I'm using $conf['locale_custom_strings_xx'] in settings.php and i have no problems with translations through t() php function. But if i translate through Drupal.t() javascript function there is no string translation from $conf['locale_custom_strings_xx']. Instead I have to use locales_target database table to translate strings through Drupal.t() javascript function.
Drupal.t() should also use $conf['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:
$conf['locale_custom_strings_de'][''] = [
'Label' => 'LabelCUSTOM',
'Edit' => 'EditCUSTOM',
];
3. Go to /de/admin/structure/types/manage/page/fields
4. You can see the "Label" strings overriden correctly, but the "Edit" (when you start to type a new machine name) is not, as this is coming from Drupal.t() (instead it has "Bearbeiten" as a correct German translation).
(optionally)
5. apply patch
6. clear cache
7. "Bearbeiten" will be changed to "EditCUSTOM" correctly
Proposed resolution
Drupal.t() should respect the string overrides.
Comments
Comment #1
ducdebreme CreditAttribution: ducdebreme commentedsubscribing
Comment #2
checker CreditAttribution: checker commentedDoes anyone know if this bug is in d7?
Comment #3
checker CreditAttribution: checker commentedSee also #369658: JavaScript Support through Drupal.t()
Comment #4
checker CreditAttribution: checker commentedI reviewed the drupal core code around javascript string translations. I think the reason that it does not work with Drupal.t() is to find in function
_locale_rebuild_js()
@/includes/locale.inc
. There is only a db query to fetch all strings and no including ofcustom_strings
. You can see in functiont()
@/includes/common.inc
how to invokecustom_strings
.Comment #5
checker CreditAttribution: checker commentedComment #6
sgtpep CreditAttribution: sgtpep commentedThank you @checker for hint. Here is suggested patch.
Comment #7
checker CreditAttribution: checker commentedComment #8
acrollet CreditAttribution: acrollet commentedPatch against 7.x attached.
Comment #10
David_Rothstein CreditAttribution: David_Rothstein commentedHere's a reroll that works correctly with translation context, and fixes a code style issue also.
This probably needs tests, and need to check if it affects Drupal 8 also...
Comment #11
checker CreditAttribution: checker commentedPatch #10 is working.
Hey, it is possible to get this fix before this issue has its 4th birthday! ;-)
Comment #12
bkouchi CreditAttribution: bkouchi commentedI had a multi-site in another language with locale custom strings and Patch #10 addressed my needs.
Comment #13
sammuell CreditAttribution: sammuell commentedPatch #10 works well
Comment #14
poker10 CreditAttribution: poker10 at ActivIT s.r.o. commentedChecked per #10 and if I have not missed anything, this seem to affect also D9, as the code is practically the same: https://git.drupalcode.org/project/drupal/-/blob/9.5.x/core/modules/locale/locale.module#L1248.
Comment #15
poker10 CreditAttribution: poker10 at ActivIT s.r.o. commentedI have created a D10 issue: #3383888: Drupal.t() does not respect locale_custom_strings. As per backport policy, I think we need to Postpone this until that one is fixed. We can probably use the similar approach in the D10 patch, but the test will be needed for sure. Thanks!
Comment #16
poker10 CreditAttribution: poker10 at ActivIT s.r.o. commentedD10 issue was committed, therefore I think we are good to go here in D7 as well.
We just needed to add a new test for this (see the D10 commit: https://git.drupalcode.org/project/drupal/-/commit/0e6eec0727d1813373807...).
Uploading a test-only patch (with the new test added) and patch with fix+test.
I have also updated the IS with manual steps to reproduce this.
Comment #18
poker10 CreditAttribution: poker10 at ActivIT s.r.o. commentedComment #19
Fabianx CreditAttribution: Fabianx at HeroDevs commentedRTBC!
Straightforward fix!
Comment #21
mcdruidThanks everyone!