Decouple UI translation language information from language list schema

The idea, and quick overview of the code looks good to me.

The patch looks good and the issue's goal seems reasonable to me too. Should we consider dropping the languages table altogether?

Well, you still owe us the update function :)

Overall looks good, very minor nitpicks. I'll test everything tonight.

+++ b/modules/locale/locale.install
@@ -250,6 +232,29 @@ function locale_update_8000() {
+  $languages = db_query('SELECT * from {languages}')->execute();

Why not DBTNG? Can we have "FROM" (uppercase) at least?

+++ b/modules/locale/locale.install
@@ -250,6 +232,29 @@ function locale_update_8000() {
+  $plurals = $javascript = array();

I've been whipped by @DamZ for using chained assignments, it seems it's an unrecommended practice :)

-26 days to next Drupal core point release.

+++ b/modules/locale/locale.install
@@ -250,6 +232,30 @@ function locale_update_8000() {
+  $languages = db_query('SELECT * FROM {languages}')->execute();

Tested the upgrade path, the line above is wrong: the execute() invocation should be removed, as db_query() already returns an iterable result. Any reason not to convert this to DTBNG?

<?php
  $languages = db_select('languages', 'l')
    ->fields('l')
    ->execute();
?>

-27 days to next Drupal core point release.

I ain't sure what the current politics are: should we provide test coverage for the update function?

I'm going to test the upgrade path again tonight to be sure everything is ok :)

Now everything seems ok. I had a hard time testing the upgrade path due to:

#1331350: [Upgrade path broken] Entity module not enabled during D8 upgrade
#1331370: [Upgrade path broken] Stored include paths need to be updated to /core before running the upgrade path

Since you mentioned problems testing the upgrade path due to other issues, I checked upgrade-filled and noticed it does not have locale module enabled at all. This upgrade is straightforward and has had manual testing, so I've committed and pushed this to 8.x.

However I've opened #1336170: Add locale module to upgrade tests as a critical task to add some locale data and/or locale-specific upgrade path testing since I don't want to add any more untested updates to 8.x.

EDIT: I think variable change should be in lock_*() to prevent possible data-loss in race condition, same could be doem for JS

This change require change notification because table field are removed and new variable introduced

+++ b/core/includes/gettext.incundefined
@@ -401,24 +401,17 @@ function _locale_import_one_string($op, $value = NULL, $mode = NULL, $lang = NUL
+          $locale_plurals[$lang] = array(
+            'plurals' => $nplurals,
+            'formula' => $formula,
+          );
+          variable_set('locale_translation_plurals', $locale_plurals);

variable introduced

+++ b/core/modules/locale/locale.installundefined
@@ -97,19 +99,6 @@ function locale_schema() {
-      'plurals' => array(
-        'type' => 'int',
-        'not null' => TRUE,
-        'default' => 0,
-        'description' => 'Number of plural indexes in this language.',
-      ),
-      'formula' => array(
-        'type' => 'varchar',
-        'length' => 128,
-        'not null' => TRUE,
-        'default' => '',
-        'description' => 'Plural formula in PHP code to evaluate to get plural indexes.',
-      ),
       'domain' => array(
         'type' => 'varchar',
         'length' => 128,
@@ -130,13 +119,6 @@ function locale_schema() {

@@ -130,13 +119,6 @@ function locale_schema() {
         'default' => 0,
         'description' => 'Weight, used in lists of languages.',
       ),
-      'javascript' => array(
-        'type' => 'varchar',
-        'length' => 64,
-        'not null' => TRUE,
-        'default' => '',
-        'description' => 'Location of JavaScript translation file.',

this fields been removed

@Gabor:

What about these lines from #23?

I think variable change should be in lock_*() to prevent possible data-loss in race condition, same could be doem for JS

First off, I've read the comment in email and consider later time edits not good for discussion (easy to miss like I did)

Yes, I supposed so. I have been lucky to read the comment when already edited.

[...] I don't hink we should focus on building a temporary workaround here and instead work on stuff that matters.

Ok, thanks for the update :)