During bootstrap function language_initialize() (in language.inc) is calling the function language_list() (in bootstrap.inc). At that moment the ‘locale.module’ is not yet loaded, even if it is enabled.

As a result the static variable $languages is set to the default language only and other languages are not available. It looks like the ‘if (module_exists('locale'))’ is called too early.

The result is that other, optional, languages are not available. You can see the problem when enabling the ‘language block’ and try to translate a node after clicking the ‘translate’ tab. Only the default language is available. Also the ‘translate interface’ (admin/build/translate) is not functional.

Attached a patch that change the ‘module_exists’ into a variable_get(‘language_count’). This variable will be set by the locale.module and deleted when uninstalling it. It looks like a safe way for me to detect the existents of the locale.module even while not yet loaded.

I must admit that I’m not very familiar with the bootstrap-process and can’t find the reason why this is not working anymore. Last time I checked a devel-version (19 July) it was working well. I searched trough old CVS message but I couldn't find a change that has this mis-function as result.

Nick

CommentFileSizeAuthor
#2 languages_2.patch625 bytesdesbeers
languages.patch598 bytesdesbeers
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Gábor Hojtsy’s picture

Well, we had the variable_get there before, and it caused problems with the language list settings page. If you check there with your patch applied, you will see that the page is broken if you have only one languages. We might need to do something else there, as it is indeed a correct observation that locale module will not be available this soon in the bootstrap, so we should not check for the locale module here already.

desbeers’s picture

FileSize
625 bytes

I saw the broken ‘language settings page’ now. Locale_languages_overview_form() needs to know ‘all’ languages, not just the ones that are enabled. When disabling a language it still exists in the system; e.g. is not deleted. While testing my first patch that was my expected behavior (language deleted) but when ‘re-adding’ the disabled language I saw what is broken. The language already exists. I was testing with only 2 languages.

I changed the ‘language_list’ function again to check for both cases now. First the ‘variable_get’ and second a ‘module_exists’.

It seems to solve the problem and a patch for this attached. I tested with 1, 2 and 3 languages and with disabling/enabling the locale module and the various languages.

It looks to me it’s unavoidable to start the language-system so early in bootstrap in case of (at least) cached pages so this looks like the right solution for me.

Another option would be to copy part of the language_list function straight into locale_languages_overview_form() (in local.inc) and not to use the ‘language_list’ function at all but that looks very un-clean to me because is duplicating a lot of code.

Gábor Hojtsy’s picture

Status: Needs review » Fixed

Yes, one option would have been to duplicate code. But I am fine with making language_list() more versatile, so I committed this fix. Thanks!

Anonymous’s picture

Status: Fixed » Closed (fixed)