default language and string translations

There's a number of bug reports on the default language problem that Jose Reyero usually dismissed as non-issues.

It is clear that the status quo creates an unbelievably difficult problem for site owners on their upgrade path to D6. I stopped half-way the conversion of a fairly populated site (millions of hits/month) to multiple languages because of the default language problems and resumed just yesterday.

Im sure there is a way to avoid clusterf**k when changing default languages and in my naive mind it looks easy, without too much blood/sweat using current system and introducing "Language neutral" for all translated strings to sync.

Basically problem is that Locale assumes all strings from core to be English when in fact they are not¹, they must be treated as Language neutral. English should be added as new seperate Language in multilingual systems with possibility to copy all strings from Neutral to English.

¹ Some strings are English, some are American English, some are bad English, few are English with typos :)

My proposal is fix in i18n or new module that introduces Language neutral, sets it as default, does not show it to front end users and (optionally) find other ways to provide path with no prefix for new "virtual" default language that can be ANY other language including English.

Lets discuss. Opinions welcome!

Name it Language neutral or English, the problem stays the same.

AFAIU, i18n-strings just way a bit too far in trying to solve the i18n problems.

If the default language was chosen to be English for i18n-strings, it would be much easier for Drupal users to understand what is going on.

How to fix that is a different matter. I am not sure i18n is fixable as it it now. Any fix I can think of would create major upgrade problems.

Language neutral is English. Every string in every module must be written in English, it is a requirement for correct functionality.

http://api.drupal.org/api/function/t/6
Parameters
$string A string containing the English string to translate.

i18nstring is created for user submitted string translation. There are sites which don't have English language so it is logical to use the default language as source, therefore not requiring to translate any user submitted string into English..

Sure there could be a solution for switching default language, just it seems no one has had the time to implement it yet. Patches welcomed, but whinning about it on the issue tracker just takes away time from people that maybe could do the patch otherwise.

The problem with having language-less strings is that the underlying localization system doesn't really support it. Nor D7 will do it. Moreover source strings need to have a language so you know from which language you are translating.

Thinking of English as the only default language is like saying everybody has English as one of the languages on their site. And really, the world is bigger than that...

So Drupal core handling (D6 and D7) for user defined strings is really limited. Everything you build on top of that will be limited too. We haven't got lucky with patches attempting to fix that for D7.

However most of the issues here refer mostly to UI for handling such strings. That's fixable and just needs time and work. But it eems developers posting patches have other priorities, not anybody's fault.

whinning about it on the issue tracker

i follow 2 closed issues and nobody whines there, they sit silently and are sad :)

Nor D7 will do it.

Even sadder :)

source strings need to have a language so you know from which language you are translating.

Not necessarily. I dont care what is language of source strings, most of the time they will be english anyway.

the core issue is that switching default languages will fck up translated strings. That is massive fail. How about we think for a moment what is the less painful way to fix it.

I had an idea yesterday, what if developer needs web site in french and russian, but wants to work/synchronize content in english. So he installs drupal with english default + fr and ru languages. He wants users to see french as default and be able to switch to russian, but default english is hidden.

the idea would be that he NEVER EVER switches default language, its english forever (not to kill translated strings). default french for front end is set in apache config or (...your suggestion here), like something.com = something.com/fr

is it possible to switch to russian in this apache setup?

returning to original posts

The strings will be translated from the default language (which may not be English), so changing the default language may cause all these translations to be broken.

Why exactly this happens?

Hi there!
I am with mansspams. Even though my point is somehow different:
I just don't want to have the functionality of t() or i18n lost if i view a drupal page in english.
By using i18n (and t()) I'm able to switch default text outputs of modules the way I want it. It's really handy. Not only in terms of translation but also in terms of modifying texts to my needs. May I want to have a certain module to spit out a different text at a certain place - I can do that nicely by using i18n - as long as I'm not trying to change english texts :(

So many systems are using gettext functionality to change outputs generally...
...why not drupal too?
I'm getting sick of jumping in each modules source code to change the english texts and get them lost in the next upgrade of the same module.

Cheers to mansspams.
And the problem lays even deeper in my eyes.

@guedressel: add a new language and name it English. Do never modify the source code.