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
http://admiyo.fedorapeople.org/ipa/static/index.xhtml
http://admiyo.fedorapeople.org/ipa/static/index.xhtml#lang=es
http://admiyo.fedorapeople.org/ipa/static/index.xhtml#lang=he
http://admiyo.fedorapeople.org/ipa/static/index.xhtml#lang=id
http://admiyo.fedorapeople.org/ipa/static/index.xhtml#lang=ru
You might need to his ctrl-shift-r to see the different languages.
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
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.
http://admiyo.fedorapeople.org/ipa/static/index.xhtml#lang=cz
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
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
