Unclear fallback behaviour for static translations

[exophunk]

Description

I ran into a weird behaviour with static message translations. I think this came with the 3.1 Update.

I have the following site structure:

Primary: "Deutsch", Handle: de, Language: de
Second: "English", Handle: en, Language: en

Translation files:

- lang
  - de
    - site.php
  - en
    - site.php

de/site.php:

<?php
return [
  "Baum" => "Baum",
  "Haus" => "Ein Gebäude"
]

en/site.php:

<?php
return [
  "Baum" => "Tree",
  "Haus" => "House"
]

template:

{{ 'Baum'|t }}
{{ 'Haus'|t }}

Output on DE page:

Tree  // <--- WTF?
Ein Gebäude

Output on EN page:

Tree
House

Now what happens:
If the translation file for de holds a key that has the exact same value ("Baum" => "Baum") it simply gets ignored and the system somehow gets the translation from the en/site.php file. If the key does NOT equal the value ("Haus" => "Ein Gebäude"), then it correctly pulls the translation from de. Currently half of my pages translations simply stopped working and some do still translate, very weird.

So if a translation file has keys with the same value, it fallbacks to another language, which doesn't even is the primary language. It just fallbacks to en because it is english I guess? And also, it seems very unclear, why a fallback should happen, simply because the key equals a value. There should no fallback to another language at all.

Also, if simply not providing a site/de.php file, the system also pulls translations from en, even if the craft.app.language is de. This should never happen?

Steps to reproduce

1. Add two sites. e.g. "de" and a second non-primary as "en"
2. Add translation files
3. Add key-value pairs that equal
4. Add key-value pairs that do not equal
5. Output { 'key'|t }} in your templates and check the templates in different languages
6. See how weird "en" fallback happens

Additional info

• Craft version: 3.1.3
• PHP version: 7.2

[brandonkelly]

Sorry, this was a side effect of 70a1c20. The reason is because Craft is (wrongly) assuming that the source site messages are written in English, and as of that commit it is falling back to its source language’s message when it looks like the requested translation was unsuccessful.

It’s fixed for the next release now. You can patch your local install by updating your craftcms/cms requirement in composer.json to:

"require": {
  "craftcms/cms": "dev-develop#2a78466ce2a7d4dddc127d99a86f3336b828978d as 3.1.3",
  "...": "..."
}

And then run composer update.

Or you can create a config/app.php file with this, which will override Craft’s assumption that the source site messages are in English:

<?php

return [
    'components' => [
        'i18n' => [
            'translations' => [
                'site' => [
                    'sourceLanguage' => 'de',
                ],
            ],
        ],
    ],
];

[pju-]

@brandonkelly I think this issue is back in 3.1.14, or at least something similar.
I have static translations for a plugin, and those display the same behaviour exophunk described (if the translation is the same as the key, it will fall back to English).

[brandonkelly]

@pju- Plugins actually can specify what their source language is. Just add this to your primary plugin class:

public $sourceLanguage = 'xx-XX';