[sldev] Looking at I18N formatting standards

[Philippe Bossut (Merov Linden)]

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090220/169a75d5/attachment.htm