Updated: Comment #0

Problem/Motivation

1.) When adding a new language on admin/config/regional/language, the language files are not downloaded.

The site is installed in English and French language is added:

language-list-siteEN-added-FR.jpg

sites/default/files/translation is empty.
sites/default/files/languages doesn't exist.

When installing the site in French, on admin/config/regional/language it is indicated that 77.43% of the strings are translated.

The same happens with other languages.

2.) When installing the site in another language than in English, the downloaded .po files are those for Drupal 7:

On an installation in French:
sites/default/files/translation > drupal-7.0.fr.po
sites/default/files/languages > fr_V1w2Fpm_cFVONuoPeAW5VNt_uVVj_2p-Lr7fiyzv_6w.js

On an installation in Finnish:
sites/default/files/translation > drupal-7.0.fi.po
sites/default/files/languages > fi_uzcPQ6tyBuW6lg6wdOrZKWz_V1d8uL_1p5Hg_1D1f9I.js

User interface changes

At the moment, when adding a new language, all the strings on admin/config/regional/translate/translate are empty:

translation-siteEN-translationFR.jpg

I suppose that if the language files were downloaded, some of them would be translated as they are when the site is installed in French:

translation-siteFR.jpg

API changes

None.

Related

Comments

Issue tags:+D8MI, +sprint, +language-ui

Tagging.

I can confirm, that when I add spanish, I have 0% UI strings translated. I thought #1804688: Download and import interface translations should have made it work automatically.

I have the same issue.

I add:
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

There are different issues happening here, the concrete issue @wusel is experiencing is being tracked at #1914070: Improve version fallback for install language..

Because this issue has some interesting use cases and not sure if everything is covered, I'm against marking this as duplicate.

Priority:Normal» Major

That wrong version translations are downloaded and no translations are downloaded in some cases sounds like to me at least a major.

If you add a language to an existing site, a po file is downloaded using the \Drupal::VERSION. Currently this is 8.x-dev for all, and therefore it will not download any translation. No po files are provided for dev's. Edit the 'version' in the info.yml file to test.

Status:Active» Closed (works as designed)
StatusFileSize
new439.36 KB

As Sutharsan correctly mentioned, there are no po Files for 8.x-dev.

If you change

const VERSION = '8.0-alpha2';
in Drupal.php

and adapt local_project table it works perfectly, see screenshot for some proof.

I think that the Issue of wusel is exactly #1914070: Improve version fallback for install language.

Status:Closed (works as designed)» Active

So there are two problems here. #1914070: Improve version fallback for install language. resolves the installer problem. It does not resolve the language addition problem, and that should still work with this. Making it required to change your version is not the way to solve this IMHO. The code for adding language should work with dev releases.

Title:Language file problems when installing a site in a different language than English or when adding a new languageTranslations not downloaded when adding a new language
Issue tags:+Needs issue summary update

Retitling for the remaining problem. The install problem is handled in #1914070: Improve version fallback for install language.. Needs issue summary update to reduce it only to the remaining problem.

@#3

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

Yeah this bug is about adding another language on that install (or an English install). Is *that* downloading a translation now? :)

There are two bugs:

- like #11: the first language did not download the correct version of the po file:
drupal downloads the file "drupal-8.0-alpha2.de.po" and NOT "drupal-8.0-alpha4.de.po", which we can find at http://ftp.drupal.org/files/translations/8.x/drupal/drupal-8.0-alpha4.de.po

- if I then add a language like "Hungarian", I read at "admin/config/regional/language" for this installed language Hungarian: "Interface translation = 0/6253 (0%)" and there is no po file at \sites\default\files\translations\

Hint:
If I look at admin/reports/dblog I can find: "Translation file not found: http://ftp.drupal.org/files/translations/8.x/drupal/drupal-8.0-dev.hu.po."

Wusel

Yeah the download of alpha2 is "expected" ATM. About two weeks ago it was downloading Drupal 7 translations. As per the current code it will download translations for the first published version of that series (alpha2 is the first with a tarball). So once betas are out, beta1 translations would be downloaded for all betas. Once rcs are out, rc1 translations, etc. This needs some serious improvements on the server side to make more intelligent. See #2113957: Build server side version fallback system for translations and #2113955: Rely on proper server side version fallback for translations for those.

As for the adding new language is where this bug is at, look at the title and issue summary :)

The version of the translation to be downloaded is based on the VERSION constant. When writing the code for the version fallback I assumed this string would reflect the version of the tarball, but it doesn't. I've downloaded the D8-apha4 tarball, and found out it has const VERSION = '8.0-dev'; (in core/lib/Drupal.php). I should have been set to '8.0-alpha4' in order to load the corresponding translation file.

Yeah, this would need the same fallback logic that the installer has *for dev* versions no?

Hm, I wasn't paying proper attention to the issue subject/title. I was talking about the 'during installation' situation. A solution is that VERSION is set before and reset after creating the release. (unless the below packaging script can handle this).

When enabling a language, the project version is used. This version is based on the date in the .info.yml file. The packaging script is not working correctly yet, as it does not include the right version in the info.yml files. For example system.info.yml contains version: VERSION. This should be version: 8.0-alpha4. #1963092: Convert .info file rewriting in packaging plugins to deal with D8 .info.yml files is about dealing with info.yml files.

Yeah, well even if that is made to work it will never work on -dev versions when adding a language, so we need that code applied to when adding a new language. Sounds like it may be just guessing a version if we don't know the core version reusing the same function as in the installer? :)

Without version info, the installer code falls back to hardcoded "8.0-alpha2" version. That can be done. It its simplest form we use "8.0-alpha2" (or 4) if no version info is available. But only for core. I we want to fallback to multiple version (8.0 > RC1 > beta1 > alpha2), the impact is bigger. Currently we can not handle multiple 'check if translation version x exists' requests.

So our other option is we suggest people to install git_deploy?

Issue summary:View changes

Updated issue summary.

I checked that the last alpha (8.0-ALPHA7) had const VERSION = '8.0-dev'.

What's next in this issue?

@penyaskito: the installer has special code to take fallback version numbers in case of dev versions. This was not added to the regular locale update code though (with the expectation that alpha/beta/rc releases would have actual version numbers instead of dev). To support this dev approach, we would need to have similar fallback code in the runtime path as well like in the installer.

I'll try to make some progress on this while at DDD in Szeged.

The logic for version fallback in core/includes/install.core.inc:

function install_get_localization_release($version = \Drupal::VERSION)

Its calling function, "install_check_translations", loops through its results, which would be the same logic required when adding a new language. This logic could be added each time a new language is saved, but perhaps the localizations should be downloaded automatically only when setting or changing the default language. If it were added only when the default language is set, then the correct place to add this would be in function "language_system_regional_settings_form_submit" in core/modules/language/language.module.

Does this sound correct, or should localizations be downloaded every time any language is added?

The logic for language fallback during Drupal installation is in code that is for core only. The place where translations are downloaded when languages are added is used more broadly. It looks like it is used for translation downloads for core as well as all other modules and themes. Should the language-fallback code be extended (when languages are added) to include checking and downloading localizations for all modules and themes?

Status:Active» Postponed

The fallback code was written specifically for installing Drupal and downloading the drupal core translation (and only core, not contrib modules). It has an hardcoded fallback scheme. It would be silly to use a hardcoded scheme beyond the installation process. Once update module is available (after installation), it is used to provide the latest release version of a module (and core).

The root of the problem in this issue is that info.yml files currently do not provide a version. In the file you find "version: VERSION" instead of for example: "version: 8.0-alpha10". This is taken care of by #1963092: Convert .info file rewriting in packaging plugins to deal with D8 .info.yml files. Pending this issue, I mark the current issue as postponed. I expect that the current issue is resolved once the .info(.yml) file issue is fixed.