Coming from here, here and here (and before starting a new issue on D.O.) comes my query to the community: Do we need another META or initiative of tasks?
Drupal has grown into a fantastic multi-langue platform with tons of possibilities and detection methods to manage large multi-language projects. With all the features comes a certain challenge regarding UX and there has been done a lot already over the years in multiple initiatives. From my POV Drupal is unmatched in this field out of the box already. But with all the options at hand, things can interfer with each other in unexpected ways and can make it hard to understand or distinguish where and how to set up. More often then rarely this leads to the assumption that there's a setting missed by the user. But in fact there is maybe still another use case not covered yet, where the wanted goal is not possible to achieve. Language setting concepts and different wishes is like pushing a fortunes wheel.
One of this use cases is when projects need to really decouple content, interface and config translation not only in the language to be selected per user, but also if some these areas should be multi-language at all, or if, only partly. It turns out that there is a certain confusion grown over the years regarding the way how to set up a multi-language Drupal installation correctly when content translation, interface translation and config translation have mixed priority and mixed count of languages (or parts of it) needed in the project.
Not only the language detection settings can become complex to understand for an average user who tries to find a way to decouple the different language areas of Drupal UI and to set up the number of used languages in this scenario, but also the overall flexibility of what needs to be translated and what not is hard to tweak from UI for now.
TBH, a long time already I think about if the translation framework needs another initiative to "more fine-grain settings between translatable areas and decouple interface and config translation sub module dependencies and make translation settings more flexible per area" with active issues and missing issues collected as subtasks. But I hesitate and do not want to create too much noise yet interferring with the maintainers spare time and priorities. That's why I choose to wrap it up here first and collect opinions. These challenges in core with different translation areas, its settings and use cases to handle in admin UI user friendly maybe need another bigger review of all of us.
One of the first things to be discussed should be: The activation dependency between config and interface translation. And the automatic interface translation import, which is hard to circumvent, to fine-tune, or to partly disable for average users. It makes it impossible to simply tweak 2-3 field labels without getting an interface translation flood up and running making the database grow. Users start to fiddle around with interface translation, go into user settings to prevent other admin UI languages to be seen other than English. In case of English not being the default language, all admin paths will be in /en/... paths then, which can cause issues with some common admin practises including pathauto url-aliases and others.
As a work around you can do:
drush config:set --input-format=yaml -y locale.settings translation.import_enabled false
and leave user settings untouched. Which works only if set early. But there should be options at hand in UI to prevent auto import of interface translation or to disable interface translation all at once for individuall or all languages, while keeping config translation on. Also a reset should be available on obvious places to flush a messed up interface translation import.
For many English native contributors this challenge is probably unknown because they do not know about how other languages deal with English interfaces. It is a common practise in Western world today that teams work on English software and English "back-ends" in technical or editorial context. People are used to English in their Notebooks and in any admin UI online or at home and in universities etc. Similar to phones. Config Translation (referring to custom translation strings) and interface translation needs to be decoupled to be able to still tweak some translation which belongs to front and admin. But they still need to be activated both, starting a challenge. I think this is not an easy task. I assume there are reasons why they depend on each other? Would love to hear more from involved into this decisions back in the days.
Another reason for this to be required is that some interface translation is opiniated and can become unintuitive on accident since many other languages than English use a certain "nearby English interface terminology" or even keep certain words in original to prevent confusion with other meanings. An example: Let's use the flag module as a fictive example. It provides extended interface translation (thanks for this awesome contrubution) for each part of the project. But (it's just a fictive example) in case of some wierd direct word by word translation it would be not intuitive for web admins to read "Die Flagge wurde gesetzt" which rather translates/reads to "The (national) flag has been raised" than to the original "flag has been set" which every admin understands. (It is not like flag uses the translation, is just an example).
- #3345204 Allow to exclude specific languages from interface translation update
- #3503250 Allow disabling translation import in UI by exposing the
translation.import_enabledlocale setting - #3584385 Modernize language negotation plugin instantiation
- #2770113 Allow to skip translations import
- #2801397 Account administration pages option break multilingual
- #3204082 Interface translations override config translations on update
- #3549927 Streamline translation of Views block titles, custom menu titles, etc.: Allow Interface Translation
- #1314250 Allow filtering/configuration of which languages apply to what (UI, nodes, files, etc)
- #3554296 Fix ConfigurationLanguage deviating from InterfaceLanguage by setting it instantly
- #2864972 Content and interface translation don't clearly separate
- #2837083 Add a way to identify module/theme/profile names as unique translation strings
- #3160334 Avoid all config translations being updated for each different config translation
- #3337864 Configuration language is not adjusted after changing the site default language
- Admin toolbar specific:
- https://www.drupal.org/project/l10n_tools
- https://www.drupal.org/project/stringoverrides (for those who only need to translate some strings but would love to turn off config and interface translation for now)
- https://www.drupal.org/project/translated_config
- https://www.drupal.org/project/tranc
Please rather comment on https://git.drupalcode.org/-/snippets/270 if you have a git.drupalcode.org account.