Repository navigation
Feature Request [i18n]: Support providing TRANSLATIONS at NgModule level #11431
Description
Current behavior
Currently translations can only be provided at bootstrap using TRANSLATIONS. This makes it difficult for feature / component modules to ship translations xlf files along with the npm module: All xlf files from all feature modules (for a specific locale) will have to be merged before bootstrap into a single value for TRANSLATIONS.
Expected behavior
Ideally we could provide a TRANSLATIONS value for every NgModule. This would have to be per locale, possibly as an Url pattern, something like
@NgModule({ // ... omitted translationUrl: './messages.{locale}.xlf', // ... omitted }) export class MyFeatureComponent { }
but I'm not familiar enough with the compiler to understand all implications of this.
Reproduction of the problem
Package an component with localization and corresponding messages.xlf into an npm module.
What is the motivation / use case for changing the behavior?
Larger codebases like to reuse common, localized components in multiple applications to provide base components with a common style, etc. Having to merge the localization data from all modules in a pre-build step is possible, but figuring out which components are actually used and resolving the corresponding paths is tricky.
Please tell us about your environment:
Win10, corporate (with proxy..)
- Angular version: ^2.0.0-rc.6
- Browser: [all]
- Language: [all]
Activity
[-]Feature Request [i18n]: Support providing TRANSLATIONS on an NgModule level[/-][+]Feature Request [i18n]: Support providing TRANSLATIONS at NgModule level[/+]paumayr commentedon Sep 8, 2016
Related, but not as important would be the ability to run ng-xi18n per NgModule. For us this is not really a problem as we have sample / test applications for developing components which we can use to extract i18n.
While thinking about it, it should be possible to restrict ng-xi18n output to a specific module. Consider this:
Feature A (i18n)
Feature B (i18n) using Feature A
calling ng-xi18n to generate messages for Feature B would also include i18n data from Feature A, which we want to keep out of messages.xlf of Feature B.
ocombe commentedon Apr 19, 2017
This is something that we are looking into adding when we fix #11405 (using translations in code). It might not be exactly like you requested though
ChBernat commentedon Feb 26, 2023
@ocombe This was fixed quite some time ago.
Is this feature going any further?
ocombe commentedon Feb 27, 2023
No I don't think so, I'm not working for Google anymore though, so I'm not sure
ChBernat commentedon Mar 12, 2023
Damn, that's a shame.
@petebacondarwin Any news?
alxhub commentedon Apr 3, 2024
I'm going to go ahead and close this issue, as with the introduction of
standalone, NgModules don't make much sense anymore as a reasonable subdivision of an Angular application for the purposes of i18n.angular-automatic-lock-bot commentedon May 4, 2024
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.