[development] Drupal and i18n, the holy grail?

[Rob Thorne]

Stefan Nagtegaal wrote:
>
> Op 25-feb-2006, om 16:10 heeft Bèr Kessels het volgende geschreven:
>
>> Op zaterdag 25 februari 2006 15:47, schreef Adrian Rossouw:
>>> Remember that just because you can override any setting doesn't
>>> mean you will be able to from the interface. You still need to actually
>>> have a form element to capture the setting for that specific layer,
>>> although you might just change the default layer that things save to.
>>
>> My, personal shot at this, is to use less on-site configuration and 
>> more real
>> PHP.
>> A block defined in a hook_block can have a t() around its title. A 
>> block added
>> trough the online interface has no translation options. Same for 
>> menus, node
>> types, etc etc etc. Another reason not to lean too much on online
>> configuration, but rather build your site with normal PHP files.
> And how about usability???
> Only building your site with PHP-files doesn't improve that in any 
> case, only making it even worse..
>
>
>
> Stefan
If I understand Stefan, I have to agree.

As an old I18n/L10n tools hand (my first engineering jobs were in this 
general area),  I'm curious what a less technical admin trying to get up 
a site in Japanese or Arabic finds difficult right now.  Also, is there 
a list of general features that European or other non-English language 
coders notice as being general pains in the ass (such as bad 
phone/postal code UI, etc). 

One of the things I see frequently in I18n discussions is the tendancy 
to reinvent the wheel.  Very few of the problems people have are new, 
even for web apps, and some very good people came up with great 
solutions 10 years and more ago.  Mozilla, for example, has some great 
tools (invented by a guy named Tao Cheng, an old friend of mine).  The 
best thing about using existing tools is that people who do localization 
professionally know them and can use them.  So using more standard tools 
makes it easier for us to get professional quality translation work on a 
wider range of modules and in a wider range of languages.  You can 
easily design a better tool/file format/l10n system than many of the 
ones currently used.  But there are likely a number available that are 
almost as good, and are used widely.  It would be good to know what 
those tools are, since getting translators familiar with your system is 
half the battle from what I've seen.

I suspect some of you are old I18n hands as well, so you know what I'm 
talking about.  Mostly, the underlying PHP platform is at least better 
set up for this than (sigh) JavaScript, which has always been a 
disaster, and our t() function has most of what it needs to do things 
right if developers code with it correctly.  So I'm guessing making L10n 
easier or even possible is the bigger challenge right now.  Am I right 
about this?

thanks,
Rob