Interface translations not downloaded after re-adding previously removed language

Hm, we should be clearing that cache when *removing* the language, no? Otherwise we accept that incorrect data will be lingering in our cache. The reason for the bug sounds like that the cache was filled in with data that is not cleared when the language is removed.

Retitled to be more specific.

Getting there :) Ideally locale_translation_clear_status() would be tied to the config delete, so it happens if a deployment removed a language, not only if the form removed it. (The form would remove the config, so it would have the same effect with the config based solution).

Then needs tests if at all possible and done :)

There is already a lot of cleanups happening in locale_configurable_language_delete(). So it could be as simple as this right?

I was so convinced I had configured git for windows right... :s

Can the IS be updated to match the new solution?

Also ran the test locally without the fix and got

Translation status cache emptied
Failed asserting that an array is empty.

Which is good!

@smustgrave IS updated. The essence is more or less the same, but more focus on cleaning up during deletion (instead of fixing it when enabling) as suggested in #9.

Thanks! Think this is ready for committer review.

Random fail

I'm triaging RTBC issues.

Thanks for working on this 5 year old issue and providing a test!

I have read the Issue Summary, comments and the patch. The proposed resolution matches the fix, which is good for reviewers. What I don't see is a fail test but @smustgrave did that locally and reported the results.

I read the patch in #8, which includes an update hook which is no longer in the patch. I am not sure if that should be done here or in a follow up but it is a significant change. I have added discussing this to the remaining items.

https://www.drupal.org/project/drupal/issues/3089764

+++ b/core/modules/locale/tests/src/Functional/LocaleUpdateTest.php
@@ -407,6 +407,10 @@ public function testEnableLanguage() {
+    $translation_status = \Drupal::keyValue('locale.translation_status')->getAll();
+    $this->assertEmpty($translation_status, 'Translation status cache emptied');

Assertions should only have messages if in situations such as a for loop so that the individual failure can be identified.
This can also be one line, and eliminate the variable, $translation_status

I updated the IS with the standard template. Just a bit more to do here!

@quitone, Thanks for having a look. I've left out the update because the issue should theoretically be self-healing.

The locale.translation_status key value store has a timestamp and last_checked date. So, when enough time has elapsed the cache should eventually expire and new translations should be downloaded again. Right?
It might be a good idea to validate this though.

If somebody decides they still want an update hook, just calling locale_translation_clear_status() should be enough. Drupal core always clears all translation caches at once, so there is no need to select specific languages.

Made the requested changed from #24.

Tagging 'needs review' to validate the claim from #25 and determine if the DB update is needed or not.

The Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

That one was supposed to fail. Setting to NR to validate the claim from #25 and determine if the DB update is needed or not.

Believe the update hook is incorrect.

11.x is the development branch that D10 releases will be cut from so if this were to land in 10.2 update hook could start there.

Can't that be fixed on commit?