Closed nhvu95 closed 1 year ago
@daniel-sc Hi Daniel. It means that I have to add and check some test cases, isn't it? Sorry, this is my first time contributing.
Hi @nhvu95
First of all, I really appreciate that you invested time and effort for this PR to contribute! ❤️
I probably should have indicated in the readme that before creating complex PRs a discussion/sync in an issue probably makes sense. Anyway - lets have this discussion here :)
Before going into code review, I'd like to better understand the goal. I hope you understand, that I will need to weight the complexity and maintenance increase against the value it brings to a broader set of users. (I explicitly to try to keep the scope narrow - contrary to e.g. https://github.com/martinroob/ngx-i18nsupport - to assure this stays maintainable and stable) To get there some questions:
@daniel-sc Sorry for this mess; I never contributed to a project before. So so sorry about this :pray:
Our company is a global company; Our project has around 400 screens with a bunch of text, we support 8 different languages, and after 5 years of development, Now each "message.xx.xlf" file is around 38k lines. Every time we translate new screens, we have to send them to some people, and they work in the same file "message.xx.xlf" together. Besides that, the existing screen is not completed translate, but the new screen with new text comes. Some old texts are incorrect; we have to correct them. :scream: :point_right: All of these reasons make a mess, and merging translation parts takes a lot of effort because of conflict.
Behonest that I'm not thinking about it when I make this, because not everyone gets the same problem as us. Maybe only we have this. This is my bad, so you should ignore my PR if it does not apply to common. :grin:
I believe creating a new builder will make it easier to maintain and avoid conflict with the existing one. And sometimes we just need to assemble and don't need to extract-i18n one more time again.
Hi @nhvu95
thanks for your responses (nothing to be sorry about!!)
From your answers, I read, that it would be preferable to release this separately - if this would be possible, I think this would be the best solution? When you setup the repository you could share the link here so potential users can find it, if you like!
Manage by module
Assume this is an international project, and we need support in multiple languages. By then, the translation files had scaled up the size and were hard to manage. This is the translation management by modules that show its power.
ng assemble-i18n
In your project.json or angular.json, add
manageModules
andassemble-i18n
if they are not existWhen you run
nx extract-i18n
, based on your@@moduleId_UnitId
For example: If the unit id in your HTML are@@Frame_FrameDetails
,@@Setting_Location
and@@Common_Delete
you will got files like thisSend your parts to the translation department, then execute and combine them by the command to assemble only
nx assemble-i18n
Ornx extract-i18n
to extract and assemble at the same time.