I'm opening this ticket to explain why I need the textdomain support on angjuar-gettext according to the conversation at #115.
The project I'm getting involved uses some external/3rd party AngularJS components that provides UI and widgets and contains some strings should be translatable. and some of them are accessible from apps even to change it to the unique strings and some of them aren't and they aren't supposed to let users modify as a design. so i18n has to be done in each components as opposed to what @rubenv suggested there.
There are two problems in this case:
- all of components aren't necessarily under the control. centralizing all of translatable strings into one may be impossible.
- duplicate translators' resource for components if centralizing them and going to get involved with projects that uses those components.
If the textdomain is supported, those are addressed and improved a lot.
This is the incident use case of the textdomain various projects take into account, and as documented in GNU gettext manual.
Hope it explains enough. please reconsider this support in angular-gettext.
I'm opening this ticket to explain why I need the textdomain support on angjuar-gettext according to the conversation at #115.
The project I'm getting involved uses some external/3rd party AngularJS components that provides UI and widgets and contains some strings should be translatable. and some of them are accessible from apps even to change it to the unique strings and some of them aren't and they aren't supposed to let users modify as a design. so i18n has to be done in each components as opposed to what @rubenv suggested there.
There are two problems in this case:
If the textdomain is supported, those are addressed and improved a lot.
This is the incident use case of the textdomain various projects take into account, and as documented in GNU gettext manual.
Hope it explains enough. please reconsider this support in angular-gettext.