While working on #313796: Clean up database before reimport kills i18n data I’ve got the feeling that I’ve found an design flaw in the translation stuff... this is difficult to explain... I will try and hope you understand the problem...

1. A site has a standard language - let's say German.
2. You create content in German over years...
3. Now I’m upgrading to D6
4. All my nodes get the basic translation as German (I will set this up)
5. Now I’d like to add more languages to my site - this will be "English".
6. Enable i18n modules.
7. Translate your menu, block, string, etc. from German into English.

Problems:
1. Now I’m not able to export the German stuff that needs to be translated to “English” into PO files!?
2. Additional I’m not able to make a backup of the English strings.
3. If I'm exporting the POT template I get "German" strings in the source fields! But source fields should be English only.
4. If someone would start to translate the PO files I would never be able to import the German to English translated stuff. Drupal does not allow to import something into "English".
5. +++

As more as I’m thinking about this… it must be an issue that was introduced by i18n module or the way it works...

Comments

After I pressed "refresh strings" for "menu" and "update translations" for "menu" - most strings in the POT template are duplicated and German... strange things happen here.

Title:Design flaw with using localization tables (non EN sites)Issues with localization interface and i18n strings
Priority:Critical» Normal

Yes, I can see this happening. However I don't think it's a design flaw, but the locale interface not being ready to deal with source strings in other languages than English, or strings translated to English.

This should be basically an UI issue, I see nothing wrong with the underlying data model to support the above features. So we should be fixing this with some form altering of locale forms or maybe with a full form replacement.

Btw, about Problem 3, you actually should be getting source strings in German (or whatever the default site language is) instead of English, so I think that part is ok. Some notes about strings here, http://drupal.org/node/313293

I believe that I should get English source strings, but I understand that you cannot provide them if they are not inside. This seems to be impossible to solve without English, but I'm sure I will get in troubles later (D7/D8 upgrade) if this logic is not correct and does not follow the standard Drupal way. Maybe we get taxonomy or menu translation in D7 and then we will be lost or need to re-translate all stuff again. Becoming a localizer user without upgrade path is nothing I'd like to get.

I hoped I could use this D6 version without sleepless nights... about - what could happen with my data :-(.

How about adding the German string to the English translation field and if someone change the English later to real English he is fine... In such a case I would have German in the German and English translation field, but all exports are working correctly and core localisation logic keeps intact - nevertheless we add a wrong language value first to the English field.

Really, using English as the base language for these translations is not an option here. You may not have English enabled as one of the site's languages.

About the future I don't think you should worry that much, or maybe you should worry really much more as no one really knows what Drupal 7 will look like a few months from now, so you may worry about all of your site's data actually. However, as we got this nice 'textgroups' feature in Drupal 6, any future locale update is supposed to mess only with strings of the 'default' textgroup, so if it does something different, it should be noted as a bug.

Moreover, if you can write some sql, at any point in the future you should be able to come out with some simple queries that do that string swapping, then having English as source strings.

So I think for this issue the only improvement we really need and makes sense is some better UI that handles these English/Deutsche string cases.

Hope this helps you sleep better :-)

Status:Active» Fixed

Added English to the list of languages for Export/Import.

So I think the bug here is fixed. Feel free to recreate / recategorize as a feature/support/task, if you still think this is done the wrong way. (Just please not 'abstract/philosophical' bugs, that wont't be too much help)

And if someone can explain this string mess in better English than me, please contribute help texts or to the handbook.

Status:Fixed» Active

Why adding the English export only if English is not the default language? I can change my mind and turn my German default to English "next week". But I also like to export my English blocks, menus, taxo, etc for backup reasons or for l10_client clean-up feature :-)

Status:Active» Closed (won't fix)

If you change your mind about default language, all these strings will be garbled, so I see very little use for it, more than confusing people about strings and languages.

Your workaround: change default language, export/import, change default again.

Read updated docs, http://drupal.org/node/313293

Also, added some more help texts.

So, for now, switching the default language is *unsupported*. Patches are welcomed though.

Puhhh - this is an important limitation... and only one click in the languages settings and my site get's broken. :-( Handbooks are partly nice, but I think they are unnecessary if the UI is intuitive. I'm not reading them... :-)

Status:Closed (won't fix)» Active

@Jose: If we have this heavy limitation... shouldn't we not disable the "Standard" radio boxes on "admin/settings/language"? This is the only way to make sure people don't clutter their installation. Additional add an info box to the top of the page that this has been disabled by i18nstrings module activation and cannot be changed or all data get's cluttered.

Status:Active» Closed (won't fix)

Added help texts everywhere. Besides that, I wouldn't disable any option that a knowledgeable admin can make use of, just for preventing people not reading the documentation of using it.

Good software is self-explanatory.

Status:Closed (won't fix)» Active

Correct me if I'm wrong about this, but having the translation interface be uni-directional is a serious limitation--it forces you to conduct all site administration in one language. Let's say that the default language of my website is Bubble, since the website is aimed at Bubble speakers, but the site administrator doesn't speak Bubble very well and prefers to conduct site administration in English.

Creating content is easy and asynchronous: the site administrator can write a blog post in English, for example, and then hand it off to the Bubble translators, go do something else, and post the translation whenever it is complete. This is because the content translation interface is bi-directional: it doesn't matter what the default language is, content translation simply creates a link between two (or more) nodes, which can be created separately.

By contrast, when creating an interface string, the site administrator is at the mercy of the translators. Because all interface strings MUST be created in the site's default language, the administrator can't make any changes to the website unless he can get a translator to provide him with a translation first. If the translators are all sick one day, he's stuck--he can't add any new blocks, views, or menu items.

So the organization has two options: hire only fluent Bubble speakers as site administrators (maybe not possible if Bubblania is a small, poor country with little IT education) or let the site administrator do whatever he needs to do in order to work, and then go back and patch up the translations after the fact (which makes having a single string translation page pointless, since you are going to have to change all the source strings anyway).

Am I missing something here? The string translation feature doesn't seem very useful--it works well if you have a mono-lingual organization and you just want to display the site in several languages for visitors. But it fails when you have a truly multi-lingual office in which people are actually doing work in two or more languages, because it forces all interface elements to be created in the default language.

I think that both the source string and the translation string should be editable from the translation interface.

Category:bug» feature
Priority:Normal» Major

Reading all this explains a lot of things. I totally agree with @derekGeo and @hass. I also know this module is a MUST in all multilingual sites. This module is a sort of a core module because as far as i know there is no other module that handles languages (suggestions would be really appreciated).

Now lets see the big picture.

I think everyone would agree this is a key feature for this module and for Drupal in general. If Drupal can handle languages without making me cry or read lots of improvised documentation without reaching what i want (simply because it is not implemented) this would be the very base. Drupal should follow his trend in offering more features and also make these easy (or acceptably easy).

The final point is, this should be MAJOR priority at least. Personally i think this is more in important than Drupal 7. Why would i need another version of Drupal if i cannot develop multilingual sites without killing myself :)

Dont get me wrong, i love Drupal! This may seem a pretty negative note so i also make my compliments to the developers for the time they take on this CRUCIAL module. Thanks, keep up the good work!

subscribing

Component:Code» Blocks
Status:Active» Closed (won't fix)

This is definitely not changing for 6.x version, though there are some open issues about this for 7.x

So far, no one has submitted any patch for 6.x, it is late now for new features or huge patches for that version.