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
Generating and managing the translations files for large scale applications like ERP etc is very cumbersome. #23428
Comments
I had gone in past through a library which uses xliffmerge to generate the translation files from the base translation file , https://github.com/nadeem09wani/ngx-i18nsupport here is the ref to that. |
Agreed, we need to improve this |
I've used https://github.com/martinroob/ngx-i18nsupport (instead of the fork you linked which is behind the original repo) in the past, and it works really well. I would definitely reuse @martinroob's work (if he agrees) when we work on this feature. |
That would be cool @ocombe . |
@ocombe It would be a great honor for me if you reuse my work. |
I've heard that devkit/architect docs are coming on angular.io but it'll probably be in a few weeks |
Just a heads up that we kicked off a community voting process for your feature request. There are 20 days until the voting process ends. Find more details about Angular's feature request process in our documentation. |
Thank you for submitting your feature request! Looks like during the polling process it didn't collect a sufficient number of votes to move to the next stage. We want to keep Angular rich and ergonomic and at the same time be mindful about its scope and learning journey. If you think your request could live outside Angular's scope, we'd encourage you to collaborate with the community on publishing it as an open source package. You can find more details about the feature request process in our documentation. |
The mentioned repo isn't maintained anymore. It would be really helpful if angular team could provide some guidance how to solve the issue of merging xliff files. Or maybe finally integrate the xliff merge tooling into angular. |
Unfortunately @martinroob seems to have disappeared from the web a few months after his post above - luckily he gave explicit permission to use his code in the angular implementation. We keep having to pull in old dependencies to keep our translations up to date after every angular upgrade, and this is getting to be unmaintainable. So far ngx-i18nsupport is the only free library that merges the xliff files the way we need them merged in a reliable way. @ocombe - is there any chance ngx-i18nsupport could be picked back up and adopted by/integrated into Angular? |
I no longer work for the Angular team, but I can say with 97% certitude that it will not happen |
@ocombe - that's a bummer. Any history you can share? Or is there anyone we could appeal to, to increase that 3% to something better? |
As far as I know @AndrewKushnir is now in charge of everything i18n |
My new feature request #23139 was just closed as duplicate so I'm assuming this is the place to get the latest update on this feature. In my post I suggested a way forward. Anyone from the Angular team want to comment please @AndrewKushnir ? Thanks |
During our triage meeting, we discussed that this really is a CLI issue and should really be addressed here. |
Related: angular/angular#46471 |
I created a drop-in replacement for the default angular i18n builder, which should do exactly what is requested here: https://github.com/daniel-sc/ng-extract-i18n-merge |
So now maybe creating a PR to get this into the angular repo could be a next step? As most of the work seams to be already done somebody from the angular team could help with the last step? |
I'm not sure if there is a real benefit to having this included directly in angular (cli). Of course you'd save the initial If future maintenance is assured, of course I'd be happy if it is included and maintained by the angular team! |
We had a discussion about this within the tooling team. The current process looks like this:
See https://angular.io/guide/i18n-common-translation-files#translation-process-example-for-french for more context around XLIFF files in particular. The original comment is a bit vague on specifics, but we identified two key problems with the current system:
These are related but distinct problems, and we agree that the CLI can probably do more here. It shouldn't be necessary to rely on an external tool to effectively manage subsequent translation files (an external tool may be necessary to actually translate messages, but that's a distinct problem from managing translation data). A possible solution to this (option A) would be to generate a separate XLIFF file per-locale. Currently we only generate one XLIFF in the source locale, so we can't include any existing translations. However we could generate an XLIFF per-locale and include any existing translations. If a message is new or modified, the translation would be dropped, so any messages missing a I'm using XLIFF as an example, but I think the same process can work in any of the other formats (maybe not XMB since that's a different file format from XTB?) The consequences of this are:
An alternative we considered (option B) would be to leave The consequences of this are:
As of now we're leaning towards option A as the easier fix since it doesn't require complex format-specific merge logic. What would be helpful to us is to get some feedback about how well these solutions work. There aren't enough lists in this comment, so I'll add another one to enumerate some questions the community can help us answer:
If you have any feedback related to these questions, we would really appreciate hearing it. |
@dgp1130 happy to see that the angular team wants to pick this up! I'd vote for going along "option A" as this is analogous to what existing/past tooling did successfully (compare https://github.com/daniel-sc/ng-extract-i18n-merge and https://github.com/martinroob/ngx-i18nsupport). Option B would not allow translators to have the full picture and makes it difficult to adapt existing translations with unchanged source text. Please be aware that there are a couple of subtleties involved:
For reference you could check out the config options of existing tools: |
Great to see the Angular team is standardising the final step in i18n workflow! Some context Also this ZIP and the xliffmerge tool can act as a reference for how I personally expect the feature to work using To answer the questions directly:
Working most basic working Angular 13 i18n project that does i18n merging Hope this helps someone. Once again thank you Angular team for standardising this feature. |
Since the feedback seems to be mostly position with option A, we'll move forward with that. We agree this is something the CLI should do, though right now this particular issue is a lower priority so it might be a while before we get around to it. The harder part is making sure we understand the issue and have a path forward with a fix, which is where we are now. If anyone is interested to contribute this feature, we're also happy to work with you to make that happen. |
@daniel-sc, would you be willing to use your experience as the maintainer of |
@PowerKiKi Thx - appreciate the invitation. But..
HTH |
🚀 feature request.
Generating and managing the translations files for large scale applications like ERP etc is very cumbersome.
Relevant Package
This feature request is for @angular/....Description
Using the angular's builtin translation which the angular platform provides, managing and generating the translation files for multiple locale is very cumbersome , error prone and very difficult to manage as the application size scales, as generating the translation files after adding new i18n tags , generates the a default file messages.xlf and it becomes very difficult to dig into this default file (because of size .. lines of code.) and parse out the new trans-units and then move them to each locale files manually , and paste the target tag for the new trans-units .
Describe the solution you'd like
Either the translation file should be provided for each module or component level, or there must be some version control system used to check the differences/changes in the default messages.xlf file and these changes automatically being added to other locale files . Means atleast the new trans-units must be appended automatically to the locale files that the intended developer needs to create.
Describe alternatives you've considered
We have gone through ngx-Translate etc tools that provides run-time translation using pipes, but if the angular's builtin internalization module provides additional updates in near future to ease the internationalization process for developers , its far better than other third party packages.
The text was updated successfully, but these errors were encountered: