- 🇳🇱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.
- Status changed to Needs review
over 1 year ago 12:33pm 12 January 2024 - 🇳🇱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.