Problem/Motivation
This is a D10 issue from #764408: [D7] Drupal.t() does not respect locale_custom_strings.
It is possible to define locale_custom_strings_XX in settings.php to override specific string translations.
* String overrides:
*
* To override specific strings on your site with or without enabling the Locale
* module, add an entry to this list. This functionality allows you to change
* a small number of your site's default English language interface strings.
This is working for strings translated via t(), but if a string is being translated via Drupal.t() in javascript, the override is not respected and has no effect.
I think that Drupal.t() should also respect locale_custom_strings_XX.
Steps to reproduce
Easiest way to reproduce is:
1. enable second language (for example German)
2. specify some string overrides in settings.php, for example:
$settings['locale_custom_strings_de'][''] = [
'Label' => 'LabelCUSTOM',
'Edit' => 'EditCUSTOM',
'List additional actions' => 'Additional actions ACTIONS!',
];
3. Go to /de/admin/structure/types/manage/page/fields/add-field
4. You can see the "Label" and "Edit" strings are overriden correctly, but the "List additional actions" (in the dropbutton) is not, as this is coming from Drupal.t() (instead it has "Bearbeiten as a correct German translation). See the screenshot.
Proposed resolution
Drupal.t() should respect the string overrides.
Remaining tasks
Write test.
Fix the issue.
User interface changes
API changes
Data model changes
Release notes snippet
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | 3383888-4.patch | 2.47 KB | poker10 |
| #4 | 3383888-4_test-only.patch | 1.45 KB | poker10 |
| #3 | 3383888-3.patch | 1.01 KB | poker10 |
| translate.jpg | 13.81 KB | poker10 |
Comments
Comment #2
poker10 commentedUpdated the IS.
Comment #3
poker10 commentedSomething like this should fix the issue (based on D7 patch). But tests are still needed I think (so keeping at NW).
Comment #4
poker10 commentedAdded a test for checking the custom string in the generated JS file. Uploading also test-only patch, which should hopefully fail.
Comment #6
smustgrave commentedThanks for including a test-only patch to show this is an issue!
Looking at the actual fix I don't see anything standing out that could be a problem.
Issue summary appears complete
Going to mark this.
Comment #14
larowlanTested this locally with umami install profile.
Unfortunately the steps to reproduce don't work anymore because of changes to field UI.
But you can still see it with these, so updating the issue summary:
Committed and pushed to 11.x
Backported to 10.0.x
Thanks folks