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