Support i18n and l10n

[waldenraines]

We have several English strings in angular-patternfly and should support internationalization and localization.

I've used angular-gettext in the past but I think it would be better to provide files per language if possible using something like grunt-static-i18n perhaps? Then the consumer of angular-patternfly could just include the js file for the language they need.

[dtaylor113]

Hi, yeah, I was wondering about that. We do have several hardcoded, customer facing, strings in angular-patternfly.
+1 for this suggestion

[dtaylor113]

We were considering a simpler approach that strings are passed in via a language object like this:

http://api.highcharts.com/highcharts#lang

We have a copy of the object with english defaults in the directive and then if the application passes us one as well we overlay what they gave us with what we have and those are the versions of the strings that we use.

Keep it simple and let the products handle the translations and this way they can add/remove languages as they see fit. I am going to recommend staying away from doing the actual translation since there are multiple translation services out there that teams are using

angular-translate
http://i18next.com/
angular-gettext etc

I would rather have them pick what they want instead and give us the strings then to deal with multiple ways of picking languages.

[erundle]

I would prefer to have the consuming applications pass in the strings to the given directives than having angular-patternfly handle the translations directly. If we were to handle the translations we would need to check in translations for all possible languages and the parent application would need to tell us what language to use dynamically at runtime (Need to be able to handle user preferences or browser settings). Since our various consumers seem to be using different translation packages and our string are limited it seems like having the consuming application handle the translations would be the way to go. This also provides for greater customization ability if the applications want to change strings slightly.

[waldenraines]

Those are good points, I have to keep reminding myself that this is a library of components and not a web application 😄

I agree that we should allow the users of angular-patternfly the ability to pass in their own strings.

Will we need some way to handle plurals? A switch and replace is obviously fine for "1 item", "2 items" but it gets tricky with languages that support multiple plural forms. I still think we should use a translation library in angular-patternfly so we are sure to handle these types of issues. We would still let the user provide the actual translations though. Thoughts?