Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
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
Comment | File | Size | Author |
---|---|---|---|
#3 | translations.png | 121.55 KB | mrP |
#3 | l10n_update.png | 84.54 KB | mrP |
shared-translations-platform.octopus.patch | 828 bytes | mrP | |
shared-translations-core.octopus.patch | 1.04 KB | mrP |
Comments
Comment #1
mrP CreditAttribution: mrP commentedSetting to minor as this impacts current functionality in no way.
Comment #2
omega8cc CreditAttribution: omega8cc commentedWe 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?
Comment #3
mrP CreditAttribution: mrP commentedTo 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.
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.