When we set entity translation for a content type
("Multilingual support -> Enabled, with field translation")
a node of this type becomes truly multilingual (with content in many languages inside), and I guess it would seem logical for this node per se to have language-neutral status.
However, for a language-neutral node we just don't see the "Translate" button and thus cannot translate its content. (Which is absolutely reasonable for node translation, but why should it be the same for entity translation?)

So, to entity-translate the content of a multilingual node (let it be a news article we post on the front page), we need to ascribe a specific language to it - let it be English (default). Now we can translate it (say, into French) - but its French content may not be visible on the French front page because the node is "English" and thus blocked by the node-language filter.
To fix this problem, we need to go to "content filtering by language" settings (admin/config/regional/i18n/select) and make sure that "Select nodes by language" option is disabled.
(Which, however, may cause problems for us if we want to use both node translation and entity translation on the same site).

Maybe a better solution would be to enable entity translation for language-neutral nodes?

Comments

GN’s picture

One more implication:
Disabling the "Select nodes by language" option also means we cannot hide from the front page the articles that have not yet been translated: they will be visible in their original language. So,

(Language-neutral nodes cannot be translated) =>
=> (Need to ascribe a specific language to each translatable multilingual node) =>
=> (Contradiction between node language and translated content language) =>
=> (Need to disable content filtering by language) =>
=> (Entity translation cannot coexist with node translation) AND
(Non-translated nodes cannot be hidden and will be displayed in the original language)

Or am I missing something?

Gábor Hojtsy’s picture

Component: Code » Base system
Status: Active » Closed (works as designed)

http://drupal.org/node/1282018#comment-5901838 should help you understand this better. That i18n and entity translation does not work 100% great together is hopefully not best resolved with hacks like this suggestion :)

Maksym Kozub’s picture

Status: Closed (works as designed) » Active

Gábor, in my view this is not a hack but a valid suggestion based on a good fundamental idea. See my comment at http://drupal.org/node/1282018#comment-5804406. You seem to be based on the idea of _translations_. In reality, other workflow types are possible. One of those is e.g. creation of a language-neutral node where the author would be language-independent, while the title and main content would be language-dependent, and no language version would be a _translation_ of another one.

Gábor Hojtsy’s picture

@Maksym: the way we currently represent that is that we store the original submission language of the node as the node language. Since you do have some language specific details, and Drupal cannot store data related to different languages in the same variant of the entity, your original node is relevant to a specific language. That is what we store in the node language value, and not language neutral. If the node altogether is language neutral, it means it does not have language specific bits, and the system does not need to look under to the field level, because you already told the system that there is nothing language specific. Its just slightly different logic, but what you want to achieve is totally achievable with Drupal.

Maksym Kozub’s picture

...What you want to achieve is totally achievable with Drupal.

Technically, it was achievable even before the latest UI changes. I am not saying it was impossible e.g. to have all sorts of language versions etc.: I would just use the translation form to enter different language versions. However, in a situation where they are independent language versions rather than translations, I would say that doing things that way was a "hack" — not a software hack but a "concept/workflow hack" :).
Now that the translation form becomes a language-aware editing form, it looks better on the concept/workflow side. Still, even in your reply here you mention "the original submission language of the node" that we store "as the node language", and you say that "your original node is relevant to a specific language". I am saying that in my idea of the workflow, my _node as such_ does _not_ have any "original" vs "derivative" versions, and my node as such should _not_ be relevant to any specific language.
Look at an example.
My node/1 as an entity would have two text fields, "Title" and "Main content", each of those having, say, English and Russian versions, and one image field to show my picture.
node/1 author: Maksym Kozub (I do not treat it as English, — this is just a generic Latin variant of my name :))
Title (English): "About me"
Title (Russian): "Кто я такой" (Who I am)

Main content (English): (some detailed version of my bio in English here)
Main content (Russian): "Я — переводчик, и этим всё сказано" ("I am a translator/interpreter, and that's it". Suppose I have decided for some reason that for my Russian readers it will be enough to see that :).)

Image: the same in both versions.

Why, oh why should this entity (in this specific case, a node) as a whole be relevant to any language etc.?

My apology if I sound persistent :). I am a Drupal newbie, but I believe I do know something about multilingual workflows, different concepts of handling multilingual content, etc., and I do not see where I am fundamentally wrong with the above question.

Gábor Hojtsy’s picture

With Drupal users, we are just seeing a lot more interest in having a "fallback" or "original" language recorded and we build our original tools and workflows around that because that is what we see the 80% use case is. We are not building for "independent language versions stored in the same entity" because that is not the common use case. Even for a user profile, you represent a person who has a mother tongue, and let's face it most people learn one primary language and then learn secondary languages, not learning multiple languages absolutely parallel at the same time, so their logical bio representation would also represent them in a primary language initially. I understand where you are coming from, but that is not the 80% use case that we see our users have and therefore not designing for that.

Maksym Kozub’s picture

Even for a user profile, you represent a person who has a mother tongue, and let's face it most people learn one primary language and then learn secondary languages, not learning multiple languages absolutely parallel at the same time, so their logical bio representation would also represent them in a primary language initially.

Well. the fact that I have my mother tongue has nothing to do with concepts and workflows for multilingual content. E.g. it is logical for many fellow colleagues of mine to have their bios etc. in English first, English being the language of their clients etc. Besides, I have used this example, but I could build a similar example of content created by a multilingual international _organization_, with people of various language backgrounds etc.
Anyway, your point is well taken:

We are not building for "independent language versions stored in the same entity" because that is not the common use case.

I hope this approach will change at some point in time. In the meantime, as I already said, a language-aware edit form is much better on the workflow side, although it would be even better to have a language-neutral node have it, too :).