Problem/Motivation

The current entity translation UI was designed to match more or less the user experiece of the core node translation UI. The main difference is that, since here we are not dealing with multiple entities, the actual translation screen is not the original entity edit form, but a stripped down version holding only the translatable bits (translatable field widgets, publishing status, etc.). However, this is true only for translations, AAMOF when editing the original values we get the standard entity edit form.

This approach has a couple of big consequences:

  • On the UX side, as already noted by @peximo in the early days of the TF4 core patch, we are totally losing the contextual editing model we have throughout our content editing experience: the edit tab always leads to the edit form populated with the original values, no matter which translation the user is viewing. Aside from that, you get a different form depending on which language you are trying to edit, which may be confusing as hell, if you are allowed to edit any translation and there is no strong difference in your translation workflow between original and translated values.
  • On the architectural side, there is no easy way to reuse the widgets other modules add to the edit form, which might hold translatable elements. For instance, the path alias widget is special-cased at the moment, because it's a core translatable element, but menu translation, pathauto support and anything else would need to be explicitly supported to appear on the translation form. This model simply does not scale.

A side-issue being addressed, since we are revamping the translation UI, is how to deal with original values. In the current model, borrowed from the node translation UI, form widgets are prepopulated with the original values when creating a translation. This solution is far from ideal, since once the translation is over we have no clue of what the original values are. If we need to update the translated values because the original ones are changed, we are out of luck.

Proposed resolution

A solution to both the problems cited above is turning the usual entity edit form into the translation form by making it language aware: this way a user can get the contextual editing, because the edit form is populated with the values actually being viewed, if a translation corresponding to the current content language exists. Moreover the user always gets the same form, unless per-language permissions are in place, in which case only the allowed fields would be present, as usual.

On the architectural side form additions are always in place, they "just" need to support multilingual values, which is not hard to do once the content they relate to is multilingual enabled. We are planning to post a core patch introducing the entity_language() function, which could be used to retrieve the language of the translation actually being edited.

Since the edit form will hold shared field widgets alongside with translatable field widgets, the risk of performing unintended changes will be extremely high, if we do not design our UX carefully. One suggested possibility is making shared field widgets available only when editing the original values, the other one is finding a way to make always clear to the user that the change being performed will affect all the translations. We can assume we will mainly deal with variants of two translation workflows:

  • The simple model is suitable for most small sites: here translations are "normal" content and are handled the same way no matter which language they are assigned. Usually in this scenario there is a single content admin role which has the same permissions on all the translation. Arguably people being assigned this role expect to deal with every translation as a standalone entity.
  • The editorial model instead is more likely to be found on sites having an admin staff with different roles. Here content admins would have full powers on content, while translators would enter translations only for a (possibily strict) subset of the entity fields. Moreover translators would be unlikely to create the original content.

In the first scenario, showing the shared field widgets only when editing the original values might end up in a cumbersome and confusing experience, AAMOF we would lose again the contextual editing capability, since a shared value would be viewable but not editable when dealing with translations. Moreover a missing field in our forms usually means that the user has no permission to edit the value, while in this case it would just mean that the translation being viewed is the "wrong one". OTOH it might be really hard to find a solution letting users safely deal with shared field widgets.
Which is the best solution here is yet to be decided.

Remaining tasks

  • Decide how to deal with shared field widgets.
  • Decide how to deal with original values.

User interface changes

et_ui_tng-01.pnget_ui_tng-02.pnget_ui_tng-03.pnget_ui_tng-04.pnget_ui_tng-05.pnget_ui_tng-06.pnget_ui_tng-07.pnget_ui_tng-08.png

API changes

No relevant API changes foreseen at the moment.

Original report

I had a long UX discussion with @Gabor and @webchick about the current translation UI: we agreed that users should not see a different form depending on whether they are editing the original field values or the translated ones.

The solution we came up with is providing a localized version of the entity edit form and somehow highlighting the untranslatable fields to outline that changing their value will affect all entity translations.

Files: 
CommentFileSizeAuthor
#141 qtranslate2.png12.42 KBdrupalina
#119 entity_lang_ux-19.png136.22 KBsteinmb
#105 et-1282018-105-1.png10.14 KBplach
#105 et-1282018-105-2.png7.26 KBplach
#99 initialdesign.jpg83.29 KBBojhan
#96 et-uitng-1282018-96.patch120.17 KBplach
PASSED: [[SimpleTest]]: [MySQL] 62 pass(es).
[ View ]
#93 et_ui_tng-1282018-93.patch118.63 KBplach
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch et_ui_tng-1282018-93.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#88 et-1282018-88.patch118.91 KBplach
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch et-1282018-88.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#85 et-1282018-85.patch117.31 KBplach
FAILED: [[SimpleTest]]: [MySQL] 61 pass(es), 1 fail(s), and 1 exception(s).
[ View ]
#83 et-1282018-83.patch115.79 KBplach
FAILED: [[SimpleTest]]: [MySQL] 55 pass(es), 6 fail(s), and 0 exception(s).
[ View ]
#78 ScreenClip.png57.4 KBbforchhammer
#78 shared-fields-handling-1282018-78.patch5.6 KBbforchhammer
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch shared-fields-handling-1282018-78.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#59 entity-translation-ui-mockup.png44 KBpixelite
#57 et_core_work-1282018-57.do_not_test.patch9 KBplach
#56 et_core_work-1282018-56.do_not_test.patch2.11 KBplach
#50 switchlinks-error-1282018-50.patch3.14 KBbforchhammer
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch switchlinks-error-1282018-50.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#45 et_ui_tng-01.png88.83 KBplach
#45 et_ui_tng-02.png91.41 KBplach
#45 et_ui_tng-03.png38.18 KBplach
#45 et_ui_tng-04.png54.28 KBplach
#45 et_ui_tng-05.png88.64 KBplach
#45 et_ui_tng-06.png98.08 KBplach
#45 et_ui_tng-07.png200.39 KBplach
#45 et_ui_tng-08.png198.63 KBplach
#36 et_core_work-1282018-35.patch5.1 KBplach
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch et_core_work-1282018-35.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#33 idea for edit node with translatable entities ui.png13.13 KBcosmosian
#33 idea for edit node with translatable entities ui 2.png16.23 KBcosmosian
#18 et.png6.77 KBplach
#6 et_core_work-1282018-6.patch3.11 KBplach
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch et_core_work-1282018-6.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Comments

Subscribing...

And will it be possible to grant certain user permission to translate (translatable) fields, but not to change values of untranslatable ones? Would be nice to have such a feature.

Subscribing

Issue tags:+montreal

Tagging. Where can people find this code?

Here is the development branch: it needs the core patch I was not able to roll yet (hopefully tonight):

http://drupalcode.org/project/entity_translation.git/shortlog/refs/heads...

Just click on the snapshot link to get a tarball if you cannot use git.

StatusFileSize
new3.11 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch et_core_work-1282018-6.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

This is the core patch I'm using to work on the new UI. I'm working on nodes atm so the core patch supports only those, hence it's not ready to be posted on the core queue. However it's needed to preview the current changes.

Component:User interface» UITNG

Component:UITNG» Code
Issue tags:+uitng

using tag instead of component

The @TODO comment about backward compatibility is not clear. Is LANGUAGE_NONE a constant only defined in Drupal 8+? If so, you might replace the @TODO with:

  $langcode = isset(LANGUAGE_NONE) ? LANGUAGE_NONE : FALSE;

and this will be compatible across major versions. Alternatively, one could check DRUPAL_CORE_COMPATIBILITY constant.

No, LANGUAGE_NONE exists also in D7 but returning it would change the current behavior, which assumes a null value when an entity has no language property.

Issue tags:+Usability

Let's summon the UX folks.

How do we help out with this issue is not clear
just test the core patch from comment #6 and regular entity translation ?

will this issue help solve the
pathauto translatability ? (#1155134: Integrate pathauto bulk generation),
menu translatability ? (#1123610: Menu item translation, #1182058: Add Entity Translation (entity_translation) support for menu items using Menu Translation)

How do we help out with this issue is not clear
just test the core patch from comment #6 and regular entity translation ?

If you wish to test the ongoing work (which is pretty incomplete atm) you can checkout the ml_edit_form git branch or download the related tarball by clicking on the lastest snapshot link from the repository viewer page.

The core patch in #6 is need to make the new UI work correctly.

Please don't post here or open new issues about bugs and functional problems since the work is not finished yet. UX comments instead are welcome.

will this issue help solve the pathauto translatability ? [...]

Hopefully yes, since the pathauto and menu widgets would be in place even for translations.

is there any progress on this
I would be in favor of getting something working and discuss UX later
(I can help with testing and small improvements if needed)

ET is a great module but lucks pathauto/page title/menu and lots of other support which are greatly needed and maybe we can tackle with this approach ?

I would be in favor of getting something working and discuss UX later

This is problably the route we'll take, unless some UX guy shows up soon.

I'm planning to get back on this in a few days and try to come up with something basically working. The feature branch linked in #5 may be used to test the ongoing work.

Can someone prove a screen shot of the current status?
I think it would be nice if on the Node Edit form, the translatable field looks like a multi-value field.
Each value would have a Language field/icon just before the value box.

The module Double field does something similar.

I think it would be nice if on the Node Edit form, the translatable field looks like a multi-value field.
Each value would have a Language field/icon just before the value box.

That would work well for a bilingual site, but not for a site with a large number of languages.

StatusFileSize
new6.77 KB

This is how the UI will look like:

ET UI

We are not going to implement a per-widget language selector. This is something that has been discussed but we rejected it as it does not fit well the current behavior, AAMOF ET provides per-language subentities, it does not handle language at field level.

The main issue still open is how to visually distinguish between translatable fields and shared ones.

The shown UI raises me another question: don't you need an original field/value to know WHAT you are translating? (altough I realize that this wasn adressed in previous ui s)

I think there is a high risk that people will miss any clues about which fields should contain langugage-specific values and which are going to affect all languages. I visualize a mess as translators inadvertently alter the original values of fields that should not be translated.

Plus in the sites I have been working with, the 'translator' is a different and much more limited role than the 'author', and the translator should not be able to alter the original values.

So I suggest presenting the fields that are shared as disabled fields on all languages other than the original one. The translators can see them and cannot touch them, and only the author can alter the original values, and those can only be altered when editing the original language.

Which brings up another point. Will there be a way with this new form to keep translators from being able to edit the 'original' value of the entity?

And for the 'clue' about what to translate, the default value for empty fields could be the original value. Then we could have a test in the submit processing to see if the translated value still matches the original value. If it does, it hasn't been translated and you wipe it out again before saving.

Another suggestion for the clue about the original value. Leave the field empty but add a button next to each translated field that would open up a modal window that contains the original value. That button would still work after a translation has been entered so the translator could double-check that the translation is still correct.

Or instead of a button next to each field that brings up the original value of the field, a single button on the form that would open up a modal window with the original value of the whole form.

Or rather than a modal window maybe a button that would expand the form into two panels, with the original value of each field on the left and the form item to be translated on the right.

I think there is a high risk that people will miss any clues about which fields should contain langugage-specific values and which are going to affect all languages. I visualize a mess as translators inadvertently alter the original values of fields that should not be translated.

We already agreed during the initial discussion that we need visual clues that fields are language-specific and/or shared. There has not been any feedback about what this clues should look like yet, so nothing has been done in this direction atm.

Plus in the sites I have been working with, the 'translator' is a different and much more limited role than the 'author', and the translator should not be able to alter the original values.

We will need to introduce permissions to prevent original values from being accessed or even define per-language access to entities through appropriate permissions and/or user configuration, discussion welcome (see also http://groups.drupal.org/node/197848#ui).

So I suggest presenting the fields that are shared as disabled fields on all languages other than the original one.

Disabled widgets are a pain and read-only (rendered) values have been removed from the current translation form for similar reasons. Moreover they have been deemd a poor UX choice: #1032846-2: Remove read-ony non translatable fields from the translation form.
I think not displaying shared fields to users that don't have access to them is the most consistent solution.

And for the 'clue' about what to translate, the default value for empty fields could be the original value.

This is more or less the current behavior, it's just not been implemented yet in the new UI.

Or rather ...

Or even a collapsed fieldset below each translatable field widget :)

It would be nice to have a feedback from Bojhan or Yoroy on this, since I'd like to design this form as the base for what will become the D8 translation UI.

I understand that the visual clues don't exist yet. My point is that I don't think there is any possible clue that might not be overlooked. The only thing that is safe is to hide or disable the shared fields. IMO anything else is a recipe for disaster.

I do agree that disabled fields are a PITA. Hiding them is fine by me. Or in other places we have discussed showing the display of the field instead of the form element, so you can see that a field goes there and what it contains. Or even just display the field name with ' (untranslated)' next to it as a sort of placeholder for the missing field. Any of those would prevent someone from altering the value.

And to follow up on my concern about shared fields. We had shared fields in CCK. We tried every possible way to explain to people that if they share fields and change their values it will affect all the places they are shared. No matter what we did people missed that and the issue queues were full of 'OMG I destroyed my data' issues from people who made those changes. I am very very concerned that if you expose a shared field on every translation form it is going to get altered when it shouldn't. Why open ourselves up to those problems? It is simple enough to just say those fields can only be altered in the original language, by whoever has rights to alter the original values, and everywhere else they are hidden.

I understand that the visual clues don't exist yet. My point is that I don't think there is any possible clue that might not be overlooked.

I think it's a fair point, altough always having to go to the original version to edit shared values would slow down editing in many situations. Moreover we would be reintroducing the distinction between original form and translation form, just at a different URL.

That said, I'm not an UX expert, so I'd really like to read replies from more authoritative voices than mine :)

I think it's a fair point, altough always having to go to the original version to edit shared values would slow down editing in many situations.

But if you think through the likely workflow, that would rarely be an issue:
- Original author creates an entity, filling out both values to be translated and values not translated.
- One or more translators come in, and need to only touch the fields that need translation.
- If one of the original values needs to be altered, it will most likely be a decision of the original author to make that change, and they would most likely be doing that in the original language.

In fact, the only time this would be a problem is if one person is both creating the original content and also doing the translations. And even then they are likely to still do it the same way: create the original, then create a translation and touch only the values that need translation. I can't think of very many situations where someone would be trying to translate *and* alter the original shared values at the same time. That seems like it would be an edge case, not the norm.

Moreover we would be reintroducing the distinction between original form and translation form, just at a different URL

Yep, but that form is actually pretty close to what we really need. The only problem with that form is that it is incomplete, it doesn't have all the form elements that might need translation.

Can anyone explain me the original goal here? The current issue summary, isn't very clear.

I think I grasp the UX gain that we get from this improvement, I am unsure if we want to abandon our original model which scales better and can be applied in a lot more usecases.

Are we changing what is displayed on the forms? I thought, we already had language-aware edit forms in our old model? What is exactly the question you are asking the UX-Team its feedback on?

Agree we could use some use cases / "What problem are we trying to solve?" / etc. info here. I remember this discussion vaguely, but it was an awfully long time ago and I've had many subsequent discussions since. :)

I updated the issue summary with some background and use cases.

@Bojhan:

I am unsure if we want to abandon our original model which scales better and can be applied in a lot more usecases.

I ain't sure I understand what you mean here: could you expand on this?

Are we changing what is displayed on the forms? I thought, we already had language-aware edit forms in our old model? What is exactly the question you are asking the UX-Team its feedback on?

The core node translation has langauge aware forms because every translation is a different node. Here we are trying to get closer to that model.

Issue summary:View changes

Issue summary

Issue summary:View changes

minor cleanup

I came here because the entity translation model is a great development with a lot of potential on further improving multilingual possibilities and UX for (mostly the backend side of) drupal sites. But it has presently still some serious flaws with UI and integration in pathauto and menu on an automated level, it basically ignores entity translations because the node itself only has one language connected to it as far as I've been able to figure out. Next to that the UI for managing the field values for the various translations has a quirky workflow that confuses my users/customers.

I'm glad the issue is already being addressed here and would like to add my ideas to the various problems mentioned in the discussion. Like most here I'm focussing on Node translations, not Taxonomy terms (problems are not as pressing there in my opinion and can be dealt with later).

Problem 1 - UI for Editing nodes with translatable entities

Would it be an idea to have the shared fields in a separate button when Editing the node? Like the screenshot in #18 shows a "tab" button under Edit for each language you could add one for the shared field widgets and use the language ones only for the translatable field widgets.
as part of the language buttons

This would mean pulling all shared fields out of the edit screens once the node has been created so there is no chance of accidentally changing them. So they don't show no matter which language is being edited, even the original one.

In the add node screen used to create new content (nodes) all field widgets would still need to be immediately available as they might have Required fields that need to be set before the node can be saved. This workflow and screen would not be affected by any changes to the Editing workflow and screen(s).

The position of the shared fields button as part of the language buttons or between "Edit" and "Translate" tabs a level higher would be up to the developers I guess, as they can better oversee the long term consequences and development problems of either choice. From a UX point of view I can't see pressing issues with either position (one mouse click number difference) but would prefer the higher level tab if development effort would be the same for either choice.

The tabs for a node with entity translations enabled could be:

  • View
  • Edit (Translatable Fields) -> buttons for each added translation beneath it
  • (Edit) Shared Fields
  • Translate(/Manage Translations) -> add new translations and go to appropriate language tab of edit translatable fields screen

as part of the higher level buttons

Problem 2 - Permission Management for translatable fields

Perhaps the splitting up of widgets over various tabs would make permission management easier as well. I.e. giving merely viewing rights for translators to the shared fields "tab" and only allowing the creator/some role to edit the values in it.
Language permissions could be added as well maybe to allow different groups of translators only to add/edit translations of a (set of) enabled language(s). This would include access to the language "tabs" when editing translatable fields.

Problem 3 - Usecue to consequences of messing with shared fields

Adding a clear warning text above the values in the shared fields tab that changes made here will affect all languages should make its purpose clear.

Together with the fact that they are at another screen/tab it also adds another clue that they are not editing a normal translation.

Problem 4 - Many enabled languages to manage tend to mess up the screen

As mentioned somewhere in the thread here you would be swarmed by "tab" buttons if there are a lot of languages enabled. So perhaps add a possibility to set a cut-off point from which the separate language buttons are turned into a little form? Choose the language from a dropdown menu and click an "Edit for this language" button. Next to it would still be the shared fields button.

The reason for letting the cut-off point be administrable would be the amount of room a theme offers varies on the design of the site.

Problem 5 - What to do on initial translation creation

When creating a translation, having the values copied from the original language can be useful, but it would be nice if it was a selectable choice maybe? I.e. have two options to click when going to add a translation:

  • "add empty translation" -> leave all translatable fields empty
  • "add prefilled translation" -> fill all translatable fields with the values of the original language

-- Just my couple of cents :)

Thanks for sharing your ideas, it would be nice if @Bojhan, @Gabor and @webchick could tell us what they think about this.

I think this needs at least a visual of the current state of things before I could comment. I don't understand the problem yet so I don't know how to critique the answers discussed here. Something with a product content type that shares images and a product ID across translations for example. How is that translating such a node handled *now* (with screenshots! :-) and why is that not good/doesn't scale etc. That would help me grok the designs already posted here.

I understand that the biggest challenge is in how to handle the shared values. This is reminiscent of the Views UX challenge about 'overriding' or editing the base view for a given display. Not sure if it's really solved there but, interesting :)

StatusFileSize
new5.1 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch et_core_work-1282018-35.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

This is the updated core patch that matches the latest changes. We have now an almost full replication of the current functionality. UX issues still to be addressed. Get the updated snapshot and apply the attached patch to the latest core dev snapshot to test the ongoing work.

@yoroy:

Crossposted. I'll try to provide some screenshots tomorrow.

I am not sure if splitting the shared fields and translatable fields is such a good idea. The translator may miss relevant info.
How about using the/a formatter on the translation screen instead of the widget?

We have a client that will have 11 languages on their site and they are in the process of rolling this site out as we speak. The tabs above are going to look messy -- they will have to wrap into two lines. The current method of having a tab that contains a vertical list of languages where you can select one works much better for that many languages. Can I suggest that as we propose solutions we include that many language options to be sure there is a useful way of handling them?

One other concern. All this work is to get the node translation form working. What will happen with other entities? The current system of a separate form that just has the translatable fields results in a form that works with any entity. We will be using Organic Groups, taxonomy, etc on that 11 language site, and all those other entity fields will need translation too.

I'm just wondering if we're 'fixing' one problem by introducing a bunch of new ones.

We have a client that will have 11 languages on their site and they are in the process of rolling this site out as we speak. The tabs above are going to look messy -- they will have to wrap into two lines.

I think we can solve this issue with JS in many ways, which is the best I cannot tell atm. We could even drop the subtabs altogether, it would look to me overkill though, the key point is having and entity edit ML form.

The current method of having a tab that contains a vertical list of languages where you can select one works much better for that many languages.

The 'translate' tab is not going away, but obviously it won't solve the issue above. Language subtabs are meant to be just a "language switcher" act to convey the idea that under the edit tab you can deal with multiple languages.

One other concern. All this work is to get the node translation form working.

This is not true, one of my main goals has always been to deal with any entity type and all the code being written here deals with entities in general. Obviously I stared from nodes which are the most complex scenario feature wise.

Workflow description for the situation now

Sorry, no screenshots as I'm working on my tablet atm.
For clarification: the address/nodeID is the same for all language variants of the node, except for the URL/domain part as set in the Languages admin page.

Creating a node with translations

  1. Create a new node in default language (i.e. english in most cases)
  2. Fill in all the required fields and click Save
  3. Go to Translate tab of the node
  4. Click "add translation" for one of the other enabled languages of the site
  5. A screen comes up that only shows and allows editing of the translatable entities, the values of the default language are prefilled in the fields
  6. Fill in the fields of the translatable entities with the translations where required and click Save
  7. Repeat for other languages (optional)

Editing the node translations later on

  1. Go to the node in any language
    • To edit the shared fields
      1. Click Edit tab
      2. A screen comes up that allows editing of all fields and the values will be filled in the default language, no matter which language the user was viewing when clicking Edit. <-- This is the confusing part mostly.
      3. Change the values that needed change and click Save
    • To edit the translatable entities
      1. Click Translate tab
      2. Click "edit translation" for the desired language
      3. A screen comes up that only shows and allows editing of the translatable entities
      4. Change the values that needed change and click Save

Workflow that appears more preferable

Creating a node with translations

  1. Create a new node in default language (i.e. english in most cases)
  2. Fill in all the required fields and click Save
  3. Go to Translate tab of the node
  4. There are two choices
    1. Click "add prefilled translation" for one of the other enabled languages of the site
      • A screen comes up that only shows and allows editing of the translatable entities, the values of the default language are prefilled in the fields
    2. Click "add empty translation" for one of the other enabled languages of the site
      • A screen comes up that only shows and allows editing of the translatable entities, the values in the fields are all empty
  5. Fill in the fields of the translatable entities with the translations where required and click Save
  6. Repeat for other languages (optional)

Editing the node translations later on

  1. Go to the node in the language that requires editing
    • To edit the shared fields
      1. Click Shared Fields tab (or alternatively: click Edit tab and then click the Shared Fields "language selector" button)
      2. A screen comes up that allows editing of only the shared fields and the values will be filled in the language the user was coming from
      3. Change the values that needed change and click Save
    • To edit the translatable entities
      1. Click Edit tab
      2. A screen comes up that only shows and allows editing of the translatable entities, and the values will be filled in the language the user was coming from
        • The language switcher buttons indicate which translation is being edited, and allow the user to switch to another language to edit if they happen to be currently working in the wrong language
        • If there happen to be a lot of languages enabled the buttons could be rendered as a dropdown listbox with the current language as the current choice
      3. Change the values that needed change and click Save

On the issue of missing information for the translator

There is only so much you can display on a screen at once. If the values can't be changed I don't see a reason to have them on the screen while doing the translation as they clutter up the display and confuse the user. If they are required to be viewed by the translator, have them open up another tab/window in their browser where they can be viewed when necessary. Scrolling is just as bad (or even worse) as browser tab/window switching from an UX point of view. Besides, right now they are not visible either when editing a translation for a node with entity translation enabled so this would not really change.

Most (professional) translations of large amounts of text are done off-site, and copy-pasted into the site from what I've observed. Only small amounts of text will get translated directly on-site. The major work remaining then on-site is getting the text markup matching the original. The reasons for this mainly being that on-site work will be more easily lost when

  • browser/computer crashes occur, as there is no auto-save
  • the browser is accidentally closed, as there is no "Save before exit?" prompt
  • translating might take some time and saving work to handle a disruption is only a viable solution if "publish live" is turned off, this also brings the user to the View screen after a pause which disrupts the workflow (extra clicks required to get to the edit translation screen again)
  • accidentally hitting the backspace button with the mouse last clicked outside a text block, causing the browser to go back in history loading the previous page and discarding all the changes you made in the fields (<-- always a nice one to have a rage fit over)

I'm not sure this is relevant for this state, but it seems, that there is a problem with custom languages in the latest snapshot.

In my current project I have "english" and "english-us".
English US is a custom language and every time I try to translate this custom language, it changes the source language.
Also in the translation overview, the state of the (german) source and the custom language are similar.

In the normal english translation it works as expected. Maybe it's a settings problem, but I don't know where this problem could be...

@webcultist
I don't think this is relevant to ET multilingual form ...
please open up a new issue giving as much information as possible

Ok, sorry. I thought it's maybe related to the new interface or the core patch. In the normal, unpatched version it works correctly.

StatusFileSize
new198.63 KB
new200.39 KB
new98.08 KB
new88.64 KB
new54.28 KB
new38.18 KB
new91.41 KB
new88.83 KB

Here are some screenshots, updated the issue summary.

@webcultist:

It seems something broke during the last commits. I'll fix it soon.

Issue summary:View changes

Updated issue summary.

Thanks, that is so very, very helpful to understand the challenge. I'll have to respond more in-depth later, but yes, thank you :)

Thank you very much for the work you do! A clean, usable and understandable translation interface is so unbelievable important for a good cms.
It's one of the most important points for all bigger companies, when they choose a system here in Germany.

Thank you so much =)

@yoroy, @Bojhan:

FYI, this issue belongs to the D8 content language UI battleplan.

Updated the branch with some bug fixes.

StatusFileSize
new3.14 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch switchlinks-error-1282018-50.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

I just checked out the branch and tried it out. I got this fatal error:

Error message Recoverable fatal error: Argument 3 passed to l() must be an array, null given, called in \includes\menu.inc on line 1662 and defined in l() (line 2339 of \includes\common.inc).

This is caused in entity_translation_menu_local_tasks_alter(), when language switch links are not available, which can happen content language negotiation is setup to "fall back to interface language". In that case switch links also need to fall back to the interface type, see attached patch.

Committed, thanks!

I've been using entity_translation for several larger projects with multiple editor and translator roles for a while now, and can confirm that the present UX is indeed problematic. Also, I think that the solutions being proposed here are really going in the right direction. Thank you!

One thing that bothers me from a UX point of view though is the existence of both the 'Translate' tab and the new buttons below it indication the language that the user is working on. I think that is a duplication that will confuse users. Wouldn't it be possible to ditch the 'Translate' tab altogether? This could be achieved with enhancing the language buttons.

Let's say:
- language buttons are visible for all languages enabled on the site
- language buttons for languages that don't have a translation yet have an additional little plus sign in them
- language buttons for languages with existing translations have an additional little edit (pencil) sign in them
- the active language button also has the edit sign and is darker than the others

Visibility of the buttons could be determined on a permission basis, e.g. users with only the permission to translate into a specific language wouldn't see the buttons for other languages or have them greyed out.

The end result would be that there is no more 'Translate' tab but just an 'Edit' tab. Much simpler.

As I already said I'll leave comments about the UX side to the experts, however the translate tab also shows the update status of translations.

@reglogge - the problem with ditching the Translate tab altogether is that the core Content translation module and other configuration pieces (e.g. blocks, menus, etc.) use the Translate tab to do their work. And, like @plach said, it has the overview on it as to what is translated and what is not. IMHO, I think it should stay.

Personally, I'm not sure I like the extra language buttons/widgets on the proposed multilingual edit form. I would probably prefer:

1) switching using the regular language switcher (though it probably isn't always enabled for node edit pages)

2) if I'm in English UI and click "edit" on the entity-translated node, I am editing the English versions of the fields... the top of the form makes it obvious I'm editing for English

3) likewise, if I'm in German UI and click "edit" on the entity-translated node, I am editing the German versions of the fields... the top of the form makes it obvious I'm editing for German

4) common fields are marked as common fields somehow so it is obvious the change will be for all translations... e.g. "This field is shared across translations."

5) translated fields are also marked as such so it is obvious they are for that translation only... could have language listed as well so it is completely obvious... e.g. "This field is for German only."

But, I'm not a UX person ;)

Kristen

I absolutely agree that there is a strong need to fix this UI. It's OK for me to manage my own site this way - but I'm afraid it would be rather difficult to explain to content managers why editing entity-translated articles in default and non-default language(s) is so different, and why it's so much more complicated than managing "good old" node-translated sites where you just edit what you see by clicking "edit" and "save".

#54 sounds very reasonable to me. Kristen pretty much took the words right out of my mouth :).

P.S. Ability to switch from extrinsic to intrinsic translation of nodes is a long-awaited feature for me, so I'm really grateful to you Plach for what you are doing.

StatusFileSize
new2.11 KB

We are getting close, I just pushed a working taxonomy translation implementation :)

Here is the core patch needed to make things work.

Sorry, this is the right one.

The functional side is ready in the topic branch I tested it also with commerce (see #1495570: Update Entity translation integration). I just need to polish some comments and I'll post a patch here for review.

Here is the core issue with the patch needed for this to work: #1495648: Introduce entity language support.

StatusFileSize
new44 KB

Here's my conception of the new entity translation UI, based on ideas from the Entity Translation UI BoF at DrupalCon Denver.

It was suggested that for translatable fields, we should render the field in the source language above the field widget.

For untranslatable fields, we should change the label to make it clear that the field will apply to all languages.

There was also a suggestion that we could include a link to toggle between displaying all fields, and only widgets for the translations, which would simplify the interface.

Proposed Entity Translation UI

Feedback on #59 from @pixelite:

  1. I like the toggle at the top that lets you hide the non-translatable fields if desired.
  2. I like that you can see the original source data.
  3. For original source data that is long, the height will need to be limited by default so they don't see everything but can expand/toggle it to see all.
  4. Based on discussions with @Gábor Hojtsy, my understanding was that the language selection on the form would go away and, instead, be in a language switcher (in a block or ?) so it is a generic switcher rather than a per-page implementation.
  5. I like the language designator in the field label, but I don't know if that will go over with the UX people.

Overall, it feels like this is a good direction to go as it deals with:

  1. Showing the original field data compactly.
  2. Designates what is translatable compactly.
  3. Looks very similar to existing UI.
  4. Doesn't expand out the real estate by using 2 columns which might interfere with the new edit form redesign that is happening where the fieldsets are moving to the right of the page.

StatusFileSize
new40.5 KB

Here's an updated version of the mockup with a couple changes to better capture our discussion:

  • There's no translate tab, the edit tab is used to add all translations.
  • Editors can select a language using a selection widget rather than local tasks.

Proposed Entity Translation UI

I mentioned this earlier but want to bring it up again. All these mockups are assuming there are only a couple of languages available. I am working with several sites that have 10 or 11 languages. Tabs for all those languages are going to look pretty ugly -- they are going to wrap and make the form very messy looking. Please don't forget to allow for that many languages in the mockups and discussion. The current design works much better for so many languages (a single translate tab).

@KarenS: well, we basically discussed having a "language switcher" control that we'd use on both content and config and you'd be able to switch language to translate them. That sounds like a common pattern that we'd try to apply here. So think of that widget as a language switcher. It will most likely not be tabs, since we need to allow for tabs as well. @pixelite expressed that in her latest mockup.

I didn't realize the Translate tab would go away altogether. I suppose this makes sense because the language switcher will let them do the job.

I wonder if that will be as intuitive as the Translate tab. It does require one less step which is nice, but then there is no overview table. Would be good to get some translators to chime in.

Also, I'm assuming then that the Translate tab will go away *everywhere* and be replaced by the language switcher widget.

FYI, the top-issue description has new screendumps! Thanx Kristen! (I stumbled upon it, since normally I only check the latest replies...)
I like the way this is going, both the updated screendumps in the original issue description, and the #61 screen from pixelite, which responds well to the discussion about the 'showing the original value' in #19-#22.
However, the use case for 'Translate all languages at the same time by the same author/translator' (as expressed in #16) is not addressed yet. (My use case: entities with lots of untranslateble fields, and few -short- translatable ones. )
An extra option 'Select language = all languages' would be nice.

I can imagine you consider this an edge case, but to cater for the different constellations, is it possible to implement this issue as a plugin (a per-entity-type widget)?

Wondering about the Translate tab as well.

Translation Management Tools is currently hijacking that tab for both content and source translation, converts it to a tableselect and adds it's own stuff (mostly a button to request translations, and an additional column to show the state of eventually existing jobs).

Of course, if it *does* go away completely, we can simply add our own tab and make it look and feel like we want to and only have the things we need for ourself.

There is no plan to drop the Translate tab and actually I'm not totally sold on the screenshots above: in the Entity translation UI BoF we discussed some solutions but the implementation details were not addressed. I think @yoroy had a couple of mockups which were a bit different. I'd like to read his feedback on this issue.

However, we didn't discuss moving language subtabs to something else, and given the amount of time spent to make them work I don't think they'll be removed, at least for D7.

Also there is no plan to allow editing multiple languages on the same form, this would be pretty complex to implement and we really need to ship with something working now.

My short-term plans:

  1. post a working patch with the bare-minimum needed to handle shared fields, probably a permission to hide them and a minimal visual clue that they are shared (the label suffix sounds as a good candidate)
  2. roll an alpha-2
  3. commit the patch
  4. refine the UI here
  5. release a beta, which will be focused on bug fixes

Perhaps we should consider showing the non-translatable/shared fields in the edit form but not have them editable unless the current language is the original content. Does that make sense? Is this Possible? There could be some short help text denoting them as shared/non-translatable fields. I believe that this is the best way to avoid both of these (from the screenshot workflow in the issue description):

The Fr body is here but the image (a shared field) is not, why ET hates me? :(
F**k, I have to go back to the edit from...

Mmh, I didn't expect the image would change also in the En translation :(

As for the language sub-tabs, I like that idea a lot! Perhaps the language tabs could be shown as "[LangName] ([status])" to make things clear. [status] being "original content"/"published"/"not translated". If we added these as visual aids, we'd have no use for the translation overview table (the way I see it) apart from the source language column. This could perhaps be added to both the view and edit pages of the node ("Translated by [user_name] on [date] from [source language]").

I realize that my proposal doesn't take into account the case of websites with too many languages mentioned by Karen back in #62 and previously, but that's partially because I personally have not build any website that required more than 4 languages (typical use case is only 2) and partially because I doubt that there'll be a case where a single translator will be translating more than 2 or three languages - no need to even see the rest in edit view if the don't have permissions to translate them in the first place. Even if there is a use case where a single person has access to edit all 10 or 11 languages of a site, I still think that that'd be an edge case.

As for the language sub-tabs, and too many languages: how about an option to choose a 'language selector formatter' both use cases, e.g. :
- horizontal sub-tabs/list
- dropdown selectlist
- vertical list (eventually in exposed form, as in screendumps in issue summary)

Or use country flags instead of full text in such cases perhaps?

-1! Country flags don't represent languages.

But we do have language icons.
Sounds like there are enough ideas for a new 'Entity Translation Language Selector ' module :-)

I'm sorry, but those icons are still country flags. How many languages does India have, for instance?

As I said in #68 these must be edge cases:

...I doubt that there'll be a case where a single translator will be translating more than 2 or three languages - no need to even see the rest in edit view if they don't have permissions to translate them in the first place. Even if there is a use case where a single person has access to edit all 10 or 11 languages of a site, I still think that that'd be an edge case.

My suggestion in #70 was not intended as a solution to the problem of having too many languages. What I meant was more like:

I'm sure that admins of such sites with a long list of languages would already have to come up with solutions for similar problems in other parts of their sites. They'll figure it out for that problem too.

To that extend, a contrib "Entity Translation Language Selector" module does sound like an idea ;)

Please, don't derail the discussion to the language switcher. It is not the object of the debate. What is useful here is providing use cases in which the UI will be involved. The main issue to be solved remains the usability of the shared field widgets.

The main issue to be solved remains the usability of the shared field widgets.

What do you think about my proposal back in #68 to have these be shown in the edit form of all translations but not being editable unless one is switched to the original content language?

They can also have a help text to explain things when not editable. Something like:

Non-translatable field. This field cannot be changed unless you are editing the original content of this article.

- The link in the help text would be pointing to the edit form of that node's original content where that field can actually be edited (if the user has proper permissions).
- The help text there would change to something like:

Note: this is a non-translatable field that is shared among translations of this article. If you make any changes to it here, these changes will also be mirrored to the other translations.

- The "article" part of the help text should be dynamic and change to the content-type-name of that node.

This seems to be a move in the right direction. I am not a software developer, so I cannot and will not comment on code scalability and _software_ architecture, but for me this change is about the workflow and _information_ architecture. From that perspective, I would dream of going even further than this change. (Please tell me (and forgive me as a Drupal newbie) if this is not the right place for those considerations.) Here is how I see it.
AFAIU, up to now both entity translation (with Entity translation module) and node translation (with core Content translation module) have been based on the idea of having "the _original_ content". in "the _source_ language", and some _translations_, as _derivative_ from that original content.
Now, suppose I am making the "About me" page for my site. I plan to have it in, say, English and Ukrainian. I want visitors to be able to switch between those with a language selector. However, I work on each of those versions independently (well, relatively independently, and in any case copying the markup, but still). In the English version, I add some information relevant to English native speakers, which is not fully repeated in the Ukrainian version, and the latter is created in a similar way.
In this situation I would definitely prefer to have language-aware edit forms rather than translation forms, and sets of _different language versions_ of my content, rather than _translation sets_. Such sets would probably show me the "Last updated" date for each version instead of "This translation is outdated because the original version has changes".
That is what I would see as a truly multilingual CMS :).
Do all those things sound reasonable, or are they like some crazy newbie's idea? Or maybe that's another paradigm shift, to be implemented in Drupal 10 ;)?

StatusFileSize
new5.6 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch shared-fields-handling-1282018-78.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
new57.4 KB

klonos: What do you think about my proposal back in #68 to have these be shown in the edit form of all translations but not being editable unless one is switched to the original content language?

See plach's note on disabled widgets in #23 ("Disabled widgets are a pain").

plach: 1. post a working patch with the bare-minimum needed to handle shared fields, probably a permission to hide them and a minimal visual clue that they are shared (the label suffix sounds as a good candidate)

Attached patch adds the suggested visual clue (label suffix), css classes for custom styling, and a permission "Edit shared fields" for hiding shared fields from translations forms. Bare minimum :-)

Component:Code» Base system

Committed #78 with some small adjustment, mainly displaying the label only for shared fields and making it optional. I also added a permission to edit the original values. The two new permissions combined allow to replicate the experience of the old translation form. This should address Karen's concerns.

I have only fixing PHPdocs and some small code cleanup left on my todo list. A patch will follow soon :)

Thank you plach.
Is the new form going to be available for language-neutral nodes, too?
I think it's absolutely reasonable that language-neutral nodes cannot be node-translated, but why should the same be true for entity translation?
When content in two or more languages is to be stored in a single multilingual node, I think the whole notion of 'node language' does not make much sense anymore, and it would be quite logical for a node per se to be language-neutral. Why should it be necessary to ascribe a specific language to this node in order to enable translation of its fields?
(see #1458574: Enable translation button for language-neutral nodes?).

GN: the way we approach this, each version of the node has a language. There is no language neutral version of the node. What would the node title be for that for example? The "node language" is the original submission language of the node, which is pretty useful for workflow purposes to track. Then there can be any number of other language versions of the node. If a node does have a language neutral version, then in this setting it can only have that, because it is not meningful to translate a node from a language neztral state to a language. If all of its properties were neutral to language, it does not make sense to attempt to translate them.

@GN:

What Gabor said :)

Status:Active» Needs review
StatusFileSize
new115.79 KB
FAILED: [[SimpleTest]]: [MySQL] 55 pass(es), 6 fail(s), and 0 exception(s).
[ View ]

And finally here is the patch! I will commit it as soon as #1495648: Introduce entity language support gets in, unless serious issues arise meanwhile.

Ajax widgets might throw notices, it's a core bug, please review #1404480: Notice: Undefined index: in file_ajax_upload() (line 258 of modules/file/file.module). to fix it.

Have fun :)

Status:Needs review» Needs work

The last submitted patch, et-1282018-83.patch, failed testing.

Status:Needs work» Needs review
StatusFileSize
new117.31 KB
FAILED: [[SimpleTest]]: [MySQL] 61 pass(es), 1 fail(s), and 1 exception(s).
[ View ]

I forgot to fix tests. The attached patch is green locally but tests won't pass here until the core patch is committed.

Status:Needs review» Needs work

The last submitted patch, et-1282018-85.patch, failed testing.

Status:Needs work» Needs review

@todo:

+++ b/includes/translation.handler.taxonomy_term.inc
@@ -0,0 +1,30 @@
+    // displayed. ¶

Trailing whitespace.

Status:Needs review» Postponed
StatusFileSize
new118.91 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch et-1282018-88.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Fixed a couple of bugs introduced in the latest commits. Setting to postponed to avoid triggering the testbot. Testing/reviewing is welcome.

Gábor Hojtsy: Thank you for the explanation Gábor. The title is indeed unilingual, so it makes sense to ascribe its language to the entire node - but this is why we are discarding it in favor of a regular translatable field for ET.
I think that having to disable content filtering by language in order to display the French content of an "English" node on a French page looks like a dirtier hack to me than translating fields of a "language-neutral" multilingual node. I would say the "prohibition of neutrality" makes the whole entity translation thing look somewhat hacky. Should ET be an equal option for a multilingual site, or only a "poor relative" of the "normal way of translation"?

@GN: are you working with the assumption that all other properties of a node, such as its author or publication status are language independent? Eg. in all cases where Drupal entity translation would be used, people would want to have all translations published or unpublished at once?

@Gábor: Hmm, if I'm not mistaken, the problem with showing some translations and hiding the rest would exist in both cases: when a node is language-neutral, or when it is ascribed a specific language, but content filtering by language is disabled.
When I want author to be language-dependent, ET generally seems to be a bad choice, and I'll just use the old way of node translation instead. So, it would be good to have a possibility of combining ET and node translation within the same site - but it does not look possible with content filtering by language disabled.
Or am I missing something?

@GN: content filtering by language is just a workaround to make default core listings work with language; you can replace those listings with Views and build them in a way that works with your ET or core translation nodes. Just build your views for each with the respective filter for the translation methods you used.

StatusFileSize
new118.63 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch et_ui_tng-1282018-93.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Updated patch

Status:Postponed» Needs review

The core patch as landed, this is going to be committed soon!

Bot?

Status:Needs review» Needs work

The last submitted patch, et_ui_tng-1282018-93.patch, failed testing.

Status:Needs work» Needs review
StatusFileSize
new120.17 KB
PASSED: [[SimpleTest]]: [MySQL] 62 pass(es).
[ View ]

Rerolled

Status:Needs review» Reviewed & tested by the community

Green :)

This will be committed just after alpha-2 is released, see #1624830: [META] Roadmap for a stable release of Entity Translation for details.

Assigned:plach» Bojhan

Working on a UI

StatusFileSize
new83.29 KB

I wanted to share an initial design for this, there are two things I want to do;

1) Find a good spot for "switching" language, secondary navigation is super ugly at best. I imagine this can't actually be a dropdown because of accessibility, which might require either theming a button or something else.

2) Adding "Translated only for X language" and "Translated for all languages" to each field rather much. When I tried it out I quickly ran into way too much information and loads of clutter on the page. Which is when I started thinking about the 80% usecase (I know, this is not popular to do around i18n issues) but to me it seems its most likely there are only a few fields that are translated across all languages, and most are translated per language.

The solution in 2) could be optionally and we allow for people to toggle "This field is for German only." I don't really think its desirable, because it clutters the UI both on the content creation as on the site building part..

Assigned:Bojhan» Unassigned
Issue tags:-Needs usability review

In terms of review, I dont see any "latest" screenshot. If its secondary navigation I imagine its not very usable, because its not a very scalable pattern.

Bojhan, is the screenshot just a complete fresh mockup or do you use a special theme? It looks very nice. How did you get the Vertical tabs to the right?

@Bojhan:

The "latest" screenshots are the ones in the OP, with the exception of a "Shared field" text appended to the title of non translatable fields. I like the improvement proposed in #99.

Is the select widget in the top right of #99 a language switcher? If so I don't think this solution is in any way better than the language tabs: we would end up with two identical language selection widgets in the same page, one intended to switch the active form language and one intended to specify the language of the entity (or the translation).

However I will commit the RTBC patch to proceed with the other issues that are blocked by this one and then put the status back to active so we can refine the UI.

@plach Sure, commit! Could you perhaps ping me on IRC to provide more context to the "language switcher" supporting two different usecases?

StatusFileSize
new7.26 KB
new10.14 KB

@Bojhan:

This is what I was referring to in #103. I guess I'm not getting your point.

http://drupal.org/files/et-1282018-105-1.pnghttp://drupal.org/files/et-1282018-105-2.png

So I don't get why the second dropdown is so prominent, its the setting for the current language of what you are looking at right? Is that so common to change, that it needs to be on top? If not, can it just be in a vertical tab?

@Bojhan: it is not that prominent by default, but you can move it around in the field setup, so you can end up with this ugly setup (if you want to). I'm not sure we should be afraid that people could make illogical setups, if the default is logical, no? We cannot really prevent this.

Also, the difference between the tabs and the language switcher is that the tabs are in the menu and would only be possible to always display in 2nd level tabs, if you already have first level tabs. However, if you also have second level tabs, they would be impossible to show, no? So that is the thinking behind having a language switcher instead on top of content somehow for admin. If you want to translate to a wholly new language, should this dropdown include the languages, where translation does not exist and say "(create)" after their name or something?

Priority:Critical» Major
Status:Reviewed & tested by the community» Active

Merged the new UI into the new 7.x-1.x branch (whoo-hoo!), status back to active.

Component:Base system» User interface

Title:Drop the translation form in favor of a language-aware edit formImprove UX of language-aware entity forms

Retitling to avoid misunderstandings.

Did you merge it? Checked out 7.x-1.x branch but do not see those UX canges mention in #105.

No UX work has been committed, since we have no clear consensus on something actionable yet. The plumbing part has been merged one month ago.

I was surprised to see this missing as well. Understand falsely that the UI was merged was well. The proposal was a definite improvement.
Perhaps we should timebox the discussion and then merge the current work if nothing happens until a set date?

@bojanz:

Are you referring to the dropdown mentioned in #105? Because the screenshots in the OP have been merged.

My current focus now would be improving the ability to distinguish between shared and translatable fields. Bojhan was proposing also other improvements but we didn't reach consensus yet.

Ah, okay, I misunderstood thinking no Ui changes were merged.

Yes, they are, and if you could have a look to #1495570: Update Entity translation integration it would really be great ;)

Added to my todo list. We want to use entity translation in Kickstart v2 (or at least document & support it), so that issue is critical.

StatusFileSize
new136.22 KB

@plach, thanks for clarifying the status of this issue. Regarding the UX do I not have much useful input that is not already been sad. Those two language selectors are confusing and changing the selector to make it less visible do I not think is the solution.
entity_lang_ux-19

That one is the original entity language. I'm not sure whether it should stay or not. Initially my idea was to have a regular select allowing to change the translation language: say I chose to create a french translation but then erreously inserted german content. The selector would allow me to change the translation language, see this related issue #1701460: Make translation language changeable.

Maybe we should just rename "Language" to "Original language"? That way it shouldn't be confusing.

"Original language" sounds good to me... I don't think that is confusing, but agree that just "Language" by itself is.

"Original language" is good.

Maybe this is covered elsewhere, but what happens if someone changes it (the "Original language") on the English form? If someone is on the English form, and changes it from Norwegian to French, will the English form get saved properly with a new Norwegian translation and the entity language switching to French (with the French translation getting deleted)? It's not clear if English will get mixed in or not. To alleviate confusion, perhaps the entity/original language widget shouldn't appear on this form at all, or maybe it should only be on the Norwegian version.

What about "Source language"? I think "Original language" might be possible to confuse with the language the text was originally written in, which very well could be somewhere else than the site.

Is "Source language" something that translators and non-tech folks understand? As a programmer, it sounds fine, but not sure the general public would be okay with it.

Both Wikipedia and The free dictionary defines the use of "Source language" as just that.

Actually it wouldn't surprise me if "source code" actually stems from the use of "source" in for example articles to tell from where the information came from :)

"Open source" was a journalist thing, first, for instance.

We can have a different source language for each translation, there is also a language selector widget for that. The original language is the one the entity was "originally" created in. We have used this distinction consistently both in code and in the UI since the very beginning of the entity translation project.

Yeah, its not always so easy to know where terminology really stems from when you are so used to use them within your own role.

To clarify how I see the difference between "Original language" and "Source language":

Original text -> Translation 1 -> Translation 2

  • The Original text is the original language for both translation 1 and 2.
  • Translation 1 has the original text as source language
  • Translation 2 has translation 1 as source language
  • Neither translation 1 or 2 can never be the original language

Since we will be able to use any language version as the source to translate from, then source language and not original language should be used.

@tstevenson:

Since we will be able to use any language version as the source to translate from, then source language and not original language should be used.

Sorry, but I can't follow this argument: we already have a separate source language widget which is labelled as "Source language". The currently read-only widget is the original language as per your definition. As I was saying above it might make sense to turn it into a translation language widget, but if we keep it as it is now, it should definitely be labelled as "Original language".

@plach: Is it indicating the language that the translation was made from or always the original?

Using my example in #129 would it for Translation 2 show the language for Translation 1 (from which the translation was made from) or the original text?

Currently it shows the language of the original text.

Hm, I don't really see what purpose that has. Except when that text is also the one used as the translation source.

Also, having a ghosted drop down like this means that it's not clickable, plus that there is a clickable link at the top that seems to contain the same thing.

What about if at the top it would be something like this:

When source and original language is the same:

  • [current lang editing] [lang 1] [lang 2 (source)] [lang 3]

When source and original language is different:

  • [current lang editing] [lang 1] [lang 2 (origin)] [lang 3 (source)]

This way there will only be one place where the various languages a piece of content exists and it will be indicated directly from where the current text comes from. Everything nicely collected in one place.

Hm, I don't really see what purpose that has. Except when that text is also the one used as the translation source.

Thomas, you seem to try and cast a doubt on a sacred cow :). See Gabor's comment #81 above, as well as the related issue #1458574: Enable translation button for language-neutral nodes?.
Seriously though, I do see it useful if we were able to have truly multilingual workflows in Drupal, with not only the screen indication but also the very concept of the _original_ language of the entity dropped. However, based on some replies (particularly those by Gabor) I do not see any chances to get to that point any soon.

@Maksym Kozub: Sorry for causing troubles :)

I can understand yours, and others, points about this. The only thing I am interested in is to try and find the best ways of creating great UX for those that in the end will use this to work on content.

@tsvenson:
You have not caused any troubles at all, I was just joking (maybe it was not a good joke...). Actually, I do support your point about no purpose in having that "original language" there. I am just going a bit further than you do, and I am saying that not only the indication but the very concept of one "original language" is irrelevant in a multilingual workflows :). It is just a pity for me to see that while on the UX side language-related things are becoming more and more "symmetrical" (language-aware Edit instead of Translate being the key example), and generally better every day, on the conceptual side I cannot persuade esteemed developers that it would be better if Drupal would support workflows based on that "true multi-directional multilingualism" (my term :)), not only on the "Original+translation(s)" approach.

@Maksym Kozub:

Well, I do believe that knowing that the source language used for a translation isn't the original is important. After all, a translation is an interpretation by the translator of the source text. Thus, the more translations there are between a text and its origin, the more likely it is that the meaning of it changes to some extent.

So, if you then easily can spot that you are not translating from the origin you can quickly switch to it instead. That is, if you also understand the language it was originally written in.

Going a bit off-topic here maybe, there should actually be a setting for only making translations possible from the original text or allow from any derivative of it as well.

@tsvenson:

Well, I do believe that knowing that the source language used for a translation isn't the original is important.

Of course it is. What I meant was mostly about the existence of situations where the very concept of "the original language" does not actually seem relevant. See e.g. http://drupal.org/node/1458574#comment-6230424 (and the whole discussion there).

Note: I added a patch to #1701460-8: Make translation language changeable, which hides the "original language" widget and adds a new dropdown for the "translation language" (as per plach's suggestion above).

There is an amazingly similar proposal for the theming of the language switcher block to look like Bojhan's designs from #99 at #1498880: Theme language switcher for seven theme (for Drupal 8 core).

StatusFileSize
new12.42 KB

The content on our multilingual site is created entirely by the end-users (who are not Drupal experts). Therefore, we spend a lot of time thinking about user-friendliness and intuitive design. The main content consists of 17 fields that end-users need to fill, and only one of those fields is translatable: the Body/Description field (everything else is just numbers and taxonomies, which are automatically translated as part of the interface).

So, having a language-chooser on the node creation form on a content where only 1 field may be multilingual, is really confusing! What further adds to the confusion is the " (all languages) " appended to all other field titles -- that really needs to go.

The best IMHO example of how intuitive and VERY user-friendly design for a multilingual field can be, is to be found in the Wordpress's leading internationalization plugin called "qTranslate". What is does is create an AJAX or Javascript tab for each language just above the given field. See example below. In my opinion this would be the best solution to be implemented for Entity Translation even in 7x.

qTranslate

@drupalina's Yes i used that module in wordpress , very useful and easy to use

I'm not advocating for any solution but if you talk about:

So, having a language-chooser on the node creation form on a content where only 1 field may be multilingual, is really confusing

You've to think at the opposite case too. What is if just a single field isn't translatable? Isn't it annoying to click on each field to translate, maybe you forget to switch the language of the fields and you end up inserting content in the wrong language.
I think such opposing scenarios demand a configurable solution. But I guess that needs quite some effort.

@sinasalek thanks for supporting my idea. I really think this would be the best solution for ET,especially given that it is based on tried and tested plugin from Wordpress.

@das-peter I totally agree, and therefore I propose that we (the admins) should have the best of the two worlds. If there was an ET setting that would allow the admins to choose between the current solution and the one that I have proposed: "Combine the translatable fields under language tabs".

Frankly, I had high hopes for ET, because over the last 7 years with Drupal I have built many multilingual sites and in each case internationalization has been a can of worms. But now that I have installed the ET and had a chance to properly use it, I should say that I'm quite disappointed, because as it is right now, it does not provide the user-friendly and intuitive interface for the end-user.

@drupalina:

What further adds to the confusion is the " (all languages) " appended to all other field titles -- that really needs to go.

There's a setting to hide those.

Therefore I propose that we (the admins) should have the best of the two worlds.

Unfortunately the approach you are proposing conflicts with the underlying architecture, we already evaluated and rejected it almost two years ago. I am not saying it wouldn't make sense in certain contexts, but it would involve a fair amount of work to get it done properly.

I should say that I'm quite disappointed, because as it is right now, it does not provide the user-friendly and intuitive interface for the end-user.

The main problem with multilingual is that it's a hard topic with very few people working on it, at least in D7. We are already having a hard time making it working properly at functional level, unfortunately UX will have to wait we are done with that. Anyway, this issue is listed in #1624830: [META] Roadmap for a stable release of Entity Translation, hence if any viable improvement is proposed here, it will certainly be done before the first stable release.

Issue summary:View changes

Added screenshots

@drupalina

Please check my sandbox project: https://drupal.org/sandbox/taran2l/2162979