When the Spanish translation gets installed, the table `menu_links` has some values in Spanish on column `link_title` while the majority remains in English.
The resulting effect are Spanish menus while in English interface. Why?

mysql> SELECT menu_name, link_title FROM menu_links WHERE link_title LIKE 'Enlace%';
+------------+---------------------+
| menu_name  | link_title          |
+------------+---------------------+
| navigation | Enlaces secundarios | 
+------------+---------------------+

Comments

jose reyero’s picture

jose reyero commented
Title: Installing Spanish translation overrides English built-in?! » Installing (Spanish) translation overrides English built-in?!
Project: Spanish translation » Drupal core
Version: 6.x-1.x-dev » 6.3
Component: Miscellaneous » language system
Priority: Critical » Minor

No idea but in any case, I don't think this is specific of the Spanish translation. So moving this issue to Drupal project.

ñull’s picture

ñull commented
Version: 6.3 » 6.4
Priority: Minor » Critical

I can confirm this. I installed Drupal in Spanish, so not importing it after installation. I am the admin and want to work in the original language English to avoid any confusion when I administer the site. So I set the admin user to English. In version 4.x and 5.x this would give me the satisfactory result of having Administration pages and interface in English. In 6.x everything stubbornly remains Spanish, so it really breaks the language system. Imho that is not a minor bug, because the key functionality of the language system is broken.

ñull’s picture

ñull commented
Title: Installing (Spanish) translation overrides English built-in?! » Change user language is broken
Version: 6.4 » 6.6
Status: Postponed (maintainer needs more info) » Active

I can confirm that it also "works" (or fails, we talk about a bug here) when you try it with another language like Dutch. I now have another clean installation done in English then added Spanish, like before I see that the default overrides everything and a user can set to English, but you won't see the change take effect.

To see if this is just Spanish I tried it with another language, Dutch this time, and the same thing happens. The default interface language was set to Dutch and even though I set user to English (or Spanish) , still Dutch is the visible interface language. This is not the expected behaviour what we have see in D4 and D5.

arhak’s picture

arhak commented
Title: Change user language is broken » Installing translations (from the very beginning) overrides English built-in
Priority: Critical » Normal

I don't think this would be critical, since it has a workaround: just install Drupal in English then once installed it is save to add any number of translations.

ñull’s picture

ñull commented
Version: 6.6 » 6.10
Priority: Normal » Critical

In my opinion it remains critical since it is no workaround for already installed and live sites.

gábor hojtsy’s picture

gábor hojtsy
he/him
Primary language Hungarian
Location Hungary
commented
Status: Active » Postponed (maintainer needs more info)

Did this also fail if you did not visit the menu admin pages at all? Ie.

1. Install Drupal with the given localization.
2. The site is already broken from the first screen?

ñull’s picture

ñull commented
Priority: Critical » Normal
Status: Postponed (maintainer needs more info) » Closed (duplicate)

This is just a duplicate of http://drupal.org/node/222401 . It is a new "feature" in language behaviour of D6

arhak’s picture

arhak commented
Status: Closed (duplicate) » Active

@com2:
woo!
no no no
this is NOT a duplicate of that issue

we are talking here about broken behavior, i18n not working, languages messed up, and so on

we are talking about the wrong data in the menu_links table which should remain in English so t() can work properly

please, read carefully from top

gábor hojtsy’s picture

gábor hojtsy
he/him
Primary language Hungarian
Location Hungary
commented

Interestingly nobody else reported this bug, however this sounds like the used menu items do use t() themselves, while they should not. Does this happen with a clean install?

arhak’s picture

arhak commented

yes, very vanilla, just starting with a profile in other language than english

arhak’s picture

arhak commented
Priority: Normal » Critical

I have noticed that in MANY places Drupal uses patterns like this (just an example pattern, not real code):

  $data = array(
    'type' => t('Page'), // if it's during profile installation would be st() instead of t()
    'description' => t('This is a description of the data type Page'),
    ...
  );

This patterns leads to translated version of several data (not just content types attributes) to reside already translated in the database
which leads to not-English version being impossible to translate again
also NOTE that whenever this patter is used is because latter on the data will be retrieved without re-applying translation to it
thus, the translated version resides in the database and will be the ONLY version available (kind of hard coded)

IMHO this shouldn't happen this way, because it only stands for non-multilingual sites, which work only with ONE translation and the problem is bypassed unnoticeable.
But for multilingual sites, this is a huge problem, since there are already hundreds of lines using this kind of pattern, even worse, I think this pattern was highly introduced since someone noticed the performance improvement without noticing the affected multi-lingual sites.

am I agreeing this issue should be critical?
it's turning kind of annoying to hit it here and there every while blocking a seamlessly multi-lingual site development

petergrob’s picture

petergrob commented

A little late, try to set this.

language configuration to 'Padprefix'

I hope this is what you mean.

Peter

arhak’s picture

arhak commented

@#12 excuse me, but I don't see how does that has anything to do with this issue

gábor hojtsy’s picture

gábor hojtsy
he/him
Primary language Hungarian
Location Hungary
commented
Status: Active » Closed (works as designed)

Yes, Drupal will assume all user input is in the site default language, which is NOT English if you install in a foreign language. In that case, your site default will be the given language you've installed in. For user editable input, Drupal mostly assumes it is in the site default, so things such as your site name, menus, node types, etc. will be created localized to the right language. This works for single language sites or sites where you don't want English defaults but instead want to work off of a foreign language default. It does not work well for sites where you want an English default. You should install those sites in English to make sure all the initial setup is done in that language. This is probably not evident, but by design in Drupal 6 and 7. We might improve on this in Drupal 8 by assigning language to each setting, but that is still long ways off.

arhak’s picture

arhak commented

seems more like a "won't fix",
I doubt it was actually "designed" to be this awkward,
it was implemented this way, but it was an oversight, not deliberately

This works for single language sites or sites where you don't want English defaults
[...]
You should install those sites in English to make sure all the initial setup is done in that language.

lets say I want a multilingual site in Dutch, Italian and French, but no English at all
why should I think I would have to install in English?

It does not work well for sites where you want an English default.

why should I be forced to keep an English default in a non-English site?

This is probably not evident, but by design in Drupal 6 and 7.

at the very least, there is a lack of documentation regarding this

gábor hojtsy’s picture

gábor hojtsy
he/him
Primary language Hungarian
Location Hungary
commented

Erm, installing sites in English I've specifically suggested for when you DO want English language supported. Looks like you omitted too much while quoting me :) The usage of t() in install files is exactly better for the single language sites where it would install the settings in that language and for multilingual sites where English is not the default, where it will do the same, install in a foreign language. If you need English as your default language, it is best to start installing in English. Clearer?

arhak’s picture

arhak commented

Looks like you omitted too much while quoting me :)

sorry, it wasn't my intention to tweast your words

The usage of t() in install files is exactly better for the single language sites where it would install the settings in that language [...]

agreed

[...] and for multilingual sites where English is not the default

I don't see it

If you need English as your default language [...]

agreed

so, the problem resides in the middle part, which I still don't get,
multiple languages, and lets say no English at all

what should be done?
install for instance in Spanish?
values in tables will be in Spanish then, and therefore non-translatable to Italian
(take the same example as original post, but don't think of English as being mentioned, use Italian instead)

am I missing something?

gábor hojtsy’s picture

gábor hojtsy
he/him
Primary language Hungarian
Location Hungary
commented

User editable configuration is non-translatable with Drupal core in any case. The idea is that user editable configuration settings are in the site default language. If that is English, then it makes sense for them to be in English, so when you install your modules with .install files using t() to initiatialize user editable settings, t() will return the English original. If you install your modules in a foreign language, that is assumed to be your site default, so the settings will be saved with that language. It does not seem likely that on a site where English is not a supported language, you do want to have default settings in English, right? Sounds like a waste of time and resources. If you do want to translate editable user/site configuration, i18n module is to the rescue.

arhak’s picture

arhak commented

If you install your modules in a foreign language, that is assumed to be your site default, so the settings will be saved with that language.

makes sense until you want them to be translated as well

It does not seem likely that on a site where English is not a supported language, you do want to have default settings in English, right?

deppends...
would it be in trade off of translatability?

Sounds like a waste of time and resources.

agreed

If you do want to translate editable user/site configuration, i18n module is to the rescue.

not yet the holy grail, haves its own issues and limitations,
hopping to have it in core filling the gaps

--

thank you Gábor, very much for walking us through this,
my final point being

This is probably not evident, but by design [...]

it is not well documented (at least, not that I have found)
this would be the first place where such explanation exists (I think)