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.
Change the labels of the default shipped flags for this module to "Subscribe to content", "Subscribe to terms" and "Subscribe to users".
The labels of the default flags will change.
None.
None.
I tried to rename a flag label, but the translation got changed. If I change the translation, the flag label also changes.
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | admin menu.png | 67.02 KB | liquidcms |
| #4 | User interface translation.png | 28.37 KB | liquidcms |
| #4 | Edit French translation for Watch flag.png | 15.16 KB | liquidcms |
| #4 | Edit Flag.png | 27.22 KB | liquidcms |
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
elberHi @d4t3r can you to be more specific, what file is the issue?
Comment #3
drupalbubb commentedI activated the Message Subscribe Example module and it creates a flag labeled "Content". I need to rename this to something more specific, e.g. "Subscribe content". But this renames the widely used / translated word "content" for the whole system.
Comment #4
liquidcms commentedI think i have stumbled upon the same issue.
I have modified the Label for the subscribe_node flag to "Watch", and now, when i translate this flag and change the translation of the Name of this flag from Watch to anything, this overrides the User Interface string translation with that value.
I know, this makes no sense, so some screenshots:
edit flag:
edit flag translation:
verify it has modified Content string translation:
see impact on Admin menu ("Content"):
Comment #5
liquidcms commentedComment #6
liquidcms commentedA little more digging and re-reading the OP comment that we are both using the Message Subscribe module.. safe bet it is that module which is breaking this.. going to move this to their q.
Comment #7
liquidcms commentedComment #8
liquidcms commented@d4t3r, sorry about moving this to MS.. if you feel it is a Flag issue (easy enough to test - which i'll do now) then please move it back to the Flag queue.
Comment #9
liquidcms commentedChanging this to Major as the module is not really usable with multiple languages.
These are the steps to show the issue:
- with the subscribe_node flag set the flag link text to "Watch"
- translate this flag and set the FR for the flag link text as "Suivre"
The flag now works correctly and shows Watch/Suivre for the flag on the respective language pages.
run drush command to import custom translation file: drush locale:import fr ../translations/ssc-plus.fr.po
When this runs it also imports the .fr.po files for all contrib modules which includes the file: message_subscribe-8.x-1.1.fr.po.
This file has the translation:
msgid "Subscribe"
msgstr "S'abonner"
event though my flag link text has been set (in config) as "Watch"; it is hard coded in the flag.flag.subscribe_node.yml file to be "Subscribe" and the combination here changes my CONFIG for the FR setting to be changed to "S'abonner".
I am not 100% sure where the break is here; but i think i see the issue now:
When i run the Drush locale:import command it does 2 things: it imports my custom .po file and for some reason it reloads default config of all the contrib modules.. which will override the config for Message Subscribe and wipe out my changes.
Perhaps i am going about this wrong? Perhaps the default flags defined by this module are not intended to be used and are only examples? Although pretty sure they are used in the MS code as defined by their default installed config.
Comment #10
liquidcms commentedI think the work-around here is to simply do config import after locale import. :)
Comment #11
eelkeblokI ran into this too, but missed this issue so I created a new one: #3413871: Generic label of default flag causes problems for translated sites. 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*. In fact, the interface tranlation for "Content" or "Users", which obiously should not be change to "Watch" or "Follow", or whatever. I'll update the issue summary with that of the other ticket, making sure I don't destroy any info.
Comment #12
eelkeblokComment #14
eelkeblokI whipped up an MR in the web IDE, I'll be baking a patch from it and trying on my project next.
Note that when trying the patch, I think you only need to apply it, you don't need to re-install the module; it is about Drupal comparing to the version of the flag that is in the module's config/optional directory. With the patch applied, the change will still count as a translation, but now against a much more specific string which is unlikely to cause collisions with other uses of the same original string.
Comment #15
eelkeblokUpdated 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.