I was under the impression that when I set a "Store downloaded files" directory, another installation with the same directory defined in "Store downloaded files" will use the files stored there instead of downloading the translation files again.

This is not the case, as I installed a predefined language on one installation, and it saved the translation files to the set directory (sites/all/translations) as expected. After this, when I set the same directory on another installation and installed the same predefined language, the files were downloaded again from the translation server and overwrote the previous files (that the first installation had saved there). The files in the directory were not used instead of downloading them again.

Have I misunderstood this feature, or is this a bug?

Comments

Gábor Hojtsy’s picture

Category: bug » support
Status: Active » Fixed

Sounds like you have not set your setting properly on admin/config/regional/language/update to only use local files on the second site. It is probably set to use local and remote files, right? Please reopen if you did set it to local files only, and its still overwritten with remote files. That would be a bug indeed.

Tor Arne Thune’s picture

Ah, okay, I understand now. Thank you for explaining. My misunderstanding was that I thought by selecting 'Local files and remote server' for all sites, the translation updater would use the local files if they existed and were as recent as those on the remote server. If not, then the new files would be downloaded.

It's still a valuable feature for sure, but now I must choose one of the sites to be the "downloader of translations", which would have to be the most frequently used site.

In what situations would the option 'Local files and remote server' be used? Since it always uses the remote server if it is available. I suppose only when the remote server is not reachable?

Gábor Hojtsy’s picture

Status: Fixed » Postponed (maintainer needs more info)

Hm, were all files downloaded (again) and overwritten on the second run? If not all, some files might have been actually updated inbetween (if some times lasted between the two points that is :).

Tor Arne Thune’s picture

Yes, all files were overwritten. The files in the translation directory all had their creation time changed, so they were overwritten. The updates were minutes apart, so no new translations were released in between.

Gábor Hojtsy’s picture

Title: Language installer downloads and overwrites identical existing translation files » Download and overwrite happening if local & download method used
Category: support » bug
Status: Postponed (maintainer needs more info) » Active

Well, that is probably a bug in this mode, but anyway, your solution for now is to use the right mode, where it only uses local files at all times. Reopening for this.

Tor Arne Thune’s picture

I will post some file system proof of the overwrites later.

Sutharsan’s picture

Status: Active » Postponed (maintainer needs more info)

I can not reproduce this situation. I have the following setup:
* example.com
- it's own database
- Drupal 7.2
- Various modules (Views, Token, Ctools, Coder) (non 'dev' releases)
- L10n Update 7.x-1.x-dev
- Three languages: Englisch, Dutch, German
- L10n Update configuration:
- Update source: Local files and remote server
- Store downloaded files: sites/all/translations
* foo.example.com
- shared code with example.com
- it's own database
- Two languages: Englisch, Dutch
- L10n Update configuration:
- Update source: Local files only
- Store downloaded files: sites/all/translations

1. Translations updated at example.com (downloading, installing)
2. Files automatically stored in sites/all/translations
3. Update translations at foo.example.com -> Installing... -> all translations states now green.
No files were overwritten in sites/all/translations, no files were downloaded.

I do however see other unexpected behavior. At example.com some modules have an older translation date than at foo.example.com. When I change the Update source configuration from 'Local files and remote server' to 'Local files only', refresh the translation update status and update the translations, the latest is taken from disk. I guess the system favors remote over local when set the update source to 'Local files and remote server'. Even if the local file is more recent. But I expect no problems from this if only one site is set so 'Local files and remote server' and all others which share the same directory are set to 'Local files only'.

Tor Arne Thune’s picture

But I expect no problems from this if only one site is set so 'Local files and remote server' and all others which share the same directory are set to 'Local files only'.

But this expects that all sites in the multisite installation have the same modules enabled. I can definitely see a use case (my own) where several relatively different sites share a code base with very different modules enabled (all sites with modules in common). This necessitates a remote localization update on different sites in the multisite installation (updating their enabled modules), making it impossible to leave just one site with update source set to 'Local files and remote server'.

The solution would probably be to get l10n_update to prefer local files over remote files, if they are of the same date, or if the remote repository is newer than the local repository, obviously download that one.

Gábor Hojtsy’s picture

@1V: if you assume different modules, why not use different download paths for the multisites?

Tor Arne Thune’s picture

Many enabled modules are common to all subsites, so sharing a translation download location for all sites makes sense. It would save the hassle of downloading the exact same translation file for all sites. If I understood your question correctly.

So if I have one subsite with views, l10n_update and rules
and another subsite with views, l10n_update and i18n
it would be good to download the translation files for views and l10n_update only one time.
I can not set the second subsite to 'Local files only' (having the other subsite set to download 'remote files' only), because I need it to download the translation update of i18n when an update is available on localize.drupal.org. I can not set the first subsite to 'Local files only' either (having the other one download 'remote files'), because then it would not download the remote translation updates for rules.

Tor Arne Thune’s picture

Status: Postponed (maintainer needs more info) » Closed (cannot reproduce)

I can no longer reproduce this bug, as in when local files are available, the module does not download the same files from localize.drupal.org. The files in question were already downloaded by another subsite in the multi-site installation. So everything works as expected. Thanks for listening!

user@domain:~/Public/Sites/drupal$ drush vget l10n_update_check_mode -l http://domain4.local
l10n_update_check_mode: 3
user@domain:~/Public/Sites/drupal$ drush vget l10n_update_download_store -l http://domain4.local
l10n_update_download_store: "sites/all/translations"

user@domain:~/Public/Sites/drupal$ ls -Al sites/all/translations
-rw-r--r-- 1 www-data www-data   8509 2011-06-24 20:11 link-7.x-1.0-alpha3.fr.po
-rw-r--r-- 1 www-data www-data   1437 2011-06-24 20:11 link-7.x-1.0-alpha3.nb.po
-rw-r--r-- 1 www-data www-data    755 2011-06-24 20:12 media_youtube-7.x-1.0-alpha5.nb.po

user@domain:~/Public/Sites/drupal$ sudo -u www-data drush l10n-update -l http://domain4.local
Fetching update information for all projects / all languages.
Found 2 projects to update.
Updating translation.
Downloading and importing files.
WD locale: 1 disallowed HTML string(s) in sites/all/translations/link-7.x-1.0-alpha3.fr.po
The translation was successfully imported. There are 0 newly created translated strings, 58 strings were updated and 0 strings were removed.
One translation string was skipped because it contains disallowed HTML.
Imported translation file sites/all/translations/link-7.x-1.0-alpha3.fr.po.
WD locale: 1 disallowed HTML string(s) in sites/all/translations/link-7.x-1.0-alpha3.nb.po
The translation was successfully imported. There are 0 newly created translated strings, 13 strings were updated and 0 strings were removed.
One translation string was skipped because it contains disallowed HTML.
Imported translation file sites/all/translations/link-7.x-1.0-alpha3.nb.po.
The translation was successfully imported. There are 0 newly created translated strings, 7 strings were updated and 0 strings were removed.
Imported translation file sites/all/translations/media_youtube-7.x-1.0-alpha5.nb.po.
Successfully imported translations.

user@domain:~/Public/Sites/drupal$ ls -Al sites/all/translations
-rw-r--r-- 1 www-data www-data   8509 2011-06-24 20:11 link-7.x-1.0-alpha3.fr.po
-rw-r--r-- 1 www-data www-data   1437 2011-06-24 20:11 link-7.x-1.0-alpha3.nb.po
-rw-r--r-- 1 www-data www-data    755 2011-06-24 20:12 media_youtube-7.x-1.0-alpha5.nb.po
Gábor Hojtsy’s picture

Just for the record, I agree that using local files is best when they look newer or current compared to localize.drupal.org. So looks like it currently works right as per your validation. Thanks!

iwayMan’s picture

Version: 7.x-1.x-dev » 7.x-2.1
Issue summary: View changes
Status: Closed (cannot reproduce) » Active

A recent fix (Duplicate PO files saved to translations directory) re-introduced the behavior described in this issue.

On a multisite install, with "Drupal translation server and local files" translation source setting and a shared translations folder, the translation files are re-downloaded and overwritten every time l10n_update runs on different sites.

The behavior should be to use the local PO file when it is newer than the remote file.

Sutharsan’s picture

In #2877995: Local files won't import in install profile I identified a problem with determining the source of translations. This might be caused by local override of the 'l10n_update_check_mode' variable. Do you use this to get local files on production and remote files on, for example, develop?

Can you share some data with me: SELECT data FROM `cache` WHERE `cid` = 'l10n_update_status';