Quantcast
Viewing all articles
Browse latest Browse all 295783

Applying default language fallback rules to interface translation has impressively bad results

Problem/Motivation

  1. Install in a foreign language. Will download translations and import.
  2. Add English and enable English to be translatable.
  3. Now even if you look at English pages, they will be in the other language UI.

This is due to #2122175: String translation does not honor language fallback. Currently the default language fallback rules are applied to looking up interface translations which means if there is no string translation, it will try to look up the string translation *again* in the same language, then in all other languages in their order and then in the undefined language. Neither of these make sense most of the time. Language fallback for interface translation should be an explicit configuration, ie. if you want to fall back from informal German to German or if you have regional French set up for Canada and France and the Canadian should fall back on the France one or vice versa.

Proposed resolution

Fix the default language fallback setup, so there is no suggested language fallback for interface translation. Either core can implement a UI / setting for this later or contrib can provide one. Add tests to ensure the default values in the hook and that it gets all info necessary for providing fallback langcodes.

Remaining tasks

Review. Commit.

User interface changes

Interface translation will not "randomly" fall back :D

API changes

Context on getFallbackCandidates now contains the langcode key/value instead of taking it as a separate optional argument. Signature change:

-  public function getFallbackCandidates($langcode = NULL, array $context = array());
+  public function getFallbackCandidates(array $context = array());

Viewing all articles
Browse latest Browse all 295783


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>