New feature: Manage translation files by module

[nhvu95]

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 and assemble-i18n if they are not exist

"assemble-i18n": {
      "executor": "ng-extract-i18n-merge:ng-extract-i18n-assemble",
      "options": {
        "browserTarget": "item-portal:build",
        "format": "xlf2",
        "outputPath": "src/assets/i18n",
        "sourceFile": "messages.xlf",
        "manageModules": true,
        "targetFiles": [
          "messages.en.xlf",
          "messages.da.xlf"
        ]
      }
    },
    "extract-i18n": {
      "executor": "ng-extract-i18n-merge:ng-extract-i18n-merge",
      "options": {
        "browserTarget": "item-portal:build",
        "format": "xlf2",
        "outputPath": "src/assets/i18n",
        "sourceFile": "messages.xlf",
        "manageModules": true,
        "targetFiles": [
          "messages.en.xlf",
          "messages.da.xlf"
        ]
      }
    },

When 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 this

.
├── message.xlf
├── message.en.xlf
├── message.da.xlf
├── frame/
│   ├── frame.en.xlf
│   └── frame.da.xlf
├── setting/
│   ├── setting.en.xlf
│   └── setting.da.xlf
└── common/
    ├── common.en.xlf
    └── common.da.xlf

Send your parts to the translation department, then execute and combine them by the command to assemble only nx assemble-i18n Or nx extract-i18n to extract and assemble at the same time.

[nhvu95]

@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.

[daniel-sc]

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:

1. Why would one like to split the single file into multiple "modules"? In the end all text needs to be translated and multiple smaller files instead of on larger file rather makes management more complicated?
2. How common to you think is this need among other users? (I suspect it is not so common, but please change my mind :) )
3. Why should this be included in this library and not be a separate tool (angular builder)? Splitting/combining modules by ID prefix could well be separated from the extract/merge - or is there some requirement to have it integrated?

[nhvu95]

@daniel-sc Sorry for this mess; I never contributed to a project before. So so sorry about this :pray:

1. 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.

2. 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:

3. 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.

[daniel-sc]

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!