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.

CommentFileSizeAuthor
#6 flat_translation.patch18.1 KBMaskOta
Support from Acquia helps fund testing for Drupal Acquia logo

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.

MaskOta’s picture

Is there any plan for this in the near future?
I would like to work on this as it is required for our project but i would at least need some guidance to orient myself in the right direction. @joachim already listed two ways on how to go about this. I would just need some sort of confirmation or even more discussion before i(we) start working on a patch.

joachim’s picture

> @joachim already listed two ways on how to go about this.

Well, they are not two alternative ways of doing the same thing. They are rather, two different ways of adding translation support to flags:

A. A flagging affects all of a node's translations, but the flagging entity itself is also translatable

B. A flagging affects only one translation at a time.

Of course, we could feasibly have A + B combined... It might seem like it should be obvious that, say, the flagging on the French translation of a node is automatically in French, but I bet there are use cases for it.

It's not a case of 'which method is correct?', so much as 'which method is right for your use case?'.

I can say that method A wouldn't take too much work, and might in fact be largely done for us by the Entity system.

Method B is going to be painful. Translations aren't revisions, so Dynamic Entity Reference module won't help us here. We need to be able to reference specific translations, and I don't think there's anything that does that.

How does Comment module handle translated nodes? Comments are attached to all nodes, and do they all simply show?

MaskOta’s picture

FileSize
18.1 KB

I was experimenting with this a little bit but i have no idea if i am moving in the right direction or not.
Additional input would be really helpful.

What i did so far is create a langcode field in flagging table. The flagging link now contains the entity active translation language information which is stored. So you could flag a node for any number of translations.

attaching a patch of my work in progress.

"How does Comment module handle translated nodes? Comments are attached to all nodes, and do they all simply show?" I tested this and yeah they all show.

MaskOta’s picture

Status: Active » Needs review
joachim’s picture

> So you could flag a node for any number of translations.

Unfortunately, with that patch, you can no longer flag the node as a whole.

And more use cases for Flag that I know of would need that. E.g. if you bookmark a node, you'd want to bookmark the whole thing, not just one translation. Ditto for spam reports.

Can I ask what your use case is for flagging single translations of an entity?

MaskOta’s picture

Sure. We have a website where users can create some sort of games. These games can be translated. We also offer the ability to "favourite" (flag) these games. In the current system if you flag an italian translation of a game, you get all translations listed on your Favourites page.
To get around this problem we are listing only the original language of node under favourites. The problem is that the original language can be hebrew of chinese which would really confuse users when they see the listing. And the english version is not always available.

Website in question is https://playdecide.eu

"Unfortunately, with that patch, you can no longer flag the node as a whole."

I know this patch has all sorts of problems. I just wanted to know i am going down the right path. There should probably be a new option for each flag that allows you to flag each translation or the entity as a whole... TBD

joachim’s picture

> In the current system if you flag an italian translation of a game, you get all translations listed on your Favourites page.

It sounds more like you need to fix your view of favourites rather than go down this rabbithole of flags per translation. If a user likes a game, they like that game as a whole, not just a single translation. It doesn't make sense semantically to like just one translation.

MaskOta’s picture

Yeah, i would like to do a quick easy fix. But how?

A user could favourite games in all sorts of languages. An Italian player could favourite an Italian translation of a game that was originally in Chinese. That same person could then favourite and english or german translation of a game. What would i show in the view then?

joachim’s picture

> That same person could then favourite and english or german translation of a game. What would i show in the view then?

Who is looking at the view? Does it not make sense to show the output in the language of the current user, and if that translation is missing, fall back to the original language of each node?

joachim’s picture

Another question that springs to mind is that it's not clear what your translations represent.

If you have a node for Cataan, say, does the fr translation of that node simply represent the same thing, but with the text translated for a French speaker? Or does it represent the French version of the game, that is, a different physical object which is slightly different from the English translation of the game?
If the latter, then I don't think you are using translations correctly, and you really should have different nodes for the different things.

MaskOta’s picture

"Does it not make sense to show the output in the language of the current user, and if that translation is missing, fall back to the original language of each node?"

It would not be ideal. Like i said an Italian could flag an english version of a chinese game. Have chinese characters suddenly appear in your favourites is confusing.

"If you have a node for Cataan, say, does the fr translation of that node simply represent the same thing, but with the text translated for a French speaker?"

Yes, translations are just that. Translations. But since this is a kind of open platform it is up to the translator how it turns out in the end.

Do you think that having flags per translation is not worth the development time? Is my case really an edge case?

joachim’s picture

> Like i said an Italian could flag an english version of a chinese game. Have chinese characters suddenly appear in your favourites is confusing.

Ok, take away the problem of flagging completely. I am a user of the site whose language is set to Italian. I go to look at the node for a Chinese game. What should I see?

> Do you think that having flags per translation is not worth the development time? Is my case really an edge case?

Another thought experiment: instead of favourites, consider a flag that means 'I own this game'.

Do you want your data to represent 'I own Cataan in Italian', or 'I own Cataan'?

If the former, then you should not use translation, but have one node for each version of the game. If the latter, then translate your nodes, but flag the whole node, not a particular translation of it.

MaskOta’s picture

"I am a user of the site whose language is set to Italian."

The website interface is english for everyone. What you can do is search games in general, where you get all translations listed, or in a particular language. So if you are looking for italian translations of games, the one that was written in chinese would only show if the italian translation existed.

"If the former, then you should not use translation, but have one node for each version of the game. If the latter, then translate your nodes, but flag the whole node, not a particular translation of it."

There are more things tied to our system than what i mentioned. The data model is correct for what we do. For example, users can submit results for each game no matter the language. These results are then aggregated and visualized.

What is still dont know tho is weather what i did in my patch is any good or completly useless.