Because of the new translation system in core, nodes (or any entity type) have the same ID, no matter what their language is.

Afaics, there's no way to flag a node which has different languages as the flagging table does not store the langcode of the thing which is being flagged. In D7, using content translation, you did not have that problem because the nid is simply different. Not sure how things were handled when using entity translation.

Adding the langcode to the flag entity to store it is relatively easy, but it's probably not always the desired effect to store different records depending on your use case. Sometimes you probably just want to flag it globally over any language, sometimes not, so I guess some logic is needed here too.

Comments

swentel created an issue. See original summary.

socketwench’s picture

Category: Bug report » Feature request

Hm. It's a good idea, but I'm concerned about all the added complexity. I'm going to mark this as a feature request since multi-lingual changed so much in D8 that this would require some additional development.

joachim’s picture

Having to keep flags in sync across different nodes in a translation sets was a bane, so I for one was glad to see the end of this!

In D7 and prior, a node flag let you choose whether to do this, or handle each node in a translation set differently. If you were using Entity Translation, then there was only a single node, so no special handling applied.

> Adding the langcode to the flag entity to store it is relatively easy

Would that be different from a langcode field if the flagging itself were translated?

You might want one flagging for a node across all translations, but to then translate that flagging's fields.

Alternatively, you might want one flagging for a single translation, but not make flaggings translatable.

For the record, I think that one flagging per translation is going to be an almighty headache, just as one flagging across translations was on D7.