Problem/Motivation

When a drupal core release comes out the accompanying translation files will not be available immediately. It takes at least a few hours (up to days) before translation files of the (point) release. During this time the installation of Drupal in a non English language fail with a requirements fault "The %language translation is not available."

Currently the installer (install_get_localization_release()) only provides a fallback in case the release is a development snapshot. For example 8.0-dev falls back to 7.0 and 8.2-dev falls back to 8.1.

The main problem we need to solve is the user experience. We need to make sure that a translation is found. Even a quite old translation would be acceptable. Once the Interface translation (local) and Update module are installed and enabled, a more intelligent update mechanism is available and more recent translations will be downloaded and applied.

Proposed resolution

* Implement simple (hardwired) fallback rules for core translation releases.
* Allow for multiple suggestions and multiple 'download' attempts.

Manual test of the patch

Normal scenario

  1. Start the Drupal 8 installation as usually at example.com/install.php
  2. In the first installation step, select a non-English language. (e.g. Dutch (Nederlands))
  3. Stop in the second step (select installation profile).
  4. Observe the translation file downloaded into sites/default/files/translations.
  5. This file should be: drupal-8.0-alpha3.nl.po (or perhaps drupal-8.0-alpha4.nl.po)

To re-run the test, remove any *.po file from the sites/default/files/translations directory and re-start the installation procedure at example.com/install.php

Alternative scenarios

  1. Change the drupal VERSION string in core/lib/Drupal.php [updated, file moved] (line 82) from '8.0-dev' to any of the following versions: '8.0-alpha1', '8.0-alpha2', '8.0-alpha4', '8.0-beta1', '8.0', '8.4'.
  2. Start the Drupal 8 installation as usually at example.com/install.php
  3. In the first installation step, select a non-English language. (e.g. Dutch (Nederlands))
  4. Stop in the second step (select installation profile).
  5. Observe the translation file downloaded into sites/default/files/translations.
  6. This file should be:
    • 8.0-alpha1 -> drupal-7.0.nl.po
    • 8.0-alpha2 -> drupal-8.0-alpha2.nl.po
    • 8.0-alpha4 -> drupal-8.0-alpha3.nl.po
    • 8.0-beta1 -> drupal-8.0-alpha2.nl.po
    • 8.0 -> drupal-7.0.nl.po
    • 8.4 -> drupal-7.0.nl.po
  7. Prepare for the next test by removing all files from the sites/default/files/translations directory.
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Sutharsan’s picture

IMO this is must have:

8.0-unstable* -> 7.0
8.0-alpha* -> 7.0
8.0-beta* -> 7.0
8.0-rc* -> 7.0
8.n -> 8.0 -> 7.0
8.x-dev -> 8.0 -> 7.0

This is nice to have:

8.0-unstable* -> 7.0
8.0-alpha* -> 7.0
8.0-beta* -> 7.0
8.0-rc-n -> 8.0-rc-[n-1] -> 8.0-rc-1 -> 7.0
8.n -> 8.[n-1] -> 8.0 -> 7.0
8.n-dev -> 8.[n-1] -> 8.0 -> 7.0

Edit: modified 8.n-dev nice fallback

Sutharsan’s picture

Status: Active » Needs work
FileSize
3.41 KB

This is as far as I got...
install_get_localization_release() calculates several release alternatives. Somewhere between the above must and nice scenario's.

Sutharsan’s picture

Category: feature » task
Status: Needs work » Needs review
Issue tags: +Needs manual testing
FileSize
10.3 KB
8.96 KB

This is a working patch. It uses this fallback scenario:

8.0-unstable* -> 7.0
8.0-alpha* -> 7.0
8.0-beta* -> 7.0
8.0-rcn -> 8.0-rc[n-1] -> 7.0
8.n -> 8.[n-1] -> 7.0
8.n-dev -> 8.[n-1] -> 7.0

Testing this patch is difficult since we only have one version (8.x-dev) available now. Only by injecting a Drupal 7 version number into the call to install_get_localization_release() this patch can be tested. The example below (line 2005, 2006 in install.core.inc) will result in downloading and installing the drupal 7.9 release into the translations directory.

  // Build URLs for the translation file and the translation server.
  $releases = install_get_localization_release('7.10-dev');

Some test scenario's:

  • 7.10-dev will fall back to 7.9
  • 7.0-rc3 will fall back to 7.0-rc3
  • 7.0-rc5 will fall back to 7.0-rc4 (rc5 does not exist)
  • 7.20 will download 7.19 (7.19 is the latest current release)
  • 8.alpha2 will fall back to 7.0
  • 8.1 will fall back to 7.0

Tip: to test the fallback you can check the content of the translations directory, no need to compleet the full installation and check the translation status page. Whipe the content of the translations directory before you start a new installation test.

[edit] blockquote replaced by code

Sutharsan’s picture

I realised I missed one scenario: What to fall back to in the first hours/days after 8.0 is released. We can fall back to 8.0-rc1 or perhaps hardcode another rc-release. I propose this additional rule:

8.0 -> 8.0-rc1 -> 7.0

Status: Needs review » Needs work

The last submitted patch, install-language-version-fallback-1914070-3.patch, failed testing.

Gábor Hojtsy’s picture

For the 8.0 release I think we'll need to hard-code the prior RC release indeed. Otherwise the fallback rules look good to me :)

Sutharsan’s picture

Status: Needs work » Needs review
FileSize
1.22 KB
9.17 KB

#4 fallback rule added.

8.0-unstable* -> 7.0
8.0-alpha* -> 7.0
8.0-beta* -> 7.0
8.0-rcn -> 8.0-rc[n-1] -> 7.0
8.0 -> 8.0-rc1 -> 7.0
8.n -> 8.[n-1] -> 7.0
8.n-dev -> 8.[n-1] -> 7.0
YesCT’s picture

Status: Needs review » Needs work
+++ b/core/includes/install.core.incundefined
@@ -1536,39 +1536,131 @@ function install_check_localization_server($uri) {
+ * @todo Modify description.
  * In case core has a development version we fall back to the latest stable
  * release. e.g. 8.2-dev falls back to 8.1. 8.0-dev falls back to 7.0. Fallback
  * is required because the localization server only provides translation files
  * for stable releases.

I think the rules are good. Can we just make this description match those? And take care of this todo?

+++ b/core/includes/install.core.incundefined
@@ -1536,39 +1536,131 @@ function install_check_localization_server($uri) {
+ *  Array of release data. Each array element is an associative array with:
+ *   "core": Core compatibility version. e.g.. 8.x
+ *   "version": Release version. e.g. 8.1

spacing is off here.

If looking to make a list, 1354 talks about that.
http://drupal.org/node/1354#lists

+++ b/core/includes/install.core.incundefined
@@ -1536,39 +1536,131 @@ function install_check_localization_server($uri) {
+function install_get_localization_release($version = VERSION) {

needs @param with type (string?)

+++ b/core/includes/install.core.incundefined
@@ -1536,39 +1536,131 @@ function install_check_localization_server($uri) {
+  // Regular stable releases (no 'rc', 'beta', etc.):
+  //   Release alternative: Current release, no fallback.
+  //   Release alternative: Previous minor release. E.g. 8.2 falls back to 8.1.
+  //   Release alternative: Release candidate: E.g. 8.0 falls back to 8.0-rc-1.

comments confusing.

the first release alternative... is no alternative.

Also. E.g. is confusing, lets just spell it out (I had to google it): for example.

Also, one uses a : and the other .

Anyway: I'd suggest:

+  // Regular stable releases (no 'rc', 'beta', etc.):
+  //   Release alternative: Previous minor release (e.g. 8.2 falls back to 8.1).
+  //   Release alternative: Release candidate (e.g. 8.0 falls back to 8.0-rc-1).
+++ b/core/includes/install.core.incundefined
@@ -1536,39 +1536,131 @@ function install_check_localization_server($uri) {
+      // Dev releases:
+      //   Release alternative: Previous point release. E.g. 8.2 falls back to
+      //   8.1.

this format is weird. just put it on one line (well, wrap it at 80 chars).

+++ b/core/includes/install.core.incundefined
@@ -1536,39 +1536,131 @@ function install_check_localization_server($uri) {
+      case'dev':

missing space after case.

+++ b/core/includes/install.core.incundefined
@@ -1536,39 +1536,131 @@ function install_check_localization_server($uri) {
+ * Extract version information from a drupal core version string.

Verb tense should probably be: Extracts

+++ b/core/includes/install.core.incundefined
@@ -1536,39 +1536,131 @@ function install_check_localization_server($uri) {
+ * Examples of supported versions: 8.0, 8.1, 8.0-dev, 8.0-unstable1, 8.0-alpha2,
+ * 8.0-beta3, 8.0-rc4.
+ *
+ * @param string $version
+ *   Version info string. E.g. "8.0-alpha2"

merge with the @param?

+++ b/core/includes/install.core.incundefined
@@ -1536,39 +1536,131 @@ function install_check_localization_server($uri) {
+ * @return array
+ *   Associative array of version info:
+ *     "major": Major version. E.g. "8"

similar to previous note about 1354 standard for list.

+++ b/core/includes/install.core.incundefined
@@ -1536,39 +1536,131 @@ function install_check_localization_server($uri) {
+        ([a-z]+)  # Release extra text. E.g. "alpha".

Release extra text (e.g. "alpha").

+++ b/core/includes/install.core.incundefined
@@ -1728,23 +1820,40 @@ function install_import_translations(&$install_state) {
+  // Get the version number from the translation file located in the
+  // translations directory. We pick the first file which matches the
+  // installation language. This does not necessarily result in the right file
+  // so we check if at least the major version number is available.

huh? sounds contradictory.

what happens if the first file found that matches the language does not patch the major version number?

Is this just noting what version the file was that was picked?

some comments more inline in the code might help.

+++ b/core/includes/install.core.incundefined
@@ -1928,11 +2040,14 @@ function install_check_translations($install_state) {
   // Check if the desirered translation file is available and if the translation
   // server can be reached, or in other words if we have an internet connection.

lets update this to match what's happening and also correct the spelling of desired. I think this can clarify by saying that means "online" and that is what that variable is for.

Check if any of the desired translation files are available and if the translation server can be reached. In other words, check if we are online and have an internet connection.

(but wrapped at 80 chars)

----

I can do some of this. Will need checking by @Sutharsan to see if I got the meanings correct.

YesCT’s picture

Status: Needs work » Needs review
FileSize
7.4 KB
9.87 KB

Tried to clarify comments and fix standards for them.
Patch attached.
More questions to follow though.

YesCT’s picture

+++ b/core/includes/install.core.incundefined
@@ -1536,39 +1536,134 @@ function install_check_localization_server($uri) {
+ *   Array of release data. Each array element is an associative array with:
+ *   - core: Core compatibility version (e.g., 8.x).
+ *   - version: Release version (e.g., 8.1).

is "core" really the core major version number? the 8 in 8.2.

is "version" really the core minor version number? the 2 in 8.2.

or is "core" literally "8.x" for 8.0, 8.1 and 8.2 etc.

and version is the release of a translation alternative?

Perhaps some actual examples might be useful in the description.

like: for a core version of 8.2, an array might be returned:
[0][core]="8.x"
[0][version]="8.2"
[1][core]="8.x"
[1][version]="8.1"
[2][core]="8.x"
[2][version]="8.0"
[3][core]="8.x"
[3][version]="8.0-rc"
[4][core]="8.x"
[4][version]="7.0"

+++ b/core/includes/install.core.incundefined
@@ -1536,39 +1536,134 @@ function install_check_localization_server($uri) {
+ *   8.0-beta3, and 8.0-rc4).
+ *
+ *
+ * @return array

oops. extra newline.

+++ b/core/includes/install.core.incundefined
@@ -1728,23 +1823,41 @@ function install_import_translations(&$install_state) {
+  // Get the translation files located in the translations directory.
+  $files = locale_translate_get_interface_translation_files(array('drupal'), array($langcode));
+  // We pick the first file which matches the installation language.
+  $file = reset($files);
+  $filename = $file->filename;
+  preg_match('/drupal-([0-9a-z\.-]+)\.' . $langcode . '\.po/', $filename, $matches);
+  // Get the version information.
+  if ($version = $matches[1]) {
+    $info = _install_get_version_info($version);
+    // Picking the first file does not necessarily result in the right file. So
+    // we check if at least the major version number is available.
+    if ($info['major']) {
+      $core = $info['major'] . '.x';
+      db_insert('locale_project')
+        ->fields(array(
+          'name' => 'drupal',
+          'project_type' => 'module',
+          'core' => $core,
+          'version' => $version,
+          'server_pattern' => $install_state['server_pattern'],
+          'status' => 1,
+        ))
+        ->execute();
+      module_load_include('compare.inc', 'locale');
+      locale_translation_check_projects_local(array('drupal'), array($install_state['parameters']['langcode']));

what is the insert doing? why?

why only get the first file?

what happens if it's the wrong file? is it just as if an out of date translation is imported, or is no translation imported?

YesCT’s picture

Status: Needs review » Needs work
YesCT’s picture

this issue title mentions install, but will this also fallback for when languages are added to an already existing site? that would be really nice for usability testing, to have adding a language actually automatically import the translation (even an old translation) for the ui.

Kartagis’s picture

I think in the patch on http://drupal.org/node/1914070#comment-7110328, on the line 'version' => $info['major'] - 1 . '.0', '.0' should vary according to the latest minor version.

K.

Sutharsan’s picture

Answering #10

+++ b/core/includes/install.core.incundefined
@@ -1536,39 +1536,134 @@ function install_check_localization_server($uri) {
+ *   Array of release data. Each array element is an associative array with:
+ *   - core: Core compatibility version (e.g., 8.x).
+ *   - version: Release version (e.g., 8.1).

"core" is the core compatibility version number as defined in a .info.yml file. So literally "8.x" for 8.0, 8.1 and 8.2 etc. It is not the major version number.
"version" is the core release version number as defined in a .info.yml file. (Not necessarily the .info.yml of this installation, but that was the hole point of this fallback of course.) It is not the minor version number.
Each record with core/version info is a fallback alternative, sorted in order of preference, the most preferred first.

The example in #10 is not correct. What about this:
Detected version is "8.2":
[0][core]="8.x"
[0][version]="8.2"
[1][core]="8.x"
[1][version]="8.1"
[2][core]="8.x"
[2][version]="8.0-rc1"
[3][core]="7.x"
[4][version]="7.0"

Different scenario, detected version is "8.2-dev":
[0][core]="8.x"
[0][version]="8.1"
[1][core]="8.x"
[1][version]="8.0"
[2][core]="8.x"
[2][version]="8.0-rc1"
[3][core]="7.x"
[4][version]="7.0"

+++ b/core/includes/install.core.incundefined
@@ -1728,23 +1823,41 @@ function install_import_translations(&$install_state) {
+  // Get the translation files located in the translations directory.
+  $files = locale_translate_get_interface_translation_files(array('drupal'), array($langcode));
+  // We pick the first file which matches the installation language.
+  $file = reset($files);

We pick the first file because we expect only one translation file per language. If there are multiple, either the person who installs has manually place another file there or the installation profile was shipped with multiple. The installation system will not download a second file from the same language. The worst that can happen in either case is that we import an outdated translation file. The next time the translations get updated, this will corrected.

+      db_insert('locale_project')
+        ->fields(array(
+          'name' => 'drupal',
+          'project_type' => 'module',
+          'core' => $core,
+          'version' => $version,
+          'server_pattern' => $install_state['server_pattern'],
+          'status' => 1,
+        ))
+        ->execute();

This insert is to tell the automatic import process which project is installed for which a translation should be imported. An API-function would be nicer, but none is available.

Answering #12

this issue title mentions install, but will this also fallback for when languages are added to an already existing site?

This code is only used for installation and not intended for runtime. At runtime we use version data from the update module, but at install time this is not available. At runtime we currently only use one translation version and one check for the presence of a translation file for each project/language combination.

Answering #13

+ // All releases may a fallback to the previous major release (e.g., 8.1 falls
+ // back to 7.0).
+ $releases[] = array(
+ 'core' => $info['major'] - 1 . '.x',
+ 'version' => $info['major'] - 1 . '.0',
);
I wish we knew the latest version of the previous release. But remember this is the very last resort and will only be used as long as there is no rc1 release. This exactly what the current code does.

Kartagis’s picture

I made that comment and I still think the minor version should be calculated somehow, because I occasionally git pull drupal 8 and install it just to be able to port my module successfully. I sometimes install in my own language as well to see if anything breaks. I couldn't help noticing the translation for cron options mostly includes 0 sec as translation is an ongoing process and those strings probably weren't translated at that time, and also new strings might be added from time to time.

YesCT’s picture

Status: Needs work » Needs review
Issue tags: -Needs manual testing, -D8MI, -language-ui
Sutharsan’s picture

Status: Needs review » Needs work
Issue tags: +Needs manual testing, +D8MI, +language-ui

The last submitted patch, install-language-version-fallback-1914070-9.patch, failed testing.

wusel’s picture

As of #2030537-3: Translations not downloaded when adding a new language:

If I install the alpha 2 or a alpha2-xxx.dev of the D8-core and select German language during the installation, then I get the german D7-po-file (drupal-7.0.de.po) but nor D8-po-file. A German D8-po-file is available on the translation server of d.o. at http://ftp.drupal.org/files/translations/8.x/drupal/drupal-8.0-alpha2.de.po

Wusel

jair’s picture

Issue tags: +Needs reroll
pp’s picture

Status: Needs work » Needs review
pp’s picture

I rerolled the patch. The $server_available variable is nowhere used, I deleted it.

Gábor Hojtsy’s picture

Issue tags: +sprint
Gábor Hojtsy’s picture

pp’s picture

shnark’s picture

Issue tags: -Needs reroll

Patch applied, removing needs reroll tag.

shnark’s picture

[duplicate comment]

Gábor Hojtsy’s picture

I think the needs manual testing tag pretty much applies to this still.

I'm not entirely sure what kind of automated tests to provide. We can do a set of tests to install in a foreign language. There is already a test to install in German(?) I believe. We can seed such a test with different files and see if it loads it or not. Anybody wanna help with this?

Sutharsan’s picture

Rerolled the patch. \Drupal::VERSION now used instead of VERSION.

Sutharsan’s picture

This patch adds a unit test for install_get_localization_release() which calculates the fallback versions.
The todo's will be resolved in the next patch which will add fallback versions for alpha and beta releases too.

Sutharsan’s picture

Version fallback now includes alpha and beta releases too. Tests have been modified to incorporate this too. While working on this, I've simplified code and comment of install_get_localization_release().

The modified fallback schema:

8.0-unstable[n] -> 7.0
8.0-dev -> 8.0-rc1 -> 8.0-beta1 -> 8.0-alpha2 -> 7.0
8.[n>1]-dev -> 8.[n-1] -> 7.0
8.0-alpha[n] -> 8.0-alpha[n-1] -> 7.0
8.0-beta[n] -> 8.0-beta[n-1] -> 7.0 
8.0-rcn -> 8.0-rc[n-1] -> 8.0-beta1 -> 8.0-alpha2 -> 7.0
8.0 -> 8.0-rc1 -> 7.0
8.[n] -> 8.[n-1] -> 7.0
8.[n]-dev -> 8.[n-1] -> 7.0

More fallback details can be found in the test class: InstallerTranslationVersionUnitTest

[edit] dev-fallback added

Status: Needs review » Needs work
Issue tags: -Needs manual testing, -D8MI, -sprint, -language-ui

The last submitted patch, install-language-version-fallback-1914070-31.patch, failed testing.

Sutharsan’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work
Issue tags: +Needs manual testing, +D8MI, +sprint, +language-ui

The last submitted patch, install-language-version-fallback-1914070-31.patch, failed testing.

Sutharsan’s picture

Status: Needs work » Needs review
FileSize
1.98 KB
34.59 KB

Manual installation failed in an endless loop because FileTranslation::findTranslationFiles() could not detect filenames like 'drupal-8.0-alpha2.nl.po' only 'drupal-8.0.nl.po'.

Sutharsan’s picture

The endless loop I mentioned in #35 was caused by a code failure. The filename of the downloaded file was not recognised. To prevent an endless loop and I've added an extra check in the translation requirements check. Because this is an error that can not be solved by the user, I did not add a new error message, but reused the existing.

Sutharsan’s picture

Assigned: Unassigned » Sutharsan
Status: Needs review » Needs work

Patches in #35, #36 look weird. Something gone wrong with re-rolling?

Sutharsan’s picture

Assigned: Sutharsan » Unassigned
Status: Needs work » Needs review
FileSize
17.58 KB

Thanks to the interdiffs in #35 and #36 it was easy to make a proper patch.

Sutharsan’s picture

Issue summary: View changes

Updated issue summary.

Sutharsan’s picture

Issue summary: View changes

Updated issue summary.

Sutharsan’s picture

Updated the issue summary with manual test scenario's.

jpd4nt’s picture

Hi. Reviewing and testing this patch.

The test examples work as specified.

Looking at the patch, is there any reason why it does not loop through all the minor version?

Say if alpha5 came out, the po file it would get is the 7.x version, not the alpha3 which is newer.

This could reduce admin over head for new releases at the expensive of install time length.

Also which is probably a separate issue, none of the release bundles use version other than -dev so this patch is not being used to work out the version number from alpha releases.

Gábor Hojtsy’s picture

@jpd4nt: so this is happening in the installer. We want to avoid doing too many HTTP requests in the installer, because that takes a lot of time. Ideally, we would have one endpoint on the server, where we tell the version number and it directs us to the right file, or all the possible version numbers would have a file that have exported status of translations at that phase, so you would be sure to get the translation right from the first load. But that requires more server side solutions, and we'd ideally need a stop-gap solution at least for now that lets people test Drupal 8 with new translations :)

jpd4nt’s picture

Hi Gabor.

As a stop gap solution to provide translation, this patch seems to work nicely.

Those two points were the only ones that jumped out at me when reading through.

bserem’s picture

I can confirm that patch in #38 works for me too.

penyaskito’s picture

Status: Needs review » Reviewed & tested by the community

I did a code review and didn't find any nitpick. But the way this patch adds a lot of value in terms of readability and understandability of the logic behind.
The only question that came to my mind was #40, but Gábor already argumented on #41.

Some users already reported that they tested this, so I'm very tempted to RTBC.

Sutharsan’s picture

Sutharsan’s picture

Issue summary: View changes

Updated issue summary.

alexpott’s picture

Status: Reviewed & tested by the community » Needs work
  1. +++ b/core/includes/install.core.inc
    @@ -1686,39 +1686,152 @@ function install_check_localization_server($uri) {
    +function _install_get_version_info($version) {
    +
    +  $info = array();
    +
    

    Unused variable $info

  2. +++ b/core/includes/install.core.inc
    @@ -2178,9 +2317,13 @@ function install_check_translations($install_state) {
       if ($translations_directory_exists && $readable && $writable && $translation_available) {
    +    // Download the translation file and check if the file name is recognized
    +    // by the installer. Throw an error if it failed.
         $translation_downloaded = install_retrieve_file($translation_url, $translations_directory);
    +    $files_found = install_find_translations();
    +    $translation_file_found = isset($files_found[$langcode]);
     
    -    if (!$translation_downloaded) {
    +    if (!$translation_downloaded || !$translation_file_found) {
    

    I don't think this change is necessary to fix the problem and is unrelated.

  3. +++ b/core/modules/system/lib/Drupal/system/Tests/Installer/InstallerTranslationVersionUnitTest.php
    @@ -0,0 +1,122 @@
    +}
    \ No newline at end of file
    

    Missing line at end of file

YesCT’s picture

Status: Needs work » Reviewed & tested by the community

I might be missing something, but where is the version set? I wanted to see what the alphas thought their version was.
Drupal.php moved to core/lib/Drupal.php and I dont see VERSION in that file.
grepping for other stuff... didn't find it either.

andypost’s picture

Status: Reviewed & tested by the community » Needs work

@YesCT const VERSION = '8.0-dev'; in core/lib/Drupal.php

Sutharsan’s picture

Status: Needs work » Needs review
FileSize
2.06 KB
0 bytes

All remarks by alexpot in #49 processed.
@YesCT, alternatively you can change the version in all *.info.yml files to the desired version number.

vijaycs85’s picture

Status: Needs review » Reviewed & tested by the community

Thanks @Sutharsan. The interdiff looks fixing exactly what we need to address in #46. Back to RTBC now.

vijaycs85’s picture

Status: Reviewed & tested by the community » Needs work

sorry for the quick RTBC on a 0 bytes patch :( @Sutharsan can you please check and attach the real patch please? :)Thanks @alexpott for checking it and letting me know :)

Created new issue #2102069: Throw validation error on 0 bytes file upload. to not to test 0 bytes patches.

Sutharsan’s picture

Status: Needs work » Needs review
FileSize
16.71 KB

Sorry :S

vijaycs85’s picture

Thanks again @Sutharsan. The code looks good to me. I just send the test only patch(at #1970534-12: Patch testing issue )to see if it fails without patch. Can RTBC once it is RED :)

vijaycs85’s picture

Status: Needs review » Reviewed & tested by the community

As per https://qa.drupal.org/pifr/test/642163 the tests failing. So RTBC. Thanks @Sutharsan.

Gábor Hojtsy’s picture

Gábor Hojtsy’s picture

Issue tags: -Needs manual testing
Gábor Hojtsy’s picture

Xano’s picture

Gábor Hojtsy’s picture

Priority: Normal » Major

Elevating to major because Drupal 8 keeps downloading Drupal 7 translations instead of Drupal 8 translations, and that is ridiculous. We cant get people test the actual Drupal 8 translations without this.

alexpott’s picture

Title: Improve version fallback for install language. » Change notice: Improve version fallback for install language.
Status: Reviewed & tested by the community » Active
Issue tags: +Needs change record

Committed 7b08fd6 and pushed to 8.x. Thanks!

Fixed some minor spelling mistakes on commit

diff --git a/core/includes/install.core.inc b/core/includes/install.core.inc
index 0eb4c4e..b4ee2b3 100644
--- a/core/includes/install.core.inc
+++ b/core/includes/install.core.inc
@@ -1746,7 +1746,7 @@ function install_get_localization_release($version = \Drupal::VERSION) {
   // - extra_number: The number part of "extra" (e.g., "2").
   $info = _install_get_version_info($version);

-  // Check if version is a regular stable release (no 'rc', 'beta', 'alhpa,
+  // Check if the version is a regular stable release (no 'rc', 'beta', 'alpha',
   // 'dev', etc.)
   if (!isset($info['extra_text'])) {
     // First version alternative: the current version.
@@ -1851,7 +1851,7 @@ function _install_get_version_info($version) {
       (?P<minor>[0-9]+)    # Minor release number.
     )             #
     (             #
-      -           # - separator for "extra" verion information.
+      -           # - separator for "extra" version information.
       (?P<extra>   #
         (?P<extra_text>[a-z]+)  # Release extra text (e.g., "alpha").
         (?P<extra_number>[0-9]*)  # Release extra number (no separator between text and number).
alexpott’s picture

Forgot to add my spelling fixes... so reverted and recommitted :( d3d34a5 and pushed to 8.x. Thanks!

Gábor Hojtsy’s picture

Title: Change notice: Improve version fallback for install language. » Improve version fallback for install language.
Status: Active » Fixed
Issue tags: -Needs manual testing, -Needs change record, -sprint

https://drupal.org/node/2113953 is the change notice I wrote up. This change has significance for all the people trying out Drupal 8 and as said above is not yet the final solution. Eg. even after Drupal 8 alpha3 is released, it will still download the alpha2 translations, unless the fallback patterns are manually updated in the code. We either need a release process where that is maintained or a server side solution. So far the people I talked about preferred a server side solution. Opened #2113957: Build server side version fallback system for translations and #2113955: Rely on proper server side version fallback for translations for that.

Gábor Hojtsy’s picture

Yay, did I say that although this is not a final version, this will be an enabler for us to try out things and find bugs. :D See I found a pretty big one right away: #2114069: Routing / tabs / actions lack way to attach context to UI strings :)

wusel’s picture

@#19

I have installed drupal-8.0-alpha4 and drupal-8.x-dev_2013_10_24 on xampp 1.8.2-2 and Win7-64bit.

Thank you all, it now downloads the file "drupal-8.0-alpha2.de.po", if I choose German during install.

Wusel

wusel’s picture

Issue summary: View changes

file version is in moved.

Status: Fixed » Closed (fixed)

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

hansfn’s picture

Status: Closed (fixed) » Active

Version fallback is currently broken by the move to semantic version numbers.

Reopen until #2349263: Add support for semantic version numbers in installer is fixed.

Sutharsan’s picture

Status: Active » Closed (fixed)
Related issues: +#2349263: Add support for semantic version numbers in installer

Not sure why this issue needs to be reopened. The other issue pretty well covers the problem that fallback scenarios added in this patch don't work anymore. Reverting status.

hansfn’s picture

This was opened because it's much more likely that other people with the same problem find this issue (if it is open), than the other issue that I filed. I just wanted to avoid duplicate issues ... Anyway, thx for adding the related issue.