Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Problem/Motivation
If "Interface text language detection" sets "Account administration pages" as the primary, a field title isn't translated.
Steps to reproduce:
1. Install Drupal with the standard profile in English.
2. After installation, login as an administrator (uid 1).
3. Enable the following modules: Configuration Translation, Interface Translation, Language.
4. Add Japanese language.
5. On the "Detection and selection" page, enable "Account administration pages" and disable others except the grayed-out "Selected language".
6. Check if a Japanese translation is shown on the "Edit Japanese translation for Picture" page.
7. Change the "Administration pages language" settings from "- No preference -" to "Japanese" on the logged-in user edit page.
8. Go to the logged-in user edit page.
9. Picture field title isn't changed to the Japanese translation. Any other field titles such as "Current Password" and "Roles" are changed to Japanese translation.
I installed Drupal 8.8.x-dev and followed the steps above.
If "Selected language" is set as the primary instead of the "Account administration pages" and Site language settings are changed to the same as the step 7 above, Picture field title is changed to the Japanese translation.
| Comment | File | Size | Author |
|---|---|---|---|
| #10 | interdiff-3048196-8-10.txt | 1.81 KB | tetranz |
| #10 | translate-by-admin-3048196-10.patch | 5.3 KB | tetranz |
| #8 | interdiff-3048196-6-8.txt | 5.3 KB | tetranz |
| #8 | translate-by-admin-3048196-8.patch | 3.49 KB | tetranz |
| #6 | translate-by-admin-3048196-6.patch | 1.81 KB | tetranz |
Comments
Comment #2
tetranz CreditAttribution: tetranz at Third and Grove commentedI can reproduce the problem.
Comment #3
tetranz CreditAttribution: tetranz at Third and Grove commentedI think I see the problem. I should have a patch tomorrow.
Comment #4
tetranz CreditAttribution: tetranz at Third and Grove commentedI spoke too soon on this. It didn't quite work out as I expected. I will get back to it as time permits.
I think it is somewhat related to this: https://www.drupal.org/project/drupal/issues/2189267
On earlier versions (I think before that patch) it worked except that the first GET of the profile form (i.e., the redirect after form submit) did not detect language properly. The next GET (i.e., a refresh) did work.
Now on 8.8, it doesn't work at all. I think this only affects bundle fields, not base fields.
Comment #5
BerdirDoes this happen only with user entities or can you reproduce the same for example with the body field on nodes?
Interestingly, the static cache in \Drupal\Core\Entity\EntityFieldManager::getFieldDefinitions() does not depend on the language, but the persistent one does. You could try to add another key for the language code there, could be that the field definitions are loaded before language negotiation and then ignore the language change.
Comment #6
tetranz CreditAttribution: tetranz at Third and Grove commented@bendir It only happens with the user entity.
This patch with your suggestion fixes it.
The issue is related to how the language negotiation happens recursively when rendering the user. It tries to get the language but as part of that it needs to access the current user to get the admin language setting. I haven't really followed it all but it gets field config for the default language first. The extra key in the static cache separates them.
I know it would be nice to have a test for this. I guess we could add user as a special case to ConfigurableLanguageManagerTest. Unfortunately I can't seem to get that test to pass unchanged on my local environment so ... I may not get that that.
Comment #7
Tom KondaThanks @tetranz for your work.
Patch #6 works for me.
Comment #8
tetranz CreditAttribution: tetranz at Third and Grove commentedHere's a test only patch, without the fix. This should fail.
I'll wait for this result and post a combined test and fix.
There is something a little weird happening with the two existing tests in ConfigurableLanguageManagerTest. They fail on my local environment (Vagrant, basically DrupalVM). I can "fix" that by adding drupal_flush_all_caches(); before the Spanish GETs. The drupal.org testbot obviously doesn't need that so I haven't included it but I don't know why I need that on my local environment.
Comment #10
tetranz CreditAttribution: tetranz at Third and Grove commentedTest and fix.
Comment #11
tetranz CreditAttribution: tetranz at Third and Grove commentedComment #12
amateescu CreditAttribution: amateescu for Chapter Three commentedThis looks great to me! Since the change is only affecting the static cache of the field definitions, we don't need an update function.
Comment #14
BerdirRandom fail, created #3055648: Frequent random fail in \Drupal\Tests\media_library\FunctionalJavascript\MediaLibraryTest
Comment #16
BerdirAnother random fail.
Comment #17
alexpottCrediting @Tom Konda for filing the issue with great instructions on our to reproduce the bug and @Berdir for coming up with the fix.
I ran the new test locally without the fix and can confirm it fixes the patch.
Committed and pushed d9519bae25 to 8.8.x and 9940ccf048 to 8.7.x. Thanks!