One way of looking at text fields is that they are either in a specific language in which case they should be marked with that language or they are invarient across languages, perhaps have some other marking. For those fields which are in a specific language, they should actually be an array so that you can select the one that matches the user's current default language, or one marked default if there is no translated version for the language (probably english). Similar considerations apply to numbers and dates where one probably wants to format them for the current default language. The Unicode Consortium has discussed a lot about embedded language tags within text strings to handle the case of say a French quote inside otherwise English text. Here, if one were to send the string to a translator to Russian, you would expect the English to be translated but the French left alone. I don't know the current status of the implementation of these tags as I have been off their email list for a few years. Doing a search on www.unicode.org for language tags claims that they are part of the standard.
-----Original Message----- From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Jose A. Reyero Sent: Sunday, February 26, 2006 12:18 PM To: development@drupal.org Subject: Re: [development] Drupal and i18n, the holy grail?
Bèr Kessels wrote:
I rather like Jose's approach to i18n support, and that is having it in core. I'm a little skeptical that having i18n as modular functionality. It should really be a part of core, and not something that can be turned on and off.
You are, unfortunately, making the same 'mistake' that Joses approach has had since the beginning:
There is *no* holy grail. All our i18n sites differ so much in what they need that they can never use the same codebase.
I think you got my intentions wrong because I agree with this 'no holy grail' idea from the beginning. And that's why the i18n.module is nothing more than a buch of options you can use -or not- to have whatever idea of multilingual site you want.
*this* cannot live as turnkey in core. It can only ever live in core as APIS that offer miodule developers to build translation and so interfaces.
All I'd like to have in core is some basic support for handling 'multilingual objects'. But a simple default for a multilingual site wouln't be bad either.
Beleive me: I have been hacking Drupal since I released my first english and dutch Drupal site back in 2002 .
My post is not "just a wild idea" to hack current systems up into smaller chunks and that be it. Its four years of Drupal-i18n experience that I compiled into a final proposal :). And I am not sayig this to lever myself as /te/ i18n guru, or to get aah and oohs. I am saying his, to illustrate my reasons for disliking the monolyth apprroach.
Looking forward to take a look at your proposal -cannot access your site right now-...
Cheers,
Bèr