Hi,
As someone who did i18n/l10n in a former project (and even did
translations from English to French...), here's my comments on this
subject:
i18n (internationalization):
On Feb 17, 2009, at 11:48 AM, Steve Linden wrote:
The I18N dev team is going to be tackling date, time, number, and
currency localization issues in the next couple of quarters. We are
looking at existing standards for replacing text inside a message
and want to cover as many as possible before making a decision. Some
possibilities that we are looking at include ICU and XSLT. If anyone
on this list is familiar with any other good options, please reply
to this thread.
- ICU is great! It uses the Olson tables for date/time locale and Time
zone sensitive formating. Time zone support in particular can be mind
blowing. Don't underestimate this and think you can do your own home
brew "simple" version: TZ support is anything but simple... ICU is by
far the best here.
- Make sure you support primary and secondary locales as lots of
people use 2 (a primary and a fallback).
- Make sure you support the country flavors (e.g. fr_CA, fr_BE,
etc...). Beware of its infuence in data formating (use of "." instead
of "," for decimal separator for instance)
- You didn't mention "sorting" in your list. That's also a service
provided by ICU and should be used when presenting lists to users (and
we've plenty of this in SL)
- There's also a Python version of ICU (PyICU) which can prove useful
considering we've quite a bit of Python code floating around (though
none with user facing strings... yet...)
- What about providing l10n for LSL? (/me ducks...) Seriously, that'd
be really cool...
l10n (localization):
I am not particularly fond of indexed substitutions, I prefer name/
value pairs, because it gives the translator a little more context,
i.e. it is easier for a translator to look at "At [TIME] on [DATE],
there was [EVENT] on planet [PLANET]" then "At {1,time} on {1,date},
there was {2} on planet{0,number,integer}."
Our current compromise proposal would look something like this:
std::string bar(const LLSD& sdargs)
{
LLUIString foo = getString("bar"); // bar = "At [DATE,time] on
[DATE,date], there was [EVENT] on planet [PLANET,integer]";
foo.setLLSDArgs(sdargs);
return foo.getString();
}
+1 on (name/value) pairs in the code and big -1 on indexed
substitutions. As a localizer, the less guess work I have to do about
the context of a string, the faster I can get a translation out. I
don't really care about the format that much and your example could
easily be reordered in French as:
"[EVENT] a eu lieu sur [PLANET,integer] le [DATE,date] à [DATE,time]"
If you think however to localize Python scripts also, you may want to
use Python syntax though rather than your own, i.e.:
"At %(time)s on %(date)s, there was an %(event)s on planet %(planet)d"
But, heck, again, I've no religion here.
One question: which translation tool will be available to translators?
I used poedit in the past (http://www.poedit.net/) and it's pretty
handy. That also opens the door for sldev community members to
participate in the localization process. Of course, that supposes that
there's a tool to convert SL resources to the .po format and back. Any
plan for doing this?
Cheers,
- Merov
_______________________________________________
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/SLDev
Please read the policies before posting to keep unmoderated posting privileges
