On 09/03/2010 09:55 PM, Adam Young wrote:
These translations were done by Google translate, and have not been reviewed by people who speak the languages.
Only the user search page has been translated


You might need to his ctrl-shift-r to see the different languages.

Freeipa-devel mailing list

When I think about I18N, I tend to try to cover a couple types of language. The set of languages covered above covers: English as a default, Spanish, as a Language that falls primarily into the latin character set, but with difference. (Indonesian falls into this as well.)
Russian using the Cyrillic Character set
Hebrew as a Right to left language with a completly non-latin character set
Chinese as A multibyte character set. I typoed the two character code as cz. It should be zh.


I find I have to do a ctrl-shift-r to see the new language.

Each language is basically a hashmap, with a top level hashmap key on the language name as a two letter code: hence the lang=es.

A couple comments on jquery.gettext.js: It makes you load in all of the languages up front. I'de prefer to do this on demand, as the number of languages we can potentially support could be fairly high, and there is no reason to make the user wait through the lengthy file-per-languages fetch. Instead, the logic should be something like:

load the index.xhtml page. User might see the keys for fields like "logged in as", or we can use the Engliash values as defaults.
The "whoami" plugin should return the users role and language preference.
With these two pieces of informtaion, we can properly render the tabs. If we really wanted to optimize, we could send the language map down at this point as well.

This starts to step on the toes of the json-metadata call. Since that seems to be necessary at all times, I wonder if we can change that from a JSON call to something like:

<script type="text/javascript" src="json/metadata"></script>

Instead of waiting for it to finish fetching at the ipa_init time.

Of course, we could do something similar with the whoami call.

In jquery.gettext.js the language selection is driven off the language set in the document. I've overridden this by explicitly setting the language based on the query param, although this is not how we should be getting this value. If the value is not set by the user preferences, then it should be a default for the site, and the user should be able to over ride it as a settable preference. Once we have the value, we can cache it in a cookie along with the other whoami info.

gettext does not seem to have a default language implementation. I see some reference in the code to a "C" locale, but there doesn't seem to be any further documentation about how to specify the values for this locale.

NOte: since the language is currently specified with a two letter code, we have no way of distinguishing between traditional and simplified chinese. I know that typically this is done via the country specifier in the locale, with Taiwan using traditional and PRC using simplified. I don't know if this is what Scott is implying we do when he says we need to suport traditional and simplified Chinese. If so, we'll need to expand the implementation to cover the country code.

There are a slew of I18N libraries for Javascript. gettext may not be the best choice, but there is no clean leader at this point.

We can generate just about all of en.json from the code and documentation. We might even be able to automate this. Once we get this project trnaslated, this will be a very valuable set of translations, sort of a Rosetta stone for computer systems. Actually, this might have been done by other projects, and we could possibly leverage the work done on them. Making it easy for Fedora users to specify a better translation, or translation for another language would be a great way to pull less technical community members in to be contributors.

Aside from the set of languages that we need for RHEL 6 we should be able to support the set of languages I listed above either inside the team, or with minimal help from people outside the team but on related projects. Obviously, If you are a team member and speak a language other than English, you should help out with the translation for that language.

I can "own" getting people to cover Hebrew

Freeipa-devel mailing list

Reply via email to