How to use Angular i18n custom IDs

Question

In angular i18n documentation, it's recommended to set unique custom ids. But I have trouble understanding how to use them.

I understand that IDs are useful in order to prevent translation changes when you update the source language. And theses IDs should be unique. When the extractor find duplicated IDs, it only keep the first.
But I have a lot of repetitions in my app. Should I use the same ID for all duplicated sentences? Should I not use an ID for theses? Should I use a different ID for all, and translate each occurrence separately?

I guess that the better solution is to not use an ID for duplicated content, and leave the generated ID. But if I have a unique sentence, and my application change, then this sentence is not unique anymore, I will have to remove this ID and translate it again, right? I will have to be careful of what is unique and what is not. Does it seems ok?

Answer 1

Extract tool maps two instances of the same string into a single resource item. This has both advantages and disadvantages. It lets you to keep the duplicates strings at minimum but at the same time it may also be dangerous to use the same string in two or more contexts. This is why custom IDs let you control the extraction better. Unfortunately custom ID must be unique in order them to work. If you use the same custom ID twice the second string is just ignored even if the string value is different.

Because of these issues we take different approach. We add a meaning value to every i18n attributes. Then we tell our localization tool to combine the location context (also extracted to XLIFF with meaning and id values) with the meaning value to get the unique context. The context does not change even we fix a typo in the string. Also the meaning value needs to be unique only among the file it is used not among all other ids/meaning in the application.

Here is a sample

<h1 i18n="header|">Plural Sample</h1>

When extracted we get

<unit id="1835493080467832141">
  <notes>
    <note category="meaning">header</note>
    <note category="location">app/app.component.ts:2</note>
  </notes>
  <segment>
    <source>Plural Sample</source>
  </segment>
</unit>

It has meaning and location properties. The localization tool we use, Soluling, combines these two to get context:

messages.xlf.app\app.component.ts.header

This is fixed as long as we do not rename the source code file or change the meaning value. We can freely modify the string value. Also the context value is much more describing than the generated id:

1835493080467832141

This is how the sample looks in the localization tool.

Answer 2

Well, I'd use custom IDs only in case you need to have more (different) translations of one string. The documentation recommends using them in case you desire more human legibility and some translation context. I'd not worry about maintenance too much, if you used a tool to manage your translations (xliffmerge for example).

The xi18n tool already does string equality matching, so if it finds more equal strings, it stuffs them under a single <trans-unit>. You than provide a (target) translated string for this unit and it will be used in place of all the source strings. The IDs should not change between multiple runs of the localization tool since they are based on the content of the strings themselves.

So my suggestion is not to worry about the IDs and re-use too much. If you write just the strings, they will be matched together and the translation will remain the same for all of them. If you use custom IDs, you have to remember to use them and to maintain their translation manually.

The case of a change in a source string is (of course) something you have to take care of.

Let's have a simple case-study for the sake of completeness: Let's say you have two identical strings in your app that have to have the same translation. You run the xi18n, generate your messages.xlf, merge it into an already translated file (e.g. messages.cs.xlf), translate the <trans-unit> and build and deploy your app. Now, somebody comes and wants you to change one of these strings. Two cases can occur here - the source string has to be changed (and translated anew), or only the translation has to be changed (the source string remains the same). In the first case you go to your code, update the source string and run the localization process again. A new <trans-unit> will have been created - you provide a new translation, build the app and you are done. In the second case, you go to the code and slap a custom ID (description and meaning are also recommended) onto the string that has to have a new translation. You run the localization process - a new <trans-unit> (with the custom ID) will have been generated. You translate it as you are used to, build and deploy.