Can't enable more than one language

I have the same problem with 4.7.0-beta3 when trying to enable two languages (English and Italian).
Here is my little workaround for this problem.
As it is my first patch to Drupal, I am not sure if it is the best one, but at least it works on my system.

IMHO the problem is that the checkbox for enabling/disabling a language returns the language key (when checked) or null,
while the enabled field in the DB is an int flag (i.e. 0/1).
So I convert the flag in locale.module before storing it into DB:

--- locale.module 2006-01-09 20:22:04.000000000 +0100
+++ locale.module.new 2006-01-11 15:45:27.666902400 +0100
@@ -274,6 +274,7 @@
// Save changes to existing languages
$languages = locale_supported_languages(FALSE, TRUE);
foreach($languages['name'] as $key => $value) {
+ $edit['enabled'][$key] = $edit['enabled'][$key] ? 1 :0; // !!! This line has been added
if ($edit['sitedefault'] == $key) {
$edit['enabled'][$key] = 1; // autoenable the default language
}

Hope this helps

I'm sorry.
It was my first post here and I unintentionally changed the title.

I have done further testings and I am quite sure that Xiang is right:
on 4.7.0-beta3 you can enable only the default language, because the others are always disabled.
Note that it's not a display problem: they are actually disabled into the DB.
I think it is good to raise the priority of this issue to normal, as I understood from Dries' blog that localization is an important functionality :)

I have reviewed my previous workaround, so this patch is different from what you see on #1.

About the issue :

The values returned by the checkboxes to enable/disable a locale are as follows :

- the locale when checked (e.g. 'en' for English)
- an empty string when unchecked

(The same happens with the checkboxes to enable/disable themes, so it is correct).

The locale_admin form is processed by locale_admin_manage().
The issue seems to be caused by the call to db_query, which stores the locale enabled flags into locales_meta.enabled that is an integer.
The implicit type cast to integer of a string like 'en', 'it', or an empty string always result in 0.
IMHO the cleanest thing to do here might be to explicitly cast the string to boolean on the call to db_query(), so that it can be safely converted to an integer by db_query() itself.

I tested the patch and it works, but it is my first patch. Therefore a good review is surely required.

RiccardoR

Isn't an isset() cleaner than casting a string to a boolean? Would that work, or not quite?

What exactly is the value of $edit['enabled'][$key]?

Thanks Dries.
Indeed isset() is cleaner and works great : change attached.

The value of $edit['enabled'][$key] is the locale id ('en', 'it', etc.)
or an empty string.

Concerning the second issue reported by Xiang (the language selector is not present on user account editing page),
I think it is because $form['locale'] defined on locale_user() :

    $form['locale'] = array('#title' => t('Interface language settings'), '#type' => 'fieldset', '#weight' => 1);
    $form['locale_l']['language'] = array('#type' => 'radios', '#title' => t('Language'), '#default_value' => $user->language, '#options' => $languages['name'], '#description' => t('Selecting a different locale will change the interface language of the site.'));
    return $form;

is overwritten on system_user() with the user timezone selector:

      $form['locale'] = array('#type'=>'item', '#title' => t('Locale settings'), '#weight' => 6);
      $form['locale']['timezone'] = array(
        '#type' => 'select', '#title' => t('Time zone'), '#default_value' => strlen($edit['timezone']) ? $edit['timezone'] : variable_get('date_default_timezone', 0),
        '#options' => $zones, '#description' => t('Select your current local time. Dates and times throughout this site will be displayed using this time zone.')
      );
    }
    return $form;

I also noticed that the user timezone selector is not enclosed by a border (frameset), like it was on 4.6.5.
I think both the issues can be fixed with a slight change to system_user() :

cvs diff -u -- system.module (in directory D:\CVS\drupal\modules\)
Index: system.module
===================================================================
RCS file: /cvs/drupal/drupal/modules/system.module,v
retrieving revision 1.277
diff -u -r1.277 system.module
--- system.module	5 Jan 2006 23:35:34 -0000	1.277
+++ system.module	12 Jan 2006 22:56:26 -0000
@@ -198,8 +198,8 @@
 
     if (variable_get('configurable_timezones', 1)) {
       $zones = _system_zonelist();
-      $form['locale'] = array('#type'=>'item', '#title' => t('Locale settings'), '#weight' => 6);
-      $form['locale']['timezone'] = array(
+      $form['timezone'] = array('#type'=>'fieldset', '#title' => t('Locale settings'), '#weight' => 6);
+      $form['timezone']['timezone'] = array(
         '#type' => 'select', '#title' => t('Time zone'), '#default_value' => strlen($edit['timezone']) ? $edit['timezone'] : variable_get('date_default_timezone', 0),
         '#options' => $zones, '#description' => t('Select your current local time. Dates and times throughout this site will be displayed using this time zone.')
       );

The user language selector is now displayed and the timezone selector has a border. I tested it, but...
Please, an experienced reviewer is really appreciated. Thanks.

This patch fixes the two issues on localization reported by Xiang :

- It is not possible to enable more than one interface language on "administer localization".
( locale_admin_manage() : the value of $edit['enabled'][$key] can be null or a locale id (like 'en', 'it', ecc.),
but it is written into the database as an integer, which value is always 0 ).

- Users cannot select their preferred interface language on "edit user account";
( $form['locale'] returned by system_user() overwrites $form['locale'] returned by locale_user().
The two functions are invoked as hooks by _user_forms() and their return values are merged by calling
array_merge() ).

This patch, moreover, fixes a cosmetic issue, which I discovered while testing "edit user account" :
- The timezone selector is not framed by a fieldset, as it was on 4.6.5.

Concerning cosmetic, in my opinion "edit user account" would be cleaner if "Interface language" and "Timezone" were displayed in the same frame :

Locale settings :
-- Interface language
-- Timezone

I tried to do that, but it seems very complicated, because the hook_user functions of two different modules (locale and system) are involved. Does someone have any opinion or suggestion on this subject?

Please load the patch and review it. Many thanks.

If you say that the value can be NULL/string, then the isset() will work. But previously you said it is ''/string, which would not work. But since you tested and it works, it's NULL/string, right?

Thanks Cvbge!
It's actually NULL/string.
I will be more careful with terminology next time.

The patch appears to be malformed?

Re-rolled patch

Dries, Killes,
I guess this is the right move now.
as I said it is my first patch...
Am I missing something?
Thank you.

Just to confirm that this patch worked for me on the cvs version:
locale_system_1.patch (2.26 KB)

I confirm it too!

Committed to HEAD. Thanks.