Clearing cache via UI in translated language resets config translation of field labels to default language

Created on 14 January 2016, about 9 years ago
Updated 11 December 2023, about 1 year ago

Problem/Motivation

I translated field labels through the configuration translation module UI. When I create a node and then translate it the translated version reflects translated field labels so for example fr/node/nid has all labels translated. However if I clear the cache while still being on translated page (any path with language prefix) all labels become English (default language) again. If I switch to default language and then clear cache one more time then switch to French labels are translated again.

Basically every time the cache is cleared through UI while on the page with language prefix fr/... it resets translation for previously translated configuration items. And when the cache is cleared on default language the translation is back to normal.

On the site all multilingual core modules are enabled. Translation is enabled for content types and for fields. Default language of the site is English. Nodes were created in English with French translation.

Steps to reproduce

  1. Install all modules in Multilingual (language, locale, config_translation, content_translation)
  2. Added French language (any language should do) via /admin/config/regional/language
  3. Enable translation for Article under Content->Article at admin/config/regional/content-language
  4. Create a test Article node with some Tags content via /node/add/article
  5. View /fr/node/1 (or whatever), the Tags label should show as Γ‰tiquettes
  6. Navigate to /fr/admin/config/development/performance and clear cache via the UI
  7. Back to /fr/node/1 and the Γ‰tiquettes label is now "Tags"

Proposed resolution

After further investigation revealed that the translations getting cached while clearing cache in a state language override isn't in place. Which causes the system to save english/default translation into language prefixed cache key. This is caused by triggering entity title call in views route subscriber. Moving title of the route to title callback fixes the problem.

Remaining tasks

Manual testing and review.

User interface changes

N/A

API changes

N/A

Data model changes

N/A

πŸ› Bug report
Status

Fixed

Version

8.9 ⚰️

Component
BaseΒ  β†’

Last updated about 4 hours ago

Created by

πŸ‡¨πŸ‡¦Canada amykhailova

Live updates comments and jobs are added and updated live.
  • D8MI

    (Drupal 8 Multilingual Initiative) is the tag used by the multilingual initiative to mark core issues (and some contributed module issues). For versions other than Drupal 8, use the i18n (Internationalization) tag on issues which involve or affect multilingual / multinational support. That is preferred over Translation.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • πŸ‡¨πŸ‡¦Canada Liam Morland Ontario, CA πŸ‡¨πŸ‡¦

    We are having this problem as well on Drupal 9.5. The work-around in #77 is working for us.

  • πŸ‡¨πŸ‡¦Canada Liam Morland Ontario, CA πŸ‡¨πŸ‡¦

    We have had the problem return, despite the work-around in #77. Are others seeing it too?

  • πŸ‡ͺπŸ‡ΈSpain penyaskito Seville πŸ’ƒ, Spain πŸ‡ͺπŸ‡Έ, UTC+2 πŸ‡ͺπŸ‡Ί

    @Liam I'd recommend opening a new issue.

  • πŸ‡¨πŸ‡¦Canada Liam Morland Ontario, CA πŸ‡¨πŸ‡¦

    Looking at it more, I think we're experiencing πŸ› Wrong language field labels after `drush cr` because of Drush language negotiation Needs work .

  • πŸ‡¨πŸ‡¦Canada joseph.olstad

    @Liam Morland, #77 didn't work for us, and I didn't use drush to rebuild cache.

    Debugged the cache tags, the language context is there and the language code shows up in the debug. Still getting the unexpected label values and it seems to be rather isolated.

    We're getting this with display manager. I will try converting it to layout_builder, I suspect the issue will go away with layout_builder but not sure why.

  • πŸ‡¨πŸ‡¦Canada joseph.olstad

    Changing to layout builder didn't make a difference.

    I'm surprised that this is an outstanding issue.

    Seems like there's a problem with the language context and the cache tags not being respected

  • πŸ‡¨πŸ‡¦Canada joseph.olstad

    Patch I tried at 3114824 sounded promising but didn't help either.
    πŸ› Add multilingual support for caching basefield definitions Needs work

  • πŸ‡¨πŸ‡¦Canada joseph.olstad

    Workaround, I wasn't able to find a better way for now.

    Here is an example of what I did, but not exactly since I targetted the preprocess_field a bit more but for this example I'm flattenning it out.

    In this example it's the hook_preprocess_field , but in my case I added a new twig based on the theming suggestions and used hook_preprocess_field__node__field_from__news() instead.

    /**
     * Implements hook_preprocess_field().  This goes into mythemename.theme file and replace hook_ with mythemename_.
     */
    function hook_preprocess_field(&$variables) {
      $langId = \Drupal::languageManager()->getCurrentLanguage()->getId();
      $variables['language'] = $langId;
      $label = trim($variables['label']);
      $label = strtolower($label);
      if ($langId == 'fr' && $label == 'date posted:') {
        $variables['label'] = "Date d'affichage :";
      }
      if ($langId == 'en' && $variables['label'] == "Date d'affichage :") {
        $variables['label'] = 'Date posted:';
      }
    }
    
Production build 0.71.5 2024