Great feedback, thanks! One other issue I've been thinking about: how to handle pluralization and gender. For example:
"[NAME] gave you a new [ITEMTYPE] [DAYS,integer] days ago." There are 3 potential problems here: 1. [NAME] gave - 'gave' might vary based on gender or familiarity. This is pretty much impossible to solve since there is no practical way to know the gender or relationship of, say, "M Linden". 2. new [ITEMTYPE] - 'new' might vary based the gender of ITEMTYPE. In this case we could specify the gender, since ITEMTYPE is presumably in a localized table somewhere. We could do something like '[ITEMTYPE] [nuevo|nueva,gender(ITEMTYPE)]'. Has anyone seen anything like this before? 3. [DAYS,integer] days - we see this problem in English all the time "1 days ago". We could do something similar to the above example: '[DAYS,integer] [day|days,plural(DAYS)]. Again, any good references for this sort of thing? Thanks, -Steve Philippe Bossut (Merov Linden) wrote: > 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 >> <http://www.icu-project.org/> 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/) > <http://www.poedit.net/%29> 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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges
