Support dynamic ids in @angular/localize

🚀 feature request

Relevant Package

This feature request is for @angular/localize

Description

I know in-code translations using the global $localize are still an unofficial feature. However it is a very useful way for me to do translations in code. E.g.

$localize`:@@OTHER_DAYS:days`

One use-case which is not covered is, if I get the translation id via an external API. Then I have the translation id stored within an variable. It would be helpful, to be able to call $localize with an id stored in a variable. E.g.

let translationId = // get from external API
let defaultText = //
$localize`:@@${translationId}:${defaultText}`

As far as I understand the current implementation will interpret the first placeholder as part of the text and will fail building.

A clear and concise description of the problem or missing capability...

Describe the solution you’d like

If you have a solution in mind, please describe it.

An option to hand over the translation id stored in a variable to a $localize call.

Describe alternatives you’ve considered

Have you considered any alternative solutions or workarounds?

I have tried to build the arguments manually, but this fails when doing a production build:

localize(id: string, value: string) {
    let ra: ReadonlyArray<string> = [':@@' + id + ':', ''];
    ra['raw'] = [':@@' + id + ':', ''];
    let tsa: TemplateStringsArray = <TemplateStringsArray>ra;
    return $localize(tsa, ...value);
}

[simdevmon]

@petebacondarwin: thank you for your thoughts on that topic and the quick response.

The messageId and the defaultText (some features do not even have a default text and will only return the message id) are stored in a database and are fetched via a REST API from a Java application. For example I would get:

[{
  messageId: 42,
  defaultText: 'Humidity detected'
},
{
  messageId: 43,
  defaultText: 'Battery deep discharged'
}]

To explain my use case a bit better, this is the workflow I used for Angular 8:

There are 3 different ways, where translations are used:

1. Translations in templates This works fine in Angular since the beginning, so no issue here.

2. Translations in code (static id) For this I used @ngx-translate/i18n-polyfill (I know it is only a speculative polyfill):

import { I18n } from '@ngx-translate/i18n-polyfill';
[...]
this.i18n('{{count}} log messages successfully deleted.', { count: count })

1. Translations in code (dynamic id) Also using @ngx-translate/i18n-polyfill

const id = 'STATUS_' + messageId;
this.i18n({ value: defaultText, id: id });

In addition I maintain a static XLF file messages.static.status.xlf containing the dynamic ids:

    <unit id="STATUS_42">
      <segment state="final">
        <source>Humidity detected</source>
      </segment>
    </unit>
    <unit id="STATUS_43">
      <segment state="final">
        <source>Battery deep discharged</source>
      </segment>
    </unit>

During build I first run ng xi18n to extract messages from templates, ngx-extractor to extract messages from code and xliffmerge to merge the generated files with the static file:

ng xi18n --i18nFormat=xlf2 --output-path locale && ngx-extractor -i src/**/*.ts -f xlf2 -o src/locale/messages.xlf && node xliffmerge.static.js && xliffmerge --profile xliffmerge.json en de es fr ru

The advantage is that all phrases are stored in a single XLF file for each language, which makes external translation easy.

This workflow is not working anymore for Angular 9, mainly because @ngx-translate/i18n-polyfill is quite different from $localize and not working anymore. Currently I have a few options in mind for my use case in Angular 9:

• Migrate to an external library like ngx-translate or locl, but after a first try, I found out that there are also some issues.

• Make a code generation to create a map or huge switch statement containing all dynamic ids as static strings in code.

• Implement an own way to read XLF files (ship them as assets) and get the phrases during runtime.

None of these seem to be ideal, that is why I came up with this feature request. As far as I understand there is a substitution during compilation of translated phrases. Maybe $localize could be extended with an option, to build a key/value map when processing a translation file (XLF) with all pairs, that are not used for template or static in code translations. During runtime there could be a lookup for this key/value map, which was build during compilation for the translated phrase.

[angular-automatic-lock-bot[bot]]

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