Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fallback translations #52

Closed
FallenRiteMonk opened this issue Aug 29, 2019 · 8 comments
Closed

Fallback translations #52

FallenRiteMonk opened this issue Aug 29, 2019 · 8 comments

Comments

@FallenRiteMonk
Copy link

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:

Current behavior

If a translations is missing (or empty) using structural directive does not show anything at all, while using the pipe, the attribute directive or the programmatical translation returns the key of the requested translation and shows the missing translation error in the console.

Expected behavior

All possibilities of translation should behave the same way. If a translation for a key is missing, then the structural directive should also display the key as text, as well as show the error message in the console.

In my opinion it would even be more useful to use translations from fallback languages of the key if no translation is provided and only use the key if every fallback language also lacks the translation for the key. This could be optional configurable in order to not have braking changes in case some people rely on certain translations missing.

Minimal reproduction of the problem with instructions

Using the following template from the example but provide a translation where key home is not defined or empty

<ng-container *transloco="let t">
  <li>{{ t.home }}</li>
</ng-container>

<ng-template transloco let-t>
  {{ t.home }}
</ng-template>

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

The error message in the console is very useful during development for finding missing translations. I find it very irritating for a user to see a key if a translation is missing and think it would be more useful if he would then just get a translation from a fallback language.

Environment

Angular CLI: 8.3.1
Node: 10.16.0
OS: linux x64
Angular: 8.2.4
... animations, common, compiler, compiler-cli, core, forms
... language-service, platform-browser, platform-browser-dynamic
... router, service-worker

Package                           Version
-----------------------------------------------------------
@angular-devkit/architect         0.801.1
@angular-devkit/build-angular     0.803.1
@angular-devkit/build-optimizer   0.803.1
@angular-devkit/build-webpack     0.803.1
@angular-devkit/core              8.3.1
@angular-devkit/schematics        8.3.1
@angular/cdk                      8.1.4
@angular/cli                      8.3.1
@angular/fire                     5.2.1
@angular/flex-layout              8.0.0-beta.26
@angular/material                 8.1.4
@angular/pwa                      0.803.1
@ngtools/webpack                  8.3.1
@schematics/angular               8.3.1
@schematics/update                0.803.1
rxjs                              6.5.2
typescript                        3.5.3
webpack                           4.39.2
@NetanelBasal
Copy link
Contributor

NetanelBasal commented Aug 29, 2019

Due to the obvious reasons, this cannot be done when using a structural directive. Ok, it's not entirely accurate as we could probably get it done by using Proxies, but we prefer to avoid it for now.

The missing handler functionality is a "nice to have" one. We don't expect applications to be deployed with missing translation keys.

The structural directive comes with this disadvantage, but with many advantages such as DRY, efficiency, the read property, etc.

Regarding your second point, It seems unusual to me that the whole app will be in English, and one section that doesn't have a translation will be in another language. I would call it a bug.

@NetanelBasal
Copy link
Contributor

NetanelBasal commented Aug 29, 2019

We are working on a powerful CLI tool that one of his options is to analyze your code and base on your translation files will inform you if you are missing certain keys. (In all languages)

@FallenRiteMonk
Copy link
Author

I understand all the things you say and it also makes sense to say it is a bug if one translation is missing in a language. But with the current moment being, that it is possible that a text is missing or showing some weird key to the user, seems like a but as well.

The CLI tool sounds amazing and I'm looking forward to it.

Do you have any timeline on when its going to be ready for use?

@NetanelBasal
Copy link
Contributor

@shaharkazaz is working on it. I guess something like two weeks.

@NetanelBasal
Copy link
Contributor

I'm closing this issue for now. We'll keep you updated when the tool is ready. Thanks.

@Dschuli
Copy link

Dschuli commented Apr 13, 2020

Hi,
I could thing of two use cases where a fallback translation on a missing key in one language would be helpful:

  • Similar languages with a few differences (e.g. French & Belgian), where only the deltas would be needed to get translated in one of the translation files

  • Applications where only parts need to be translated - e.g. the end user part needs translation, while the administrator part does not.

So a feature request as above does make sense to me and has my support.
Assuming that loading two language files is not too much of a downside (needs verification) should be a relatively small (optional) addition to the transpiler.

@NetanelBasal
Copy link
Contributor

@Dschuli, we support this feature.

@Dschuli
Copy link

Dschuli commented Apr 13, 2020

Sorry - I'm a new to Transloco. Just found out in the docs that I just have to set the useFallbackTranslation to use it. Was about to remove my comment ...... too late. damn.
Cudos anyhow for Transloco. So far I really like what I see.....

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants