Problem/Motivation
While backend texts are perfectly translated and translations for these texts are fetched from localize.drupal.org (e.g. German translation is 100%) this doesn't seem to work for the JavaScript widget.
There are several examples, one string is e.g.
Allow loading of unknown external resources
which seems to be from https://git.drupalcode.org/project/klaro/-/blob/3.x/config/install/klaro...
and is correctly translated: https://localize.drupal.org/translate/languages/de/translate?project=kla...
Another example is
Toggle all services
which is from https://git.drupalcode.org/project/klaro/-/blob/3.x/config/install/klaro...
and correctly translated: https://localize.drupal.org/translate/languages/de/translate?project=kla...
So it seems that these texts are translated correctly but for some reason they are not used or fetched from localize.drupal.org?
Even after updating all translations using the UI or
drush locale:check
drush locale:updatethe translations for the texts in the widget are empty and have to be translated manually.
The translations for these texts are not pulled.
You can see that in User Interface translation (/admin/config/regional/translate)
Clearing caches, running cron or waiting days has no effect.
This is bad for first user-experience and every project has to translate these strings manually.
Steps to reproduce
- Install a Drupal Website in English and German
- Install Klaro
- Update the translations from localize.drupal.org
- See backend texts translated, but JS Widget text still untranslated in English
- Manually fix this in User Interface translation (
/admin/config/regional/translate)
Proposed resolution
- Find out the root cause
- Discuss the solution
- Fix
- Text
- Release
Comments
Comment #2
anybodyComment #3
anybodyI added some more details. Can others confirm this issue and does anyone have an idea? Or might the translated strings from localize.drupal.org not get applied because of the (useful) context added in #3439900: Add context to translatable strings?
Or is this a known core issue?
Comment #4
marcoliverI think this may be a problem with the localization-server.
If you look at https://ftp-origin.drupal.org/files/translations/all/klaro/klaro-3.0.8.d... that being the translations file for the latest release, some strings like "Toggle all services" just don't appear there.
Maybe something went wrong while generating the PO-file for that release, because it's also missing translations that are significantly older than that version (for example "Yes (this time)").
I opened a related issue on the Infrastructure board so somebody can maybe shake-up the PO-file pipeline.
Comment #5
anybodyThanks @marcoliver for looking into this! Let's wait for feedback.
Comment #6
jan kellermann commentedKlaro JS is an external library and has its own translation system, see here for example:
https://git.drupalcode.org/project/klaro_js/-/blob/3.0.x/dist/translatio...
Translation of external library is for me out of scope.
Comment #7
marcoliver@jan kellermann True, the library has built-in translation handling. But the Drupal module passes whatever strings you have entered in the backend to drupalSettings and they are treated as custom strings for the JS to override the defaults. Now if the translation in the backend is incomplete, only that incomplete set of strings is passed to the frontend, leaving you with a mixed-language Klaro UI.
Comment #8
anybodyThank you both for the replies. I'd like to underline that we should fix the root cause, where ever it is located.
From the user-perspective, especially as being part of Drupal CMS, this should work well out of the box, do we share that goal?
In the next step we should try to find out the real root cause and plan to fix then?
Can you both confirm the issue I described? I just want to ensure it doesn't only exist in our projects. Thanks!
Comment #9
marcoliverYes, I can confirm the issue. We encountered the same behavior just last week.
Comment #10
marcoliverThe related issue was resolved last night. I just checked the PO file on the server and it now contains both of our example strings.
I just updated the translations in my local project and the issue appears to be resolved.
@anybody Has anything changed for you?
Comment #11
anybody@marcoliver thanks - sorry I have to check that again, busy days. I'll be back!
Comment #12
anybodyThank you very much @marcoliver this indeed seems resolved. Great to have this fixed. If anyone should experience these issues again, please reopen.