As part of the automated interface translation Locale module needs to import available languages from a translation server and download gettext files and import the included translations. This process can be derived from the import process as done by Localization Update module.

Comments

webflo’s picture

Project: Drupal core » Drupal 8 Multilingual Initiative sandbox
Version: 8.x-dev »
Component: locale.module » Code
Status: Active » Needs review

This patch is only for fetching and parsing the localization server xml.

webflo’s picture

FileSize
6.03 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch import-available-language-data-1632384-1.patch. Unable to apply patch. See the log in the details link for more information. View
Gábor Hojtsy’s picture

Status: Needs review » Needs work

Tests look good, pretty much covers the whole thing :) Functionality also looks good, so just some comments:

+++ b/core/modules/locale/locale.fetch.incundefined
@@ -1,9 +1,78 @@
+/*
+ * @file
+ * Fetch and parse the list of available languages from a translation server.
+ * e.g. localize.drupal.org
+ */

File comment should be on one line.

+++ b/core/modules/locale/locale.fetch.incundefined
@@ -1,9 +1,78 @@
+/**
+ * Get server information
+ */

Should have . at line end :) Mostly a problem at all other places for comments too in the patch :)

+++ b/core/modules/locale/locale.fetch.incundefined
@@ -1,9 +1,78 @@
+function locale_get_server($server) {
+  // Fetch up to date information if available
+  if (!empty($server['server_url']) && $fetch = locale_fetch_server($server['server_url'])) {
+    $server = array_merge($server, $fetch);
+  }
+  // If we have an update url this is ok, otherwise we return none
+  if (!empty($server['update_url'])) {
+    return $server;
+  }
+  else {
+    return FALSE;
+  }
+}

The locale_get.... and locale_fetch... might need to be in a namespace. Although we did move lots of stuff out of locale, it still has some different things, translation, import/export and now automation for the import is added. So some "namespacing" with the function names would be good.

+++ b/core/modules/locale/locale.fetch.incundefined
@@ -1,9 +1,78 @@
 /**
- * @todo
- * Based on l10n_update_get_server().
+ * Parses the XML of l10n server translation.
+ *

l10n server translation is not very specific. Its a language list with some language metadata. :)

webflo’s picture

Status: Needs work » Needs review
FileSize
6.56 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch import-available-language-data-1632384-2.patch. Unable to apply patch. See the log in the details link for more information. View

Thanks for you review. Fixed the comments.

webflo’s picture

The new namespace for this functionality is locale_translation.

Gábor Hojtsy’s picture

Is that namespace not taken or will these fit nicely in there?

Sutharsan’s picture

The only use of this namespace are two variables. That does not seam a problem to me.

  • 'locale_translation_plurals'
  • 'locale_translation_javascript'
Gábor Hojtsy’s picture

Ok then, we'll revisit namespacing anyway :)

Sutharsan’s picture

FileSize
5.3 KB
PASSED: [[SimpleTest]]: [MySQL] 36,922 pass(es). View

Patch reworked to apply to 8.x without being dependent on #1627006: Collect project information for translation update.

Sutharsan’s picture

FileSize
1.46 KB
5.65 KB
PASSED: [[SimpleTest]]: [MySQL] 36,915 pass(es). View

Changes: Some documentation added.

Sutharsan’s picture

Project: Drupal 8 Multilingual Initiative sandbox » Drupal core
Version: » 8.x-dev
Component: Code » locale.module

Changing project/component to D8 locale module

webflo’s picture

Category: task » feature
Gábor Hojtsy’s picture

I think it looks good. We should figure out if we want to push forward with this vs. actually implementing YAML export on the server, which is also useful/proposed for the automation to be done after #1632236: Convert built-in language list to CMI. We might want to make the server return YAML first and get that deployed on l.d.o, and use our YAML parser here.

penyaskito’s picture

Can we assume that YAML export in l.d.o is not gonna happen before D8? What are the next steps here once that noone is pushing for #1632236: Convert built-in language list to CMI?

Gábor Hojtsy’s picture

Status: Needs review » Postponed

I'd say this is lower priority compared to other issues where we actually deal with project identification and .po file downloads such as #1627006: Collect project information for translation update and #1632384: Import available language list from translation server. Our first priority is to solve downloading .po files for properly identified projects, and then if we have time and can somehow solve this, then we can update the language list from localize.drupal.org. Otherwise we'll just make the installer display all languages known locally (this list was previously synced with l.d.o), and then let our existing code set it up locally and use it. Not having project .po file downloads is the main pain. Not being able to update the locally known available language list is the last concern :)

Therefore I think we should postpone this on the other two issues.

Gábor Hojtsy’s picture

Title: Import available language data and translations form translation server » Import available language list form translation server

Retitled to be more clear as to what we are postponing.

Kristen Pol’s picture

Title: Import available language list form translation server » Import available language list from translation server
Gábor Hojtsy’s picture

Status: Postponed » Needs work
Issue tags: -sprint

Given the above explained circumstances and this being at the low end of our priority list, I have little hope this would even happen in Drupal 8, so I don't think it makes sense to keep on a postponed state even on the Drupal 8 D8MI sprint focus list.

jair’s picture

Issue tags: +Needs reroll
InternetDevels’s picture

Issue summary: View changes
Status: Needs work » Needs review
Issue tags: -Needs reroll
FileSize
5.67 KB
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 84,980 pass(es). View

Here's a reroll.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.