[development] Drupal and i18n, the holy grail?
rob at torenware.com
Sun Feb 26 03:17:09 UTC 2006
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
>> 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..
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
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
More information about the development