When running the D8 upgrade in a language other than English, the locale system is used, which includes locale string tables. So we need to move corresponding updates to locale.inc (update_prepare_d8_language)

Actually, this was causing a lot of issues with this patch, which atm needs some hacking around locale queries for the update process not to crash #1785086: Introduce a generic API for interface translation strings
(Which means if we fix this one, that queries could be simplified.)

This is a very small and straight forward patch, most of the lines are renumbering the other locale updates.

#3 drupal8.locale-update.3.patch1.65 KBsun
PASSED: [[SimpleTest]]: [MySQL] 42,127 pass(es). View
locale_update_tables-01.patch3.52 KBJose Reyero
PASSED: [[SimpleTest]]: [MySQL] 42,133 pass(es). View
Members fund testing for the Drupal project. Drupal Association Learn more


Gábor Hojtsy’s picture

Status: Needs review » Reviewed & tested by the community
Issue tags: +D8MI

Looks very simple and straightforward. Should be RTBC if comes back green. It will fire it to needs work automatically otherwise :)

sun’s picture

Status: Reviewed & tested by the community » Needs work
+++ b/core/includes/update.inc
@@ -399,6 +399,20 @@ function update_prepare_d8_language() {
+    // Since updating in a language other than English will trigger the locale
+    // translation system, we need to take care of locale tables here.
+    if (db_table_exists('locales_target')) {
+      // Add column to track customized string status to locales_target.
+      db_add_field('locales_target', 'customized', $customized_spec);

1) Let's add a !db_field_exists() condition after the db_table_exists() condition.

2) The second comment should actually come first, and it looks like we can combine and shorten the first into it then.

+++ b/core/includes/update.inc
@@ -399,6 +399,20 @@ function update_prepare_d8_language() {
+      $customized_spec = array(
+          'type' => 'int',

1) Why is this $customized_spec vs. just $spec?

2) Too much indentation?

+++ b/core/modules/locale/locale.install
@@ -513,24 +513,11 @@ function locale_update_8005() {
-function locale_update_8006() {

@@ -734,7 +721,7 @@ function locale_update_8011() {
-function locale_update_8013() {
+function locale_update_8011() {

Let's just remove the update 8006 without renumbering, please.

sun’s picture

Status: Needs work » Needs review
1.65 KB
PASSED: [[SimpleTest]]: [MySQL] 42,127 pass(es). View
Gábor Hojtsy’s picture

Status: Needs review » Reviewed & tested by the community

I think we want to renumber updates instead of leaving holes, but I'm fine either way, if this is preferred. It does not matter as long as the main bug is fixed, which the update patch still does. Thanks!

webchick’s picture

Category: feature » task
Status: Reviewed & tested by the community » Fixed

I think the hole is probably fine for now; most likely we'll do a big round of update clean-up before beta.

Confirmed that this matches the schema defined in locale_schema(), so committed and pushed to 8.x. Thanks!

sun’s picture

As this in #2 showed:

-function locale_update_8013() {
+function locale_update_8011() {

There was a hole before this patch already.

There's nothing wrong with removing updates. Renumbering the others only causes havoc - especially for sites that are running on HEAD already - for absolutely no reason, other than pedantic silliness of "But 2 comes after 1!". We should stop renumbering updates.

Automatically closed -- issue fixed for 2 weeks with no activity.