search

rubenv / angular-gettext

Gettext support for Angular.js
http://angular-gettext.rocketeer.be/
MIT License
649 stars 154 forks source link

Textdomain support #223

Open tagoh opened 9 years ago

tagoh commented 9 years ago

I'm opening this ticket to explain why I need the textdomain support on angjuar-gettext according to the conversation at https://github.com/rubenv/angular-gettext/pull/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: 1) all of components aren't necessarily under the control. centralizing all of translatable strings into one may be impossible. 2) 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.

rubenv commented 9 years ago

I don't really see an issue here.

As for point number 1: Each library can freely ship translation strings: multiple calls to gettextCatalog.getStrings() are supported, so just load each piece of strings independently and they'll be merged together as one. There's no real need to centralise things, just treat them as independent projects and load them together in the final app.

Number 2: Not sure what you mean here? Are you saying that you want to avoid duplicate translation work? Most translation tools / platforms support this: it's called a translation memory and it solves exactly this need (across projects).

I'm a bit confused though, since you're saying that you don't have control over some parts yet point 2 seems to imply that you do perform all the localisation?

Perhaps I'm missing things. I know that from the documentation domains sound great, but they don't solve any real problem which you can't solve today. I might be wrong though, so please show me a real example.

tagoh commented 9 years ago

Well, "merged together as one" is a problem. let's see, given that there are a string "create" can be translated. and one module may uses it as a menu item, one may uses it as in a dialog box with a noun. this depends on the language one is targeting for though, the translation may not necesssarily be able to share among them. e.g. both translations can be different in Japanese. so the outcome is really up to the context and the targeted language and it is different per the situation how they appear. There might be another way to work around this sisuation but the textdomain will works well.

rubenv commented 9 years ago

so the outcome is really up to the context and the targeted language

For that purpose, you need contexts, not domains. See here for an example: https://github.com/rubenv/angular-gettext/blob/98de89361bf8fe81d7645502610cb9e378f81e83/test/unit/directive.js#L42-L50

tagoh commented 9 years ago

Aha. is it documented somewhere? if not, would be nice to see it. thanks for that.

rubenv commented 9 years ago

Just noticed that it isn't, need to update the website!