ng-xi18n should generate same IDs when using xlf or xmb format

I'm submitting a ... (check one with "x")

[ ] bug report => search github for a similar issue or PR before submitting
[x] feature request
[ ] support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question

Current behavior
Using the same template with some i18n markup text.
I try to extract the messages file with ng-xi18n.
I can use formats xlf or xmb with the --i18n-format xmb flag.
But in the generated messages.xlf and messages.xmb the units for the same input texts have totally different IDs.

Expected behavior
The generated IDs should only be a function of input text, description and intent, they should not depend on the output format.

Minimal reproduction of the problem with instructions

(see above)

What is the motivation / use case for changing the behavior?
I try to buld some tooling for i18n, especially something like a translation memory.

Therefore it is important, to have format independent IDs.

Please tell us about your environment:

Angular version: 2.0.X

Browser: [all | Chrome XX | Firefox XX | IE XX | Safari XX | Mobile Chrome XX | Android X.X Web Browser | iOS XX Safari | iOS XX UIWebView | iOS XX WKWebView ]

Language: [all | TypeScript X.X | ES6/7 | ES5]
Node (for AoT issues): node --version =

@vicb

Xmb uses decimalDigest, and xliff uses digest to generate ids.
Apparently based on this issue the digest for xmb was changed because xmb tools require decimal digests and not hexadecimal. But I don't know why it was not changed for xliff at the same time, I don't see anything in the xliff spec that specifies that it should be hexadecimal.
@vicb what is the reason for using two different digest functions? Can we make xliff use the decimalDigest function as well?

This is because we need decimal IDs internally.

Ideally we should switch to the same IDs for xliff.

I see 2 possible solutions:

create a new xliff format with decimal ids,
use decimal ids for the current xliff format -> we need to come up with a tool to convert hex IDs to dec IDs

May be we should start with the former, deprecate the latter and also come with a tool before removing the legacy IDs.

thoughts ?

So, if I understand you right, the idea is

change ng-x18n, so that it creates the same decimal IDs as xmb
have a flag to say "use old hex IDs"
deprecate that flag after a while
have some tooling to convert the IDs in already translated files

Sounds great.

Personally, I'm currently working on some tooling called ngx-i18nsupport.
The basic idea is, that it merges translated files with newly (via ng-xi18n) created files.

In the moment it works based on the IDs, so it compares the IDs found in the master file with the IDs found in the translated files and merges it.

But it would be a very small change, to let it look at the message content.

So, if you have e.g. <p i18n>Hello, world</p> and this is converted to messages.xlf

  <trans-unit id="12...">
    <source>Hello, world</source>
    <target/>
  </trans-unit>

and you have a translated file messages.de.xlf containing

  <trans-unit id="xy...">
    <source>Hello, world</source>
    <target>Hallo Welt</target>
  </trans-unit>

it would detect, that source (and description and meaning) are the same, and would change messages.de.lf to contain

  <trans-unit id="12...">
    <source>Hello, world</source>
    <target>Hallo Welt</target>
  </trans-unit>

(currently it would just delete the translation and add a new untranslated version because of the changed IDs).

Oh I like the tool that you're working on, I might use it for my workshop at ng-conf :-) (or at least mention it).

And yes you understand the idea right, the only problem is that even if the fix is super simple, it's a breaking change (because old ids will all be replaced...). The tool that converts ids will take more work but should not be too hard to do.

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.

This is a large breaking change -- we're unlikely to do this, unless a clearer benefit of having the IDs be the same is apparent.

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}

Navigation Menu

Repository navigation

ng-xi18n should generate same IDs when using xlf or xmb format #15136

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

ng-xi18n should generate same IDs when using xlf or xmb format #15136

Description

Activity

ocombe commented on Mar 20, 2017

vicb commented on Mar 20, 2017

martinroob commented on Mar 22, 2017

ocombe commented on Mar 24, 2017

angular-robot commented on Jun 5, 2021

angular-robot commented on Jun 25, 2021

dylhunn commented on Mar 31, 2022

angular-automatic-lock-bot commented on May 1, 2022

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions