For sites multi-language implementing l10n_update for one-time translation updates, a local repository for downloaded translations seems to make a lot of sense.

One option would be to create a translations folder in the same vein as $_ROOT/distro/$_THIS_CORE/keys -- see shared-translations-core.octopus.patch

Another option would be to share downloaded translations at the individual platform level in something like sites/default/files/translations -- see shared-translations-platform.octopus.patch

Thanks as always for your attention

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

mrP’s picture

Priority: Normal » Minor

Setting to minor as this impacts current functionality in no way.

omega8cc’s picture

We have had shared (central) translation for D6 core in the past, but we have stopped adding them, since it no longer makes any sense, in our opinion, because it covered only Drupal core and no contrib anyway. Plus, we never included any translations in D7, for exactly the same reasons. See related commit. I'm not sure we want to reverse this decision.

Plus, if the intention here is to simply provide (empty) but symlinked central location, it is no longer possible for built-in platforms, which share both the Drupal core and the profiles between instances.

And opening anywhere write access for the web server like proposed here is something I will not even try to understand ;)

Or maybe I have misunderstood the idea here totally?

mrP’s picture

Status: Active » Closed (won't fix)
FileSize
84.54 KB
121.55 KB

To start, this may absolutely be unnecessary. But, by default, when l10n_update installs new translations, it downloads them to a temp directory first. These get discarded in time via purge_cruft.sh. Why not download them to a shared translations folder for re-use by other sites later? See https://drupal.org/files/issues/l10n_update_0.png and https://drupal.org/files/issues/translations_0.png for an example. In this way, we're not dependent on BOA to manage/download translations only provide the structure to allow a shared location.

And opening anywhere write access for the web server like proposed here is something I will not even try to understand ;)

I had just mimicked the way $_ROOT/distro/$_THIS_CORE/keys gets generated as a starting point, but that certainly doesn't mean its correct.