To support deployment of interface translations we need some method to transfer custom translations between different sites. Interface strings which are customized (either with the build-in translation interface or by importing a translation file) are identified as customized with a flag in the database. These strings should be mad available to share them between sites. The current tools are the manual po file export and import functions.
Comment | File | Size | Author |
---|---|---|---|
#19 | 2019-10-17_16-07.png | 88.32 KB | davidferlay |
#15 | 2019-10-16_12-02.png | 32.76 KB | davidferlay |
#15 | 2019-10-16_12-15.png | 9.94 KB | davidferlay |
Comments
Comment #1
Gábor HojtsyWe can also introduce a file name pattern where the strings are imported as custom (vs. as files sourced from l.d.o for specific projects). I'd love to not have two formats supported in the interface translation code, and .po files are the de facto standard formats (not .yml files) for translation distribution. The localization update system in itself has this deployment task where the files need to be copied over to the live server, not just for custom strings. (I assume after a QA on the staging site, a serious website would not let the live site download .po files from l.d.o because they might be different from the ones QAed). The single directory .po file sourcing was introduced to ease staging and deployment and we should be able to tie custom strings into this with .po files as well I strongly believe.
Comment #2
Sutharsan CreditAttribution: Sutharsan commentedUsing po files for the file format prevents that we have to solve problems with plural formula's, plurals and very long strings. And makes it easy to re-use existing import/export code. And storing the customized translations in a po file together with the downloaded po files, would not introduce a different deployment mechanism. I agree that the preferred staging procedure would be to download from l.d.o on a development/test site. Migrate it with a VCS to the acceptance site and then with VCS to production. Acceptance and production import the translations only once (per release) and don't use the automated download or import. Translation deployment now only requires an export and import mechanism for customized translations.
Changing the title bacause a yml file format is not the purpose, but deployability is the purpose of this issue
Comment #3
Gábor HojtsyI think this is better categorized as a missing integration piece (task or bug). Sounds like it would be a little modification to the preg pattern on filenames and documenting the feature. As-in it can be done after dec 1st.
Comment #7
geek-merlinI've rolled this in contrib here:
https://www.drupal.org/project/customtranslations
It's a quite trivial approach so i'd be happy if we can mimic this in core and obsolete the module.
Comment #8
geek-merlinComment #10
esolitosYet another feature that would make D8 more multilingual-friendly.
/u/axelrutz: Are you planning to create a patch?
Comment #11
geek-merlin> /u/axelrutz: Are you planning to create a patch?
Currently i don't see any bandwidth for it...
Comment #14
geek-merlinThe module mentioned in #7 is deprecated in favor of Drush Language Commands. We can steal code there.
Comment #15
davidferlay CreditAttribution: davidferlay at Skilld commentedHi here !
I made some tests on my end and it seems to me that core Drush has already all of the things we need (although i faced something strange in my tests):
drush locale:import fr $(pwd)/web/profiles/sdd/fr_custom.po --type=customized --override=all
So I don't see any use case for https://www.drupal.org/project/drush_language )
Comment #16
davidferlay CreditAttribution: davidferlay at Skilld commentedComment #17
davidferlay CreditAttribution: davidferlay at Skilld commentedComment #18
geek-merlinWhere ever such a tool lives, it will be much simpler and more maintainable if #2631584: Provide a proper API for updating translations lands. There's already a patch to review there, so any help there will help here too.
Comment #19
davidferlay CreditAttribution: davidferlay at Skilld commentedFYI I updated my comment #15)
Comment #20
geek-merlinAs a maintainer of drush_language, i'm happy to collaborate to get this into drush and some day into core's console component. (And deprecate drush_language)
In #15, you tested
drush locale:import
. Do we have something likedrush locale:export --only-custom
too?Also i'd say we need an equivalent of drush_language's
locale-export-all
andlocale-import-all
, which iterates over all language files in a directory.Comment #21
andypostproper status cos there's no patches yet
Comment #22
andypostComment #23
davidferlay CreditAttribution: davidferlay at Skilld commentedHi geek.merlin aka axel.rutz !
Yes indeed, the actual command we use in our workflow is
drush locale:import fr /var/www/html/translations/fr.po --type=customized --override=all
(as you can see here) which worked just fine in my testsI couldn't agree more with you! In my opinion, importing multiple files at once is the main missing puzzle piece we could implement in drush and looks like we could start from code of drush_language.
Exporting command would be the ice on the cake but should have a lesser priority since it's possible via UI
Will you be going to to Amsterdam next week for DrupalCon ? If yes, I'll be there too and we can discuss it over beers
Comment #24
geek-merlin@davidferlay Unfortunately no beers and other 'dam goodies for me. But glad to work together on this and might do some reviews!
Comment #25
davidferlay CreditAttribution: davidferlay at Skilld commentedMaybe next time then @axel.rutz)
Meanwhile I just filled this issue in Drush github repo so that we get things moving :
Comment #26
davidferlay CreditAttribution: davidferlay at Skilld commentedHi there @axel.rutz,
Regards