Add warning message to import translations after enabling Interface Translation

I would argue that this is Major if not Critical. Imagine a scenario in which Language was enabled and a number of languages were added to the site. Content Translation was enabled and LOTS of content was translated. Later on, new administrators of the site (who don't understand the default site language) came on board and they needed the interface translated so they enabled the Interface Translation. It is simply NOT and option to first delete all the languages that had been added to the site so that they can be re-added and have their translation imported.

It is not acceptable to make Interface Translation a required module for Language. That's totally backwards. Not everybody who has a need for Language will have a need for Interface Translation. Interface Translation absolutely must have the intelligence to look for already enabled languages when it is enabled and then download and import those languages. If it doesn't happen automatically when enabling Interface Translation, there must be some mechanism to get it to fire.

Hmm . . . Not sure how the component got switched to ajax. Anyway, I think it's more appropriate to assign it to language system than to translation.module.

It is not acceptable to make Interface Translation a required module for Language.

I don't see why you would enable interface translation without languages, so the required part makes total sense.

Also, this isn't critical at all. I don't even think there's even a bug still. Adding a new language imports new interface translations (if configured), so that's covered.

@swentel: You are reading this backwards. Language is a requirement for all the other translation modules, including Interface Translation. The suggestion was to make Interface Translation a requirement for Language. That's not acceptable.

I can assure you that the bug still exists. I just encountered it last night. Follow the steps list by the OP to reproduce it. The issue is if you had already added languages prior to enabling Interface Translation. You are once again reading this backwards.

Having said the above, I'm going to check whether manually downloading the .po from localize.drupal.org and then importing it provides a workaround. I'm not sure if that would affect what happens when there are updates to the translation available. However, IIRC configuration options exist to say whether you will override existing translations or keep them when you process the update.

To repeat the setup from the issue summary by the OP:
1) Enable Language
2) Add a language
3) Enable Interface Translation
4) Navigate to /admin/reports/translations and note that all translations are up to date
5) Navigate to /admin/config/regional/language and note that the language is 0% translated

Workaround:
1) Download .po file from https://localize.drupal.org/download
2) Visit /admin/config/regional/translate/import and Choose your .po file
3) Configure checkboxes as desired with regards to whether to overwrite or keep translations
4) Click the Import button

So, I guess this does not need to be categorized as Critical. I think this is a fairly reasonable workaround that shouldn't have any negative side effects. I don't know whether I could argue that it should be considered a Major bug. For now I'll just leave it set as Normal. IMHO it most definitely is a serious bug.

If the concern is that the system could potentially be overloaded when enabling Interface Translation if there were a bunch of languages that needed to be imported all at once, then perhaps at least Interface Translation could write a Notice or Warning message to instruct the user to follow the workaround I've outlined above. I think it would be good for that message to continue to appear until the problem was resolved. Or, have an error that shows up on the status report page until the problem is resolved.

Still true on Drupal 9.5.x. Added template to the IS and updated it a bit.

Enable "Interface Translation" still doesn't import translations for an already defined language in 10.1.6.

The user can import the translation easily here /admin/reports/translations: Check manually click Update translations

There should be a message after enabling "Interface Translation" which guides the user to /admin/reports/translations

If the ticket is to now display a message instead can the issue summary/title be updated to reflect that.

With a new message a screenshot of the new UI should be added to the issue summary also.

Believe we will test coverage for this.

Thanks!

1) Drupal\Tests\locale\Functional\LocaleInstallTest::testLocaleInstallMessage
Element matching xpath "//div[@data-drupal-messages]//div[(contains(@aria-label, "Warning message") or contains(@aria-labelledby, "warning")) and contains(., "Available translation updates")]" not found.
/builds/issue/drupal-2609256/core/tests/Drupal/Tests/WebAssert.php:830
/builds/issue/drupal-2609256/core/modules/locale/tests/src/Functional/LocaleInstallTest.php:43
/builds/issue/drupal-2609256/vendor/phpunit/phpunit/src/Framework/TestResult.php:728
FAILURES!

Ran the test-only feature and shows the test coverage of the new message. Tried to find an existing file this could go to but didn't see one that made sense for just a message.

Applied the MR and locally am seeing the warning message now also.

I've pinged the UX team in slack to give them a chance to confirm they're happy with the text of the message.

Putting to NR to give UX team a chance to review. I'll keep an eye on this one, feel free to ping me if its sitting a while.

Adding tag per #29.

Usability review

We've discussed this issue at #3409058: Drupal Usability Meeting 2023-12-22. The direct link to the recording is https://www.youtube.com/watch?v=WXxcozzJpmY .

For the record, the attendees at the usability meeting were @AaronMcHale, @benjifisher, @rkoller, and @worldlinemine.

We’ve briefly revisited the issue at #3410538: Drupal Usability Meeting 2023-12-29. That issue will have a link to a recording of the meeting.

For the record, the attendees at the usability meeting were @AaronMcHale, @benjifisher, @rkoller, and @worldlinemine.

If you want more feedback from the usability team, a good way to reach out is in the #ux channel in Slack.

In general there was a consensus that having an informational as well as actionable message is a good thing. During the meeting we've followed the points listed in the Steps to reproduce section adding German as the second language on a Drupal 11.x-dev install with the MR applied. At first a list of things we’ve noticed:

• Not related and entirely out of scope for this issue, after installing a second language the status message on /admin/config/regional/language has a link called block administration page<code> (<code>Use one of the language switcher blocks to allow site visitors to switch between languages. You can enable these blocks on the block administration page.). Block administration page is not clear, it could either refer to /admin/content/block (you administer, edit and delete, blocks there) or /admin/structure/block. On the block layout page nor on /admin/content/block the term “block administration” is used either. It might be a good thing to keep the wording consistent across admin pages and avoid ambiguity by directly calling it "block layout page" in that info message.
• It is a good thing that the order of the status message and the warning message changed with the patch applied and that the warning message is first in line now.
• The warning message Go to Available translation updates in order to download translations for your languages. sort of "fools” the user creating the expectation being able to download the available translation updates on the linked page. Instead you are just presented the German language with the status "Missing translations for one project”. There is no apparent direct way to act upon. If you manually check for available updates the translation is still missing. After the meeting @benjifisher and me continued the discussion on Slack and tested the patch on a install of Drupal 10.2. There the user also gets sort of “fooled” since the status shows “Missing translations for one project” as well and no direct call to action is available. The only difference when you click Check manually, checking for available updates, an available update for German is shown now (in contrast to 11.x, a German translation is available for 10.2.x).
• In regards of the microcopy the order of the points made with the current warning message “ Go to Available translation updates in order to download translations for your languages.” might be improved. At the moment the action is front-loaded and the information why the action aka the link is necessary at all comes at the end.
• It was noted that the warning message is only shown directly after the interface translation module is installed. In case the call to action to go to the available translations updates page isn’t directly responded to the warning message isn’t shown on any subsequent page the user is visiting afterwards. If someone was not closely reading, was with the thoughts and focus somewhere else, and or has a small working memory, the fact that translations are available could be completely missed or forgotten.
• It was also asked why the translation isn’t downloaded automatically when the interface translation module is installed and one or more languages were already being added beforehand. It would be nice if that extra step of going to the available translation updates page wouldn’t be required - as voiced in other comments in this issue as well. But completely out of the scope for this issue.
• If you check /admin/reports/dblog the entry No configuration objects have been updated. of the type locale is not very informativ nor helpful. Without any context it is difficult to figure out what lead to that log entry and how to actually fix it.

There was a consensus about the following recommendations:

1. Change the message from Go to <a>Available translation updates</a> in order to download translations for your languages. to Check <a>available translations</a> for your language(s).. We've tried to avoid the term update in that context. It feels more like in this case the translation is initially added here instead of being updated.
2. Change the url for the available translations link from
   /admin/reports/translations to /admin/reports/translations/check?destination=/admin/reports/translations. That way the user is directly presented the action to download the translations - no extra step required.

About the message after the interface translations module is installed and the log message the group came up with two suggestions:

• With the available translations link's url changed to /admin/reports/translations/check?destination=/admin/reports/translations there is no “real” apparent failing of the system. Therefore the suggestion was to use instead of a warning message an info message.
• In regards of the log message the initial idea was to use the message from the available translation updates page including a link to the reports page. But already during the follow up discussions on Slack we've gotten away from the suggestion providing an actionable link on a log entry. And it is also the question how helpful the message from the available translations updates page would be on it's own as a log message. (Update: After a follow up conversation on Slack we withdraw even the suggestion (the one striked) for just using the message from the available translations updates page. To come up with a proper suggestion we would need to know more details. It is probably better to move changing the log message to a follow up issue?

Thanks for the great detail and for the ux team taking a look!

Moving to NW for the recommendations.

message and url are updated following the recommendations.

@smustgrave thanks for setting the issue to needs work back then. i completely forgot to change the status after posting the comment.

@sleitner Thank you, I've manually tested the latest changes. The status message looks good

and the link correctly points to the available translation updates page now:

The only odd thing is that the available language isn't vertically centered and is shifted towards the top of the box it is contained in. But I've tested the same without the patch applied and the shift is there as well (tested in Safari and Edge on MacOS). Therefore out of scope for this issue. Would it make sense to open up a follow up issue for that as well? I'll leave the status at Needs review since i've only manually tested the latest changes but am unable to provide feedback about the code part.

Have not re-reviewed but appears to have a kernel test failure

core/tests/Drupal/KernelTests/Config/DefaultConfigTest.php did fail because path alias is not available when locale is installed. Instead of the route to url conversion, the url is now hardcoded.

Changes look good. Left 2 small nitpicky items but probably good to self RTBC after that.

Update

Issue credits

Committed to 11.x and backported to 10.2.x

Thanks folks