🚀 feature request

It would be useful for the still in-development i18n extraction tooling to include support for context and context-group tags in the generated XLIFF files when this functionality is released.

Relevant Package

@angular/localize

Description

This is in anticipation of functionality that is currently in-flight (#32912 ). I looked through that PR, open issues, and other i18n-related PRs but couldn't find any mention of this. It would be really useful for the i18n extraction tooling, whenever it is released, to include support for including the context and context-group tags as defined in the XLIFF 1.2 Specs. This would make it easier to see where strings are used in source, at a glance.

Describe the solution you'd like

Include context and context-group tag information in generated XLIFF files when i18n extraction support is released. An example of what this might look like in a generated XLIFF file's trans-unit block:

      <trans-unit id="0aaa61f16a4e7f7d6a1bfc6d513fb99ceec77f17" datatype="html">
        <source>String 1</source>
        <target>String 1 translation</target>
        <context-group purpose="location">
          <context context-type="sourcefile">src/app/components/examplecomponent/example.component.ts</context>
          <context context-type="linenumber">25</context>
        </context-group>
        <context-group purpose="location">
          <context context-type="sourcefile">src/app/components/examplecomponent/example.component.html</context>
          <context context-type="linenumber">7</context>
        </context-group>
      </trans-unit>

Describe alternatives you've considered

Two alternatives would make it a little easier to back-track from string to source but have shortcomings:

• Option 1: Use custom ids for all localized strings, and use some convention to ensure that every id is unique. The downside to this approach is that in cases where the same string needs to be used multiple times, your XLIFF file has separate entries for each instance of the string, making the XLIFF file a bit of a mess with duplicate entries.
• Option 2: Use a custom id for all unique strings. So, every time we needed the string 'String 1', we'd specify custom id 'string1'. The issue here of course is that if someone changes the actual string used in one of those cases without changing the custom id, per the i18n documentation: "If you use the same id for two different text messages, only the first one is extracted, and its translation is used in place of both original text messages".