Unable to download translation updates

How strange. Does file upload (e.g. image upload) work without problems? This uses the same temporary files directory.

Can you describe the steps that leads to this problem. Preferrably on a fresh drupal install. As far is I can see, the temporary path is only used when exporting po files (form Drupal to your computer).

Got the exact same problem on D7.24.
The 1.x branch is working, no problem there.

@elsteff1385: that would be the problem of #2124931: Update l.d.o syncing for d.o update of project data I think.

I don't have this issue on a fresh install of D7.26 with 2 languages (english and french), just "Localization update" installed and "Admin_menu" (to have a module with a translation available). It works like a charm.

@jbrown and @elsteff1385, were you migrating i18n_update from 7.x-1 to 7.x-2.x-dev ? If yes, what does admin/config/regional/language/update have for "Translations directory" ? Just in case it would be related to #2182987: Warnings when migrating from 7.x-1.0-beta3 to 7.x-2.x-dev

I fixed this problem by creating sites/all/translations and setting correct permissions. If using Aegir (hostmaster project), this directory is not automatically provided (yet).

The translations storage directory is only created after you have visited the Translation updates page at admin/config/regional/language/update and entered a directory there.

Closing the issue due to lack of activity. Feel free to re-open the issue if required.

I have the same issue on drupal 7.26
visiting /admin/config/regional/language/update doesn't create automatically the directory.
I have to create manually the 'translations' directory and give 'write' permission to '(other)'

@rei did you upgrade from 7.x-1.x or did a fresh install of 7.x-2.x? Is there a message in the watchdog that the directory is not writable?

Please try this patch. It improves the checks and reporting in the installation/update process. It also creates the translations directory when submitting the settings form.

I did fresh install
upon install, I get this message in the watchdog:
"The directory sites/all/translations does not exist or is not writable."

The patch #11 is not working,
upon install the module and everytime I click 'save configuration' button on /admin/config/regional/language/update, I get this message:
"The directory sites/all/translations does not exist or is not writable."
I already set 777 at sites/all directory, but it can't create the directory automatically

I think we have to change the directory to "sites/default/files/translations" can you give it a try to change the translations directory configuration. Alternatively use "path/to/your/files/directory/translations"

still can't create directory even change to alternative path

The directory sites/default/files/translations does not exist or is not writable.
The directory sites/all/translations does not exist or is not writable.
The directory sites/default/translations does not exist or is not writable.
The directory /sites/all/custom/translations does not exist or is not writable.

@rei, did you try these directories with the #11 patch being applied or without it. If you can, please use the patch and try the upgrade.

yes, I tried with the patch with fresh install

I can confirm the problem of rei, tried the #11 patch on a clean install, ran update.php and flushed the cache... Still not working. Manually there's no problem importing a .po file.

Patch #11 applied.

I use 7.x-2.x-dev in a fresh installation but the error persists.

If I add manually /sites/all/translations with 755 permission it works.

@giupenni, did you get an error message during installation? Do you have a message like "The directory ... does not exist or is not writable" in the watchdog?

The same error of the first post.

I did install the module on pantheon and I did get an error. But I also discovered the root of the problem and fixed it in the code. Further I made the creation of the files directory bullet-proof (so I hope).

If you are still having this problem make sure your translations directory is writable by web server. The easiest way to check it is submitting configuration form on admin/config/regional/language/update page.

The problem occurs when the module is installed by Drush because in typical configuration that directory will not be owned by webserver.

I installed with drush and got the error "The directory sites/all/translations does not exist or is not writable". Changing directory to "sites/default/files/translations" fixed it (#13).

I had the same error as #2359481: File temporary://fileAVBFD could not be copied, because the destination directory translations:// is not configured correctly. (marked as a duplicated of this issue).
The issue rely on a wrong assumption that the "translations" folder is created on this two cases:

• Admin Setting form save
• Module install

There are cases when such actions "never happens": take as an example the case of an automatic building of the environment where the database is cloned from other instances (we're using Platform.sh), in such case the "install" hook never get invoked on the cloned site.

The attached patch ensures that, before downloading a bunch of translations, the directory exists. If it could not be created no files will be downloaded (thus avoiding to display tons of messages about "File temporary://fileAVBFD could not be copied" ..).

Worked for me =)

I got this problem when updating from 7.x-1.x to 7.x-2.x using Drush.

Some strange things happen in the update process. First in l10n_update_update_7200():

if (!variable_get('l10n_update_download_store', '')) {
    variable_set('l10n_update_download_store', 'sites/all/translations');
}

This seems redundant, as after that several directories are tried for writability, and on success l10n_update_download_store is set to that directory. If for some reason neither of these succeed, l10n_update_download_store is set to sites/all/translations anyway in the next update function:

function l10n_update_update_7201() {
  if (!variable_get('l10n_update_download_store', '')) {
   variable_set('l10n_update_download_store', 'sites/all/translations');
  }
}

That last one seems dangerous, as in 7200 you just tested that this directory was unwritable.

Re. #29, I see many usage of file_prepare_directory() immediately before writing a file. But checking before every write operation would be an overkill, in my opinion. It is very unlikely that the the file system may change between very file that is downloaded. To, I agree this is a good intermediate solution.

Re #31, I've created a new issue for this report #2544892: problem when updating from 7.x-1.x to 7.x-2.x using Drush.

Re #32: The patch is checking the destination directory just before the module starts the download of translation files. Thus it should not overkill the entire download process with useless file_prepare_directory() calls.
Any possibility to have the patch committed?
Cheers

The patch was committed, but not yet shared.

With last dev I still the same problem.

@giupenni, this issue in now closed. I you want to re-open, please provide details to reproduce the error.

I dont understand why is used the path 'sites/all/translations' as default instead of '/sites/default/files/translations'.

It makes sense on a Multi Site but it is this the most common case?

@harald_ the path is configurable. You can change it. This path was changed because it is the path that is used for interface translations in Drupal 8 core.

Make sure to look at admin/reports/status and see that you have tmp and private configured. Without those, translation updates won't download.

With multisite + nginx, I had to indicate the directory under sites/_SITEDIR_/files/translations:

drush -l _SITEDIR_ vset l10n_update_download_store 'sites/_SITEDIR_/files/translations'

Not sure about the reasons, but I am also using ACLs to grant www-data user and the files directory has real chmod 777 permissions...

Hello,

Just for people that might struggle with the same problem: migrating a multi-site Drupal from 9 to 10, I've placed each site in its own Drupal installation. Each site was thus inside sites/default ... but I forgot to update settings.php accordingly (notably the config_sync_directory setting).