Overly generic labels of default flags cause problems for translated sites

Created on 30 March 2022, about 2 years ago
Updated 12 January 2024, 5 months ago

Problem/Motivation

The default configuration causes translations to be overwritten.

I had a very puzzling experience after installing this module and trying to customize the labeling of the flags, partially because I was completely unaware of a feature of Drupal core. I boiled the problem down to this:

This module comes with a few default flag configurations, one of which has as its label "Content". I wanted to change this to something like "Subscribe to content", but my site is configured to show the Dutch language, so all content gets saved as Dutch, wherever it is translatable. "Subscribe to content" is "Abonneren op inhoud" in Dutch. After applying this change, "Abonneren op inhoud" would show up everywhere it would normally say "Inhoud", which as you've probably guessed, is the translation for "Content",

Someone more familiar with the Drupal config translation may already be guessing where this is going, but I was completely unaware of this mechanism until now. Apparently, when you are changing a translatable string in a config item that is derived from a default content item (from a module's config/install directory), the locale module will load that default content, pull the translatable strings out, and assume that whatever you are supplying now is an update to the *interface translation* of that string.

Steps to reproduce

  • Have a site with at least one extra language in addition to English
  • Go an configure the content flag created by this module
  • Change the label. Doesn't really matter what, just make sure you are saving the config item in another language than English
  • Notice how the default translation for "Content" is changed

Proposed resolution

Change the labels of the default shipped flags for this module to "Subscribe to content", "Subscribe to terms" and "Subscribe to users".

Remaining tasks

  • Create MR
  • Review
  • Merge

User interface changes

The labels of the default flags will change.

API changes

None.

Data model changes

None.

Original report

I tried to rename a flag label, but the translation got changed. If I change the translation, the flag label also changes.

πŸ› Bug report
Status

Needs review

Version

1.0

Component

Code

Created by

πŸ‡©πŸ‡ͺGermany d4t3r

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

Not all content is available!

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

  • πŸ‡³πŸ‡±Netherlands eelkeblok Netherlands πŸ‡³πŸ‡±

    I ran into this too, but missed this issue so I created a new one: πŸ’¬ Generic label of default flag causes problems for translated sites Closed: duplicate . I did do some debugging and encountered a mechanism in Drupal I was previously unaware of. I suppose it is reasonable behaviour, up to an extent, but the problem is that the flags created by this module use very generic labels. Upon saving, these get compared to the default configuration that is in the module, and Drupal concludes you are updating an *interface translation*. I'll update the issue summary with that of the other ticket, making sure I don't destroy any info.

  • πŸ‡³πŸ‡±Netherlands eelkeblok Netherlands πŸ‡³πŸ‡±
  • Merge request !18Give more descriptive labels to flags β†’ (Open) created by eelkeblok
  • Status changed to Needs review 5 months ago
  • πŸ‡³πŸ‡±Netherlands eelkeblok Netherlands πŸ‡³πŸ‡±

    I whipped up an MR in the web IDE, I'll be baking a patch from it and trying on my project next.

  • πŸ‡³πŸ‡±Netherlands eelkeblok Netherlands πŸ‡³πŸ‡±

    Updated the issue title to more accurately reflect the problem with the module.

    BTW, if you are wondering (like I was) if this is not a problem with core, I don't think so. I think it has to do with translatables ending up in the translation files for modules. Also, it is possible to provide a context (see e.g. the config schema cheatsheet) , like it is for strings ran through t() and friends, to avoid this problem for short strings like these. That could have been a solution to this issue too, but I think these labels make more sense and are more descriptive, especially when a site has a long list of flag types.

Production build 0.69.0 2024