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

Extracting translations at the library level #72

Closed
Rafarel opened this issue Jun 2, 2023 · 2 comments
Closed

Extracting translations at the library level #72

Rafarel opened this issue Jun 2, 2023 · 2 comments
Labels
question Further information is requested

Comments

@Rafarel
Copy link

Rafarel commented Jun 2, 2023

Hello there!

First of all, thanks for this amazing library that helps me a lot :)

Is your feature request related to a problem? Please describe.

I have a mono repo that I manage with NX (NX is not a problem here) that contains like 4 apps and 5 libraries.
Some apps import some libraries that are shared between apps, I guess that is a pretty common scenario right.

The problem is that Angular built-in localization support primarily focuses on extracting and managing translations at the application level, rather than extracting strings from individual libraries or modules. So when I do extract the i18n strings from app-one and app-two that both import my-lib I end up with the same string to translate in both app-one and app-two project and that is very redundant to maintain.

Describe the solution you'd like

Maybe it already exists, I dunno but I would be great to be able to extract the translation of all the files of a library separately. So in the app-one and app-two I would just give the my-lib translation files in the i18n configuration of the locales. (I tried this manually this works great). The real pain point is at the extraction level that depend on a app browserTarget...

I would like to avoid the need to put custom ids to every i18n string because that is a huge overhead to maintain consistent ids across the apps and libs.

Describe alternatives you've considered

I have considered extracting the string from the library using the build target of one of my app but it would extract just the strings used by the app I guess... plus the string that comes from the app and not the library so that is pretty bad.

Do you have any idea or know about any solution that would help me to manage my translations at the library level ?

Thanks a lot!

@daniel-sc daniel-sc added the question Further information is requested label Jun 2, 2023
@daniel-sc
Copy link
Owner

hi @Rafarel

it seems extraction of i18n texts directly for a library is not yet supported by angular: angular/angular-cli#17140

I'd recommend the following setup for now:

  • Always use explicit i18n IDs with a common prefix per library
  • Manually maintain translation files for your library (until i18n support in Angular libraries angular/angular-cli#17140 is resolved) and make sure they are distributed
  • Include the libs translation files in your projects angular.json (the "translation" attribute can take a list of files!)
  • Exclude the libs translations from your app translations by using the config option "removeIdsWithPrefix" of ng-extract-i18n-merge (so your apps translation files are not polluted with the libs translations)

Note that missing translations of (marked) library texts will result in a warning/error of the app build (this way you could "integration test" your manually maintained translation files).

If this does not resolve your question, please comment/reopen!

@Rafarel
Copy link
Author

Rafarel commented Jun 2, 2023

Thanks @daniel-sc for your answer.

That's exactly what I did previously (using ids for libs and removeIdsWithPrefix), except I used the build target of an app to execute an i18n extraction of the lib strings...

I subscribed to the issue you shared me, thanks a lot.
Have a great day!

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

No branches or pull requests

2 participants