Add possibility to pass a desired target language to TranslatePipe

[mzellho]

I'm submitting a ... (check one with "x")

[ ] bug report => check the FAQ and search github for a similar issue or PR before submitting
[ ] support request => check the FAQ and search github for a similar issue before submitting
[x] feature request

Current behavior
Using the TranslatePipe, there is no possibility to get a translation for a language other than the one that is set up - one can only pass interpolateParams to TranslatePipe.

Expected/desired behavior
It would be cool if one could also pass the token of the desired langauge for the translation to the pipe in case you need to translate a key to two (or more) different languages on the same page. Of course, this could be handled via the TranslateService using a method or another custom pipe, but passing the langauge token to the pipe would be a more elegant solution for the user.

<p>english: {{ some.key | translate }}</p>
<p>french: {{ some.key | translate:'fr' }}</p>
<p>german: {{ some.key | translate:'de' }}</p>

[ocombe]

Hello, this is an interesting feature, but this requires some big changes in the code :)

I keep it here, but don't expect this to be added soon unless someone else wants to do a PR

[mzellho]

@ocombe: Glad you like the idea :-). Not sure if I can really find enough time at the moment, but if I can, I'd be happy to help. Just in case: Would there be any design proposals for the feature from your side?

A little question about the ways I took to get a rather hacky, but working workaround for the moment...

I implemented a custom pipe that forwards the key to TranslateService:

let currentLanguage: string = this.translateService.currentLang;

this.translateService.currentLang = languageCode;
let translation: string = this.translateService.instant(key);
this.translateService.currentLang = currentLanguage;

return translation;

First I tried to go with use(lang: string), but I had some strange effects there. But since I wanted to avoid emitting any events in order to avoid performance issues anyway, I switched to above way and noticed, that the second language was missing in the translations object of the TranslateService. So I added all supported languages in the constructor of our component by calling use(lang: string):

translateService.use("de");
translateService.use("en");
translateService.setDefaultLang("de");
translateService.use(userLang);

Now, this works. But feels a little odd - can you think of some better approach?

[alanhe421]

It's a great function。I need it.

[mzellho]

@ocombe do you think this is gonna be added anytime soon?

The workaround I posted last year is still working with @angular:4.4.4 and @ngx-translate:8.0.0, but from time to time I am facing the issue that the application is being loaded in the wrong language which has a slightly annoying impact on the stability of my webtests...

Thanks!

[nilebma]

I think this is also discussed in this issue : #719

@mzellhofer thanks for the workaround. But it probably leads to a complete refresh of the UI (?) and also trigger all subscriptions of _ TranslateService.onLangChange_ property right ?

[Supamiu]

I made an implementation for a non-pipe usage (because I didn't need the pipe at this moment), but converting it to a pipe would be pretty easy:

public getTranslation(key: string, language: string, interpolationParams?: Object): Observable<string> {
    return this.translator.getTranslation(language).pipe(
      map(translations => {
        return this.translator.getParsedResult(translations, key, interpolationParams);
      })
    );
  }

[Wingzzzzz]

Please team consider applying the changes from angular-translate:
angular-translate/angular-translate@e591462

core function: $translate.instant(translationId, interpolateParams, interpolation, forceLanguage);

[ThanosAlmighty]

It's 2024 and this feature is still very much needed. Any updates?

[dananaprey]

We also came across the need for this feature. Any updates?

[ThanosAlmighty]

#233 (comment)

I ended up creating a custom implementation. I'm happy to share my approach if you would like.

[dananaprey]

#233 (comment)
We've already done it without these feature, but I'd take a look)