[Feature] Provide mechanism for remembering selected language

[DmitryEfimenko]

I'm submitting a...

[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  
[ ] Performance issue
[x] Feature request
[ ] Documentation issue or request
[ ] Support request
[ ] Other... Please describe:

Proposal

Based on the documentation I didn't see a way to specify a mechanism for remembering the language that user selects. I'd expect something similar to what ngx-translate-cache provides.

Current behavior

Proposed behavior does not exist

Expected behavior

Pending design

What is the motivation / use case for changing the behavior?

There is no need to ask the consumer of this library to write all the boilerplate needed to store the selected language in LocalStorage or Cookies

[shaharkazaz]

@DmitryEfimenko It's on its way 🙂
we are planning to start work next week.

[agugan]

@shaharkazaz
I am not sure whether this is incorporated in the planning or already exists. But I would also like to add a sub feature to it.

Our enterprise applications have multiple sub-projects to switch between. Sometimes we have language selection coming in from different source than the rest of project.

Currently we have to store the selected language in cookie/LS and retrieve it the respective translation module initialization.

Future: I would like to see it integrated to translation store itself.
Ex:

{
      provide: TRANSLOCO_CONFIG,
      useValue: {
        prodMode: environment.production,
        listenToLangChange: true,
        defaultLang: 'en',
        persistLanguage: {  
         persistLanguageAcross: true,
         name: 'selected_lanaguage_transloco'
   }
      }
    }

So when these options enabled, we will store the selected language also in cookie/Local/Session storage under the given name, and then we can first check for the persisted language in sub-projects else fallback to defaultLanguage.

Though this look like a specific usecase, but its also one of the bigger pain points in translations.
If you like this feature, I would love to submit a PR with help.

[shaharkazaz]

@agugan Hey, we are working on something and a PR should be ready soon, you are welcome to track this 🙂

[itayod]

Hey @DmitryEfimenko,
After reconsidering this feature, we have decided not to implement it as part of the library, as we try to keep it as clean and simple as possible.

Also implementing this feature is pretty easy and doesn't require a lot of code:

  constructor(private transloco: TranslocoService) {}

  ngOnInit() {
    // set the saved language from local storage.
    this.transloco.setActiveLang(localStorage.getItem('lang'));

    // persist the current language in local storage.
    this.transloco.langChanges$.pipe(distinctUntilChanged())
        .subscribe(lang => localStorage.setItem('lang', lang));
  }

Does it satisfy your issue?

[DmitryEfimenko]

it's trivial to save it to the localStorage. It becomes more involved when saving it to the cookie which is a valid use-case if you want to have it working with SSR.

If worrying about the library size, make it a separate addon library just like in the case of ngx-translate-cache, which is separate from ngx-translate. It does not need to be a part of the transloco library itself.

As a matter of fact, a lot of the implementation could be straight copy-pasted from ngx-translate-cache.

[NetanelBasal]

@DmitryEfimenko could you check if the following PR resolved this issue, please?

https://github.com/ngneat/transloco/pull/34/files

Feel free to suggest changes based on your experience and needs.

[NetanelBasal]

@DmitryEfimenko I rewrote it from scratch, the new implementation will be:

export function getLangFn({ cachedLang, browserLang, cultureLang, defaultLang }) {
  return whatYouWant;
}

@NgModule({
  imports: [
    TranslocoPersistLangModule.init({
      getLangFn,
      storage: {
        provide: TRANSLOCO_PERSIST_LANG_STROAGE,
        useValue: localStorage
      },
    })
  ],
})
class AppModule {}

We'll also expose the cookieStorage. If you don't provide a getLangFn function it will take cachedLang || defaultLang.

[DmitryEfimenko]

That looks clean!