The http://Entity translation module supports field-based translation in D7.
However, to create several translations, you need to enter a separate tab for each language.
The Language Sections module would be an ideal frontend.

Can the Language Sections use Entitiy Translation as a backend? That is, can you store each language in it's own field-language-value record? (and vice versa retrieve when editing)

Comments

Andy Inman’s picture

Andy Inman CreditAttribution: Andy Inman commented

Let me check that I understand - you're saying provide a sort of "power-user" UI using a single text area to enter values for a field in multiple languages, correct? What would be the main advantages, faster input? I'll take a look at the Entity translation module to see if I can understand better.

johnv’s picture

johnv
Primary language Dutch
CreditAttribution: johnv commented

Well, as for the UI (and thus user rights), there would be no change. I am not sure where you store your data now: I think it is all in one field :
table: field_data_myfield
entity_type = node
bundle = my_content_type
entity_id = nid
revision_id = whatever
language = 'en' for the language of the node.
field_myfield_value: "---en--- English"+"---nl--- Nederlands"+"---de--- Deutsch"

With Entity Translation, you can set a field to Translatable. You do not have a copy per node per language, but a copy per field. (IMO Field Translation is a better module name), so:
A non-translatable field gives only 1 record:
language = 'und'
field_myfield_value: "---en--- English"+"---nl--- Nederlands"+"---de--- Deutsch"
A translatable field gives 3 records:
language = 'en'
field_myfield_value: "English"
language = 'nl'
field_myfield_value: "Nederlands"
language = 'de'
field_myfield_value: "Deutsch"

Andy Inman’s picture

Andy Inman CreditAttribution: Andy Inman commented

Ok, I *think* I understand - so the objective would be to provide a UI for editing in LS format, even though the data would be held in individual fields (one per language), yes? I am still not sure *why* you would want to do this - because editing would be faster?

To confirm, yes, all LS content for all languages is stored in a single field - this is because originally the module tried to cater for the situation where only a single text field was available, but multiple languages needed to be handled.

I think the best way to handle your requirement would be a separate module that does some form_alter work - I don't think LS is a necessary component - but maybe I am still not understanding!?

johnv’s picture

johnv
Primary language Dutch
CreditAttribution: johnv commented

In think you understand well.

I am still not sure *why* you would want to do this - because editing would be faster?

Yep, I have a use case where a node type has several fields, and only 1 language-relevant textfield. So your LS is a perfect solution for that, since you can compare languages easily. OTOH, I am not keen on introducing too many translation policies: LS, COntent Translation, Entity translation.

I think the best way to handle your requirement would be a separate module

Perhaps you are right, it would merely be a field widget, then.

GN’s picture

GN CreditAttribution: GN commented

I think Language Sections is actually sort of "Poor man's entity translation": with LS, you can make a unilingual field or smth pretend it's multilingual :) - which is very useful in situations where the "true" multilingualism of this smth (e.g. a view header, or a block content) is either unavailable or inconvenient; but I don't think its a good idea to mix LS with Entity translation.

However, the Entity translation UI at this moment is really in need of improvement (see e.g. a discussion at #1282018: Improve UX of language-aware entity forms).