[development] Drupal and i18n, the holy grail?

[Walt Daniels]

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 at drupal.org 
> [mailto:development-bounces at drupal.org] On Behalf Of Jose A. Reyero
> Sent: Sunday, February 26, 2006 12:18 PM
> To: development at 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
> >
> >
> >  
> >
>