You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Translations in a template / area of template are usually requesting translations from around the same hierarchy, such as:
In case of the menu bar:
NAV.MAIN_MENU
NAV.PROFILE
NAV.MEMBERS
NAV.LOGOUT
NAV.LOGIN
etc.
Or in case of a template:
PAGES.MEMBERS.INTRODUCTION
PAGES.MEMBERS.TITLE
PAGES.MEMBERS.SHOW_GALLERY_BUTTON
PAGES.MEMBERS.SEX.MALE
PAGES.MEMBERS.SEX.FEMALE
SHARED.ACTIVITIES
etc.
It would be awesome if when requesting translations using directive (maybe pipes?), there would be a way to define the prefix once, with the ability to request translations from other places too:
<app-member-page translatePrefix="PAGES.MEMBERS">
<h1 translate=".TITLE"></h1> <!-- Note the . at the beginning of the translate marking that it should take into account the prefix -->
<div translate=".INTRODUCTION"></div>
[...]
<h1 translate="SHARED.ACTIVITIES"> <!-- Note that there is no . at the beginning of the translate marking that it should NOT take into account the prefix, this would work as before -->
<div translate=".ACTIVITIES"></div>
<a href="/gallery" translate=".SHOW_GALLERY_BUTTON">
<div translatePrefix=".SEX">
<div translate=".{{profile.sex}}"></div>
</div>
</div>
What is the motivation / use case for changing the behavior?
The prefixes are being repeated a LOT and are a source of issues when moving translations around, also makes the code not DRY.
When dealing with dynamic translations (such as the case with the sex of the member in the example), the code can become hard to read: [translate]='PAGES.MEMBERS.SEX.' + profile.sex instead of [translate]='.'+profile.sex.
If the nesting would be expressed with a directive instead this could become: [nestedTranslate]='profile.sex'
How do you think that we should implement this?
Using the dot notation above requires less change to the external API, and is backward compatible, however is not the most readable and reasonable solution in case of dynamic translations.
If another directive, say nestedTranslate would be used to express wether the last prefix should be used or not, this would be a bigger change to the API, however could be a much cleaner solution.
nestedTranslate could either be only a boolean input value, (and basically only denote wether the leading dot is there or not), or it could work the same way as the translate, asking for a string key, and prefixing the value with the previously set prefix.
translatePrefixes should be either additive or not based on the same rules (starting with a dot or not, nestedTranslate is defined to be true or not)
The current prefix in a context can be queried the same way the ngForm ngFormGroup ngFormGroupName, etc. family of directives work, using a @host() binding.
The text was updated successfully, but these errors were encountered:
Translations in a template / area of template are usually requesting translations from around the same hierarchy, such as:
In case of the menu bar:
Or in case of a template:
It would be awesome if when requesting translations using directive (maybe pipes?), there would be a way to define the prefix once, with the ability to request translations from other places too:
What is the motivation / use case for changing the behavior?
The prefixes are being repeated a LOT and are a source of issues when moving translations around, also makes the code not DRY.
When dealing with dynamic translations (such as the case with the sex of the member in the example), the code can become hard to read:
[translate]='PAGES.MEMBERS.SEX.' + profile.sex
instead of [translate]='.'+profile.sex.If the nesting would be expressed with a directive instead this could become:
[nestedTranslate]='profile.sex'
How do you think that we should implement this?
Using the dot notation above requires less change to the external API, and is backward compatible, however is not the most readable and reasonable solution in case of dynamic translations.
If another directive, say
nestedTranslate
would be used to express wether the last prefix should be used or not, this would be a bigger change to the API, however could be a much cleaner solution.nestedTranslate could either be only a boolean input value, (and basically only denote wether the leading dot is there or not), or it could work the same way as the translate, asking for a string key, and prefixing the value with the previously set prefix.
translatePrefixes should be either additive or not based on the same rules (starting with a dot or not, nestedTranslate is defined to be true or not)
The current prefix in a context can be queried the same way the
ngForm ngFormGroup ngFormGroupName, etc.
family of directives work, using a @host() binding.The text was updated successfully, but these errors were encountered: