Configuration and Javascript translation not created/updated in .po translation import

@jhogdon: yeah, we are tracking this in the critical release blocker at #2267715: [meta] Drupal.org (websites/infra) blockers to a Drupal 8 RC1, so we should consider closing this in favor of that one IMHO. While the criteria is not very spelled out there, that is the umbrella issue for these things, among other infra blockers. The concrete potx/localize.drupal.org issue for this is at #1933988: Support for Drupal 8 shipped configuration translatables with external dependencies (in effect contrib) and @herom is working on a more limited use case now there which seems to be working out well.

If we want to reopen this, then we should discuss what is our process for tracking external dependencies like this :) I think the overall infra blocker may not express the complexities hidden there (given it is only one issue and does not summarize all the problems to make it findable/searchable) but that is our process so far.

Oh, very good find! So the problem is the following:

- The strings are imported nicely to the database.
- Then the batch moves on to locale_translate_batch_refresh() which is implemented weird.
-> Its "first" step is it unifies the list of strings to be handled
-> Its "second" step is it picks the first (up to) 100 strings and refreshes any JS translations related to them and looks up config names
-> Its "third" step is it updates translations for the config names one by one of those hundred

Then the "third" step runs for all the config names. Once that is exhausted, the "second" step comes back for the next 100 strings, then the "third" step for all those, etc.

The problem is that the "third" step sets no batch finished percentile. Batch steps are invoked with the assumption that they finish, so if we don't set a percentile, then it will assume it is ready. So we have a full list of the affected strings, then a full list of the affected names for the first 100 strings, and then only ever process the very first of those. That is why you see at the end of the import that only one config file is updated. If we return a percentile that makes sense, then further config files are processed and you get 123(!) files updated, at least with the Hungarian translation that is pretty extensive.

It is true that the source strings are mostly not present on the server side, but those that are somehow detected via tests and other means I guess, not the config files per say will this way end up imported.

I attached a minimal and a more elaborate fix. The creation/update of the config translation files takes considerable time, so we need to provide some feedback. The minimal patch makes the batch jump back and forth, so the better fix remembers the string step status and uses that in the name step.

For a test IMHO we need the following:

- a .po file which has a translation for at least 2 config files
- import it
- look at feedback on screen that it updated 2 files (would already fail without the patch)

Looked at writing a test for this. BUT there is already a test for this at LocaleImportFunctionalTest::testConfigPoFile(). That updates two config file translations based on a .po file source, checks the translations were imported in locale and saved into config. So I could not do much else here either. AFAIS the reason the tests pass even though they should not is the timing factor, typical of batches. :/

Some more minor changes to the messages. Now that all config is updated, this is about half the processing time for core translations, so pretty important to have messages from there.

It did not let me rest that this may not be due to the batching stuff. And indeed. The test is bogus because it tests loading the translations via the locale manager, which will in fact load the override from the locale database, so not really testing if the override was *saved*. It was testing whether the override was in the locale system, but the prior translation verifications already do that.

If we instead directly look at the translation overrides, the test will fail without the fix because it stops right after updating the first config file. Yay!

I think this is a complete fix/test now. IMHO only needs issue summary update and then good to go :)

Also updated issue summary, please review :)

Tested and worked perfectly. Just a small nit.

Value NULL is equal to value 'Névtelen felhasználó'.

The test assert could use a human-friendly message.

I would repeat the dynamic value in the "User friendly" message anyway because we are iterating over multiple items, so the line number will be no indication which one fails. So I don't think it will get better than that. Then its easier to rely on what is already provided IMHO, because less pain same gain :)

ok. the documentation in the test does explain it, so I guess that should be enough.
no more issues.

Nice catch.

Committed and pushed to 8.x. Thanks!

Yayayayay, thanks.