Code block never executes in language_initialize()

This is a spinoff, as noted, of portions of #6 through #11 of http://drupal.org/node/221121. In the other issue, I suggested that perhaps the text should be simplified to read:

None. The default language is used for site presentation. Users may (optionally) select a preferred language for site e-mails on the My Account page.

This will have to be fixed in HEAD, and then backported at Gabor's discretion, though doing so will break translations and I am doubtful that he will wish to do so.

Also, though I think this suggestion is arguably more clear, I don't think the original is unclear, so I'm not positive this is a bug, but instead, perhaps a task.

The behaviour of the "none" setting is also in conflict with the text at admin/settings/language, which states:

"If multiple languages are available and enabled ... registered users may select their preferred language ... The site's default language is used for anonymous visitors ..."

To me, this strongly implies that registered users can always select any enabled language and have the interface presented in that language. This is not the case with the "none" setting, which sets presentation to the default language only.

Like htalvitie, I don't really see why turning off language negotiation should also remove the user setting for presentation language.

@isani: "none" lanuguage negotiation basically means "no interface language switching". It might have made more sense indeed to not provide any user setting for language in this case, which was the state of Drupal for quite some time. But then we realized that we need to support user language settings for some reason. I cannot recall the exact reason now, but this can be digged up. The quote you added only says that users might have the possibility (depending on other settings), although I am not good in "may", "might", "should", "shall", etc logic and fine grained differences of these.

I've just written support for a "User-Preference only" option of language negotiation into my development system, the changes were surprisingly short and simple. I can post them here if there's a need, and I'll try to roll them into a patch this week or next, depending if I meet my current deadline ;)

I'll post them here for the moment, just because it's faster to copy & paste out of the project wiki than it is to learn the patch system and go through the approval process. I'm still pretty new to Drupal, so there might be plenty to clean up. It will be submitted as a patch soon, I'm just not sure when.

It should be noted that there is one bug that I'm aware of with the fix below: When the user changes their language-setting and clicks Save, the page reloads correctly using the new language, but the message confirming that the changes have been saved appears in the old language. I'm sure it's an easy fix, it just hasn't been my top priority yet.
Anyway, the steps are as follows:

1. Edit includes/bootstrap.inc (line 133ish) to add a LANGUAGE_NEGOTIATION_USER variable (or whatever you'd like to call it).
   

   /**
   	 * User-preference based negotiation with fallback to default language
   	 * if no language is declared by the user.
   	 */
   	define('LANGUAGE_NEGOTIATION_USER', 4);

2. Edit includes/language.inc (line 54ish, language_initialize()). Add a new case to the switch-statement which processes the case of the LANGUAGE_NEGOTIATION_USER variable.
   

   case LANGUAGE_NEGOTIATION_USER:
   	  	if ($user->uid && isset($languages[$user->language])) {
     		  return $languages[$user->language];
    		}
   		break;
           

3. Edit includes/locale.inc (line 448ish, locale_languages_configure_form()). Add an element to the #options array to include a clickable option in the form for our new option.
   

   '#options' => array(
   		      LANGUAGE_NEGOTIATION_NONE => t('None.'),
   		      LANGUAGE_NEGOTIATION_PATH_DEFAULT => t('Path prefix only.'),
   		      LANGUAGE_NEGOTIATION_PATH => t('Path prefix with language fallback.'),
   		      LANGUAGE_NEGOTIATION_DOMAIN => t('Domain name only.'),
   			LANGUAGE_NEGOTIATION_USER => t('User preference only.')),

4. Edit modules/locale/locale.module (line 55ish, locale_help()). Add the description for our option in the 'admin/settings/language' case. Note that you have to move the closing </ul> tag to the end of this new option, rather than its current location at the end of the 'Domain Name only' description above it.

   $output .='<li>' . t('<strong>User preference only.</strong> The preference set in the user\'s account is used for site presentation. If no preference is specified, the default language is used') . '</li></ul>';

Like I said, it's about 4 lines of code you have to add. If you have any questions, or anything is unclear, lemme know!

Hi Tatsunami,
Thanks for a great patch. It works with user language option but I got the problem to set my Default language instead of English. I think this bug is due to Drupal 6.1. It says configuration saved but nothing saved. If not check English, it will automatically check English as the Default language.
In Drupal 5.x I see one data cell in the Local_Meta table in the database has the colunm "isdefault" but in Drupal 6 in Language table it's not. Looking forward to your help.
Dang

Hi danghoaiphuc ,

I got the same problem in my Chinese Traditional site,It may be occurred only in a cPanel created drupal site, but I'm not sure ,and not find a way to solve the problem.....

I can't see any bug in the code here. "None" means "1) use the user preference if set, 2) if it fails, use the browser preference, 3) if it fails, use the default language". This means that LANGUAGE_NEGOTIATION_USER above is *exactly the same* as LANGUAGE_NEGOTIATION_NONE.

The only defect is that the description of the "None" setting (and even its name), is somewhat confusing. Lets patch this, and close that issue.

@htalvitie: I know, what I mean here is that there is no bug.

The only defect is a documentation issue (None should be called something else, for example "User defined").

@htalvitie: You are right, sorry. I missed the LANGUAGE_NEGOTIATION_NONE case in your code above.

Here is a proper patch for this issue. It applies cleanly both to 7.x and 6.x, but because the bug is present in both branches, the patch should be first applied to 7.x then backported to 6.x.

#259882: Language setting in user profile has no effect was a duplicate.

I just ran into this as I like to administer my German sites in English because there is more documentation available in English than in German. So while I missunderstood the describtion of "none" as well (probably because I often rather scan text than reading it and I might have skipped everything in the brackets) I don't think it is something that should only be fixed due to explaination.
For me, building a German site - not a multilingual - the way D5 worked was perfect. Set default Language to German and user language to English. Would this be the right place to ask for this or should I fill a seperate feature request?

No, here is the right place to ask for this.
I ran into the issue immediatly, as soon as Drupal 6.0 was out I created a multi install, so I want to create english (only) and french (only) websites easily, but manage them all in english like I was doing on a drupal 5 multi install.
But I was forced to bear with having all admin in french on the french sites, very confusing and useless.
And I've been creating issues on french forum and here without much success. Now I see this issue as the most researched and explained, so hopefully something will come out soon in drupal 6.3 to resolve this annoying bug!

Subscribing :-)
cafetiere expresso

To show an example how important it is for foreign language speaking admins to know what the english term for a translated string is:
Guess what "Ansichten" means? No Idea? So was my impression. I searched for views module on my site and already thought something crashed as I couldn't find the damn module until I found out that in German translation "Views" is translated to "Ansichten" - Sure this is the right translation but now imagine you look in you site for "Views" and can't find it because someone renamed it to "opinions". Or you search in google for "opinions" because you think thats the modules name. Guess this leads to another discussion "Should modul names be translated?" or "Should Drupal specific terminologies be translated" which I don't want to discuss here.
Anyway I'd be happy if I could change my Language in my user profile without any other impact on my site.

@s.Daniel: there is definitely a bug here. Drupal should allow user-selected languages, no doubt about that.

The patch in #19 should solve the problem. Could you try it and give us feedback?

Successfully tested with 6.0 and 6.2

Test with http://drupal6-0.localhost

Default language German. User has Englisch as chosen Language.

None
> Site German
> English for my user
> en/ Page not found
> de/ Page not found

Path prefix only.
> Site German
> Site German for my user
> en/ Page not found
> de/ German

Path prefix with language fallback.
> Site German
> English for my user
> en/ Page not found
> de/ German

Domain name only.
> Site German
> German for my user
> en/ Page not found
> de/ Page not found

How about a seperate option "Overwrite settings by users choice" ?

@s.Daniel: so after applying this patch you are seeing the documented behavior. Is that right?

If you feel that the documented behavior need to be changed, please open a separate feature request.

Yes, this is the behaivior after appling the patch. So the patch works for me and the idea of a radiobutton "[ ] overwrite Interface language by users choice" was just a quick idea.

#19 is far from a complete patch. Unfortunately you have not been around when this language system was designed, so you have not been able to provide your feedback. If we fall back on the user preference when "no language negotiation" is selected that does not only breaks the definition of "no negotiation", but also gets to different language content for the same URLs depending on user preferences, right?

The idea behind only switching languages based on path prefixes or domain names is to have different language content under different identifiable URLs. Also, the user preference clearly describes in case of "no negotiation" that the preferred language is only used for emails, so patch #19 is not complete in that it does not turn around the user setting descriptions additionally to the site setting descriptions.

  if ($user->uid && isset($languages[$user->language])) {
    return $languages[$user->language];
  }

I would really like that Drupal just execute this block.

Thanks for checking that. I also don't want negotiation, and just want to use user's preferences for language, so i just made very quick and dirty change by commenting out lines 22nd and 23rd (Drupal v6.2 - "case LANGUAGE_NEGOTIATION_NONE: return language_default();") of language.inc file.

Hi,

I'm not fond of php so how and where to use 222401-language-none.patch patch?
I want English content to not showing when users/guests select 'Indonesian' language, and vice versa and the patch is for this, right?

regards,
Rose

As per Gábor comment in #29, this behavior is by design.

The logic of the language negotiation changed between Drupal 5 and Drupal 6. In Drupal 5, each user could choose its language in its "my account" page.

In Drupal 6, there is language negotiation based on the path or the domain name. In the fallback mode (NONE), the user interface of the site is always in the default language, but the user can choose its preferred language *for email* in its account.

That's a design choice, and the code fully respect this choice. There is no bug here. Please open a new issue (a feature request) against Drupal 7 if you want to revert that choice.

Please read the help text for LANGUAGE_NEGOTIATION_PATH:

Path prefix with language fallback. The presentation language is determined by examining the path for a language code or other custom string that matches the path prefix (if any) specified for each language. If a suitable prefix is not identified, the display language is determined by the user's language preferences from the My Account page, or by the browser's language settings. If a presentation language cannot be determined, the default language is used.

Then, open your eyes and read the code in language_initialize(). Marvelous, this is exactly what the code does!

Closing that non-issue, again.

This by design is really shit, what if I want to have a site in french for the public but I want to see it myself in english? Why did the drupal team change that possibility? Choosing the language ONLY for email is plain stupid, why do that in drupal 6? You smoke too much drug!

I'm really unhappy that this BUG(yes!!) is not fixed in drupal 6.3...

What do I have to do (ugly fixes, anything!) to make the user able to select the language in which he wants to see the site (just like in Drupal 5) while the default language remains something else?

I'm trying to read this thread but can't figure it out..
And in my opinion this new system is CONFUSING and doesn't really do what I think everybody wants..

Thanks in advance!

@alliax, wpanssi: please open an other issue for those, this one is closed.

I've created another issue, but I came to this one because someone directed me here (from one issue I opened before)
http://drupal.org/node/282178

I'm not happy with what one user Damien is doing, don't you understand that everyone wants the old behaviour back?? Give me one person except yourself who agree that for a user selecting his prefered language and nothing happening is defined as normal?

@htalvitie: as I tried to explain to you in #37, there is no dead code in language_initialize().

The last part of the function, beginning at:

  // User language.
  if ($user->uid && isset($languages[$user->language])) {
    return $languages[$user->language];
  }

is executed when $mode == LANGUAGE_NEGOTIATION_PATH and $prefix is not found in any of the $language->prefix, as stated in the description:

If a suitable prefix is not identified, the display language is determined by the user's language preferences from the My Account page, or by the browser's language settings. If a presentation language cannot be determined, the default language is used.

You are wrong in #3, and this issue is closed. Period.

@htalvitie: can you even read? This issue is closed, the behavior is by design. Please open a feature request if you want the behavior to be changed.

God, can you read? There is no programming error here.

@Damien: You refer to Gábor Hojtsy in #29 when you argue that this is "by design". Might be my bad English but as far as I can read Gábor does not say "This is how we made it and it is right because we chose it to be like that so shut up all you small people" like you seem to do. In fact what I read is more like "This patch is not good enough yet. This is how we though it should work and why."

If a feature people are actively using is suddenly gone - what is it if not a bug?
If someone took the Enter key from your keyboard and told you every time you want to press the key you need to send a text message to +1337 with the text "enter" in it cause he thought thats how it should work ... wouldn't you say that this is rather a bug than a feature?

htalvitie:

If somebody asks me, "Can the user choose the language for the user
interface in Drupal 6", should I answer "yes" or "no"? In Drupal 5 the
answer is yes.

The answer is yes, as Damien et al presented with both code and help text.

I many countries, like here in Finland, there are several official
languages. I was planning on providing my users the option of choosing
either Finnish or Swedish as the UI language, and thought that the
language selection box on the user's profile page would allow exactly
that. But I can't.

The effect of the language choice of users depends on the negotiation mode used, and is explained in the help texts.

Could somebody who has been in charge of this design choice, tell me
and others, how on earth are we supposed to build multi-language sites
without using the language negitation systems, since it is not suitable
for many.

Worst case is that you need to use a module like i18n was for Drupal 5, which set the language code using early running hooks (and you can turn off the negotiation system by setting it to option 'none' as explained in the docs).

Domain or path prefixes mess up the site, makes it impossible to use
permanent links, most users don't know how to use the browser's language
options and even those who do, often want to make the language selection
on the site anyway.

Ha, permalinks. Good point. So the design behind not changing language codes on the fly for the same URL is exactly permalinks.

1. Assume Joe uses French and sees http://example.com/ and Jane uses Japanese and sees http://example.com/.
2. Now their bookmarks (permalinks?) point to different interface languages, and possibly even different content, BUT the same URL.
3. Now assume they see and permalink http://example.com/fr and http://example.com/jp
4. Now they both can send these links over to whoever and those who get their links can see the exact language/content they see (this is what's called a permalink as far as I know, otherwise it is not permanent).
5. Also, they can switch to whatever other language since those have different URLs.
6. Also, Google/Yahoo/Live.com indexes their site/content in different languages, so their site/content will show up for both French and Japanese searches which is better audience coverage.
7. It also eliminates the user setting in some cases, since users can just bookmark the different language version and browse from there (Drupal caches per language, so the anonymous caches will work nicely).

If you hide all the different languages behind the same URL, then it is not only hidden from users, it is also hidden from search engines, and is not possible to permalink. We had bad design choices in Drupal 5, and we were trying to correct these with the new features in Drupal 6.

Note that it is still possible to use the "bad design choice fallback" with the path prefix negotiation falling back to user settings, since we forgot to add a redirection to the user settings based language selection, so that works as it did in Drupal 5. But at the same time, it also corrects the hidden languages design flaw in Drupal 5 and allows access to different languages, based on different paths. It does not break existing URLs, since it allows access to the languageless URLs with exactly the Drupal 5 behavior you are looking for. Ideally, that user setting based selection should redirect the user to /fr for French, /jp for Japanese, etc, so that the "different language/content for the same URL" design flaw in Drupal 5 would have been completely corrected. Unfortunately we did not manage to do it all, so you have the option where language settings work as in Drupal 5.

I applied the patch presented in #19. But this patch creates problems when using global redirect. The issue is documented here: http://drupal.org/node/216271#comment-1082506

Any help appreciated!

I don't think it is a problem with global redirect in particular rather I believe after applying the patch the alias languages are being chosen by the user accounts language rather than the content (or default) language which leads to content of language A havin aliases of language B.

Only for registered users I want to see interface translated into language they have been selected.
I don't want to use prefixes.
It's really important to keep my old URLs because of search engines which already has indexed them and other site put links to some pages on my site.

URL "/node/12" now becomes "/fr/node/12"
I want to see only interface changings but not a URL's. But you are changing structure of my site :(

What should I do?

There's a patch somewhere to apply, this one http://drupal.org/node/335699 and perhaps another one I don't remember where, I haven't applied those patches, that's the only solution because obviously this is never going to be fixed because so many developers say that this is not a bug but just a feature from D5 which has been removed in D6 and may or may not be put back again in D7.
Perhaps it will be backported to D6, but I wouldn't count on that.
I call it a bug because it is stupid behavior to remove such a normal feature, maybe not a bug in drupal code but in the head of developers!

Take a look at http://drupal.org/node/282191 for the technical discussion how this could be fixed in futur versions of Drupal.
For D6 I don't believe that we will see this behaivour outside of a patch or contrib module.

I hope that this error will be corrected. (Totalizator ;) )

Putting aside the whole "design decision vs. bug" thing, anyone knows if the patch at #19 is safe/reliable to use on 6.8? Thanks!

(#19) 2 Damien Tournoud - I have a problem in this patch...
Everything works fine, but when I save new node I see in the table "node" (column:language) my default language prefix (eg. En) :(

(#36) +100 - I agree with you that this is a critical error!

I have what looks like a similar issue on Drupal 5 site.

If a user changes their language in their profile they have to log out and back in for this to take effect.

Anyone planning a patch for D5?

It is unbelievable that this didn't get fixed. For us building a commercial multi-language page, it is about 5 times the effort for enabling multiple languages. We now have to go for a customisation to core. This bug is a very good example where developers are not able to recognise they made a mistake while designing a solution.

I need the i18n "Domain name only" option to INCLUDE "with language fallback." Anyone willing to help $$, as well as help apply the patch to make this whole system work?

Drupal 6.14 and i18n...

Thanks!

Is a patch in #19 still applicable? Does it preserve the same URLs for the interfaces of different languages?

subscribe