The translation system described in adr-009-translation-system handles solely the translations added through Drupals traditional translation handling.
But there was a wish for being able to translate configuration related strings as well. This includes titles, labels, descriptions, and other elements in the admin area.
We needed to find a way to handle translation of that kind as well.
We went for a solution where we activated the Configuration Translation Drupal core module and added the Configuration Translation PO contrib module.
And we added a range of custom drush commands to handle the various configuration translation tasks.
By sticking to the handling of PO files in configuration handling that we are already using in our general translation handling, we can keep the current Github workflows with some alterations.
Unfortunately handling translations of configuration on local sites is still as difficult as before. Translation of configuration texts cannot be found in the standard UI strings translation list.
With the config translation PO files added we tried to uncover if POEditor was able to handle two PO files simultaneously in both import and export context. It could not.
But we still needed, in Drupal, to be able to import two different files: One for general translations and one for configuration translations.
We came up with the idea that we could merge the two files going when importing into POEditor and split it again when exporting from POEditor.
We tried it out and it worked so that was the solution we ended up with.
We could activate only the config_translate module and add a danish translations in config/sync. But then:
- We would not be able to use POEditor
- We would need to translate the string on behalf of the administrators
We could keep the machine names of the config in English but write the titles, labels, descriptions in Danish.
But that would have the following bad consequences:
- The administrators would have to find all the texts in various, not obvious, places in the admin area.
- It would differ from the general translation routine which is confusing
- We would not be able to handle multiple languages for the configuration translations
Change the Potion module to be able to scan configuration translations as well.
We did not have a clear view of the concept of localizing configuration translations in the same manner as the Potion module scans the codebase. It could either be cumbersome to get the two worlds to meet in the same Potion functionalities or simply incompatible.