Problem/Motivation

Since #1914070: Improve version fallback for install language. at least Drupal 8 will download alpha2 translations properly. Even if Drupal 8 alpha5 is out. (Then once a beta1 is out, that will be the new base for translation downloads and then rc1, but even if rc3 is out).

Proposed resolution

Ideally we'd have a server side version fallback system where if we ask for 8.x-dev downloads, it would *redirect* us to the latest version downloads (so we know the version downloaded from the file name and can track).

1. Work out the server side solution in #2113957: Build server side version fallback system for translations
2. Remove fallback logic from core as necessary and rely on server side fallback. Remove tests for fallback logic.

Remaining tasks

Commit.

User interface changes

None.

API changes

None.

#1914070: Improve version fallback for install language.
#2113957: Build server side version fallback system for translations
#2555021: Create branch symlink to latest translation

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Gábor Hojtsy’s picture

Issue summary: View changes

Update with server side issue link.

catch’s picture

Issue summary: View changes
Issue tags: -revisit before beta

Not sure why this is tagged with revisit, there's nothing controversial here?

Gábor Hojtsy’s picture

Gábor Hojtsy’s picture

basic’s picture

Issue summary: View changes
basic’s picture

Edit: moving this from #2555021: Create branch symlink to latest translation

I've added the following rewrites to nginx:

    rewrite '^/files/translations/(.+)/(.+)/drupal-([0-9]\.([0-9]\.)?).+\.([a-z]{2})\.po$' https://ftp.drupal.org/files/translations/$1/$2/drupal-$3x.$5.po redirect;
    rewrite '^/files/translations/(.+)/(.+)/(.+)-([0-9]\.([0-9]\.)?x)-(.+)\.(.+)\.([a-z]{2})\.po$' https://ftp.drupal.org/files/translations/$1/$2/$3-$4-$6.x.$8.po redirect;

I've manually created a single symlink for drupal, and views, to use as tests:

$ curl -I http://ftp.drupal.org/files/translations/6.x/views/views-6.x-2.29.ca.po
HTTP/1.1 302 Moved Temporarily
Server: nginx/1.8.0
Content-Type: text/html
Location: https://ftp.drupal.org/files/translations/6.x/views/views-6.x-2.x.ca.po
...
$ curl -I http://ftp.drupal.org/files/translations/8.x/drupal/drupal-8.0.0-beta16.ca.po
HTTP/1.1 302 Moved Temporarily
Server: nginx/1.8.0
Content-Type: text/html
Location: https://ftp.drupal.org/files/translations/8.x/drupal/drupal-8.0.x.ca.po
japerry’s picture

Status: Postponed » Active

resetting to active because #2113957: Build server side version fallback system for translations is done. That will pretty much gut most of the work done in #1914070: Improve version fallback for install language. and replace it with either the release or dev version of drupal8.

japerry’s picture

Status: Active » Needs review
FileSize
7.24 KB

Here is a first crack at fixing this issue, based on the changes we've made on the localization server. I have a feeling that _install_prepare_import() could use some cleanup, but is only sorta related to this issue.

Status: Needs review » Needs work

The last submitted patch, 7: rely_on_proper_server-2113955-7.patch, failed testing.

Gábor Hojtsy’s picture

Priority: Normal » Major
Issue tags: +sprint

Changes look good to me. Also less code to maintain, yay :) Looks like the only fail is in InstallerTranslationVersionUnitTest which makes sense given we would not do the translation fallback on the client anymore.

Sutharsan’s picture

Removing the unit test of install_get_localization_release(). This function was removed in #7.

Gábor Hojtsy’s picture

Status: Needs work » Needs review

Go testbot!

Gábor Hojtsy’s picture

Issue tags: +Needs manual testing

Needs manual testing given that we cannot do automated testing of this, it relies on configuration of the server side. Looks good in code review. Also less code to maintain and update yay!

Gábor Hojtsy’s picture

Tweeted here too asking for manual testing https://twitter.com/gaborhojtsy/status/641265982816821248

Gábor Hojtsy’s picture

Status: Needs review » Reviewed & tested by the community
Issue tags: -Needs manual testing

I manually tested this applying to both 8.x-dev and 8.0.0-beta15 and both worked. From then on its up to the server side to work right and send the right file. While that is still refined in #2113957: Build server side version fallback system for translations we can get on with this as far as I see. Thanks @japerry, @Sutharsan!

Gábor Hojtsy’s picture

Issue summary: View changes

Status: Reviewed & tested by the community » Needs work

The last submitted patch, 10: rely_on_proper_server-2113955-10.patch, failed testing.

Gábor Hojtsy’s picture

MigrateTermNodeTest did not complete fail does not sound related.

Gábor Hojtsy’s picture

Status: Needs work » Reviewed & tested by the community
webchick’s picture

Status: Reviewed & tested by the community » Fixed
FileSize
127.05 KB
174.17 KB
Syss-MacBook-Air:8.x webchick$ git diff --stat --cached
 core/includes/install.core.inc                     | 154 ++-------------------
 .../InstallerTranslationVersionUnitTest.php        | 145 -------------------
 2 files changed, 12 insertions(+), 287 deletions(-)

That is lovely. :)

I tested this two ways, one with my wifi turned on and one with it turned off.

With it turned on:

French installation instructions

$ ls sites/default/files/translations/
drupal-8.0.0-dev.fr.po

With it turned off:

Translation server offline error message

That error message needs some work, both grammar-wise ("requires to contact" => "requires contacting") and SafeMarkup-wise (the link HTML is shown as escaped plain text). However, that's not part of this patch so we can fix it in a normal follow-up.

Committed and pushed to 8.0.x. YEAH! :D

webchick’s picture

  • webchick committed 50585b2 on 8.0.x
    Issue #2113955 by Sutharsan, japerry, Gábor Hojtsy, basic: Rely on...
Gábor Hojtsy’s picture

Issue tags: -sprint

Yay, thanks!

Status: Fixed » Closed (fixed)

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