Add warning message to import translations after enabling Interface Translation

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 📌 Drupal Usability Meeting 2023-12-22 Needs work . 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 📌 Drupal Usability Meeting 2023-12-29 Active . 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.

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.

larowlan → credited worldlinemine → .

Issue credits

larowlan → credited benjifisher → .

larowlan → closed merge request !5551

Committed to 11.x and backported to 10.2.x

Thanks folks

Automatically closed - issue fixed for 2 weeks with no activity.