Languages not translated when you add them

I think the solution would be something like this, if the language list is updated at that point is save() already.

Needs at least tests :D Anyone wants to help with that?

@jhodgdon: No we should hardcode a .po file that has translations for the languages being tested. Such as LocaleImportFunctionalTest has a de and an xx .po file which are copied to the translations dir. It also has .po files written out from test methods that are manually imported. I think from a results perspective, either should work fine.

The real catch here is my patch will have mixed results, because you can only import translations for languages you added before, so trying to t() a language name to the one you just added will not work. What will work is the newly added language will be translated to languages already on the site as available.

Also doing this in the form is not very nice. It will not happen if you import configuration for example or use the API to add a language. I think instead of doing what the patch does, we'll need to trick the LocaleConfigManager to think that the languages have some default install storage. Ie. add 2 new methods to LocaleConfigManager to wrap getComponentNames/listAll and read() on the install storage and fake the languages as if they were in install storage as afar as LocaleConfigManager is concerned. That should not be very hard hopefully :D

So I think the patch would be something like this to work seamlessly with configuration translation creation and update. This is totally untested but may already work :D Basically we simulate configured languages that also have a predefined language as if it was shipped config with the predefined language name.

Tried this out. Installed site in English, added German and Hungarian. Shipped languages (English, Not specified and Not applicable) were all translated properly to German and Hungarian but German and Hungarian were also. Looks to me like it works perfectly :) I also tested installing in Hungarian out of the gate and then adding Afrikaans and German. While not all languages had translations (I think due to missing language translations on l.d.o), it worked similarly well.

(BTW I found #2407907: Configuration translation entity listings displays items overriden on the way).

Still needs tests. I think I explained in #4 how to add tests for this. Anybody up for this? If you want to use the .po single file import UI in the test, then #2095787: Configuration translations not updated when manually importing a .po file is a pre-requisite for the test to work).

I will give this a try (add test as I understood) without the .po single import UI

That will fail without #2095787: Configuration translations not updated when manually importing a .po file, so if you want to go that way, that needs fixing first.

Ok, I'll wait for that fix then

Well, that one actually needs a test written, the fix is there, so if you want :)

Removed tag by mistake.

Removed tag by mistake.

#2095787: Configuration translations not updated when manually importing a .po file landed, so should be relatively easy to do a test for this. Easiest to add a language by importing the .po file that has the translation for a language, and then check.

@fran seva: still working on this one?

Hi Gabor.
I think I didn't understand what I should check after add the .po that create the language.
What I understood is the test should do:

1. Import a translated string for a language. I chose import from a hardcode .po using importPoFile method
2. Search the the translated string for the "new" language created in the import process.

I made a test with this steps but when I run it in 8.0.x branch the test does not fails. That make me think I'm not checking what is expected.
Attach the test and a snapshot with the test result in 8.0.x branch.

In other hand, reading the issue motivation I tried to import an spanish .po and created the "es" language and then check if the Spanish word were automatically translated but it wasn't.

1. +++ b/core/modules/locale/src/Tests/LocaleImportFunctionalTest.php
   @@ -626,4 +643,23 @@ public function getPoFileWithConfigDe() {
   +  ¶
   

   Extra spaces :)

2. +++ b/core/modules/locale/src/Tests/LocaleImportFunctionalTest.php
   @@ -626,4 +643,23 @@ public function getPoFileWithConfigDe() {
   +msgid "Anonymous user"
   +msgstr "Névtelen felhasználó"
   

   The goal of this issue is to translate the languages themselves. So the .po file should contain the string "English" and "Hungarian" and check that those are properly translated. (Feel free to use Spanish or another language of your choosing BTW :)

   You the test with $override = \Drupal::languageManager()->getLanguageConfigOverride('es', 'language.entity.es'); to check if the override was created properly. Checking for the anonymous user name does not prove anything about this issue unfortunately.

The test should work :p

Yup, the test looks straightforward and makes sense :) @jhodgdon: what do you think?

Updated issue summary.

@jhodgdon: so we maintain this built-in language list now in LanguageManager::getStandardLanguageList. We could have a shipped config file for each, though if its in a special directory, we need to make the potx module have special support for it. Then we need to redo LanguageManager::getStandardLanguageList() to read from that directory or we have two copies of the list (one in there and one in YML files). At that point I am not sure that solution is much of an improvement, it is a lot more special case code in multiple places, instead of the self-contained solution here.

One more way to solve this would be to ship the language files actually as default config, but then remove them in the installer after they are all imported, so they are actually kept as default config but not in active config. Then we need to redo the LanguageManager::getStandardLanguageList() and/or the add language process to read from that special install storage.

While there are other options, I don't see those as simpler than what we do in this patch or more self-contained in any way.

If we think outsourcing the storage to some other service would be good, then we can subclass the install storage to an "install storage with languages" and put the special case code there and inject that to the locale config manager. That would also be more code because we'd set up our own storage and inject it here but would be very similar to what we do here. I did not think we would need the overall list of the entries or their contents elsewhere other than in the locale config manager, so I did not do that, but that may be an option I could stand behind.

Attach the comment change :)

@jhodgdon: what do you think?

Me too. This issue is a normal bug fix, and doesn't include any disruptive changes, so it is allowed per https://www.drupal.org/core/beta-changes. Committed b9819fa and pushed to 8.0.x. Thanks!

Yay, magic, thanks!