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
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.
Comment | File | Size | Author |
---|---|---|---|
#141 | qtranslate2.png | 12.42 KB | drupalina |
#119 | entity_lang_ux-19.png | 136.22 KB | steinmb |
#105 | et-1282018-105-1.png | 10.14 KB | plach |
#105 | et-1282018-105-2.png | 7.26 KB | plach |
#99 | initialdesign.jpg | 83.29 KB | Bojhan |
Comments
Comment #1
jherencia CreditAttribution: jherencia commentedSubscribing...
Comment #2
renat CreditAttribution: renat commentedAnd 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.
Comment #3
das-peter CreditAttribution: das-peter commentedSubscribing
Comment #4
Gábor HojtsyTagging. Where can people find this code?
Comment #5
plachHere 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.
Comment #6
plachThis 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.
Comment #7
plachComment #8
plachusing tag instead of component
Comment #9
Lars Toomre CreditAttribution: Lars Toomre commentedThe @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:
and this will be compatible across major versions. Alternatively, one could check DRUPAL_CORE_COMPATIBILITY constant.
Comment #10
plachNo, 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.
Comment #11
plachLet's summon the UX folks.
Comment #12
GiorgosKHow 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)
Comment #13
plachIf 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.
Hopefully yes, since the pathauto and menu widgets would be in place even for translations.
Comment #14
GiorgosKis 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 ?
Comment #15
plachThis 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.
Comment #16
johnvCan 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.
Comment #17
dboulet CreditAttribution: dboulet commentedThat would work well for a bilingual site, but not for a site with a large number of languages.
Comment #18
plachThis is how the UI will look like:
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.
Comment #19
johnvThe 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)
Comment #20
KarenS CreditAttribution: KarenS commentedI 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?
Comment #21
KarenS CreditAttribution: KarenS commentedAnd 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.
Comment #22
KarenS CreditAttribution: KarenS commentedAnother 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.
Comment #23
plachWe 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.
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).
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.
This is more or less the current behavior, it's just not been implemented yet in the new UI.
Comment #24
plachOr 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.
Comment #25
KarenS CreditAttribution: KarenS commentedI 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.
Comment #26
KarenS CreditAttribution: KarenS commentedAnd 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.
Comment #27
plachI 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 :)
Comment #28
plachComment #29
KarenS CreditAttribution: KarenS commentedBut 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.
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.
Comment #30
Bojhan CreditAttribution: Bojhan commentedCan 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?
Comment #31
webchickAgree 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. :)
Comment #32
plachI updated the issue summary with some background and use cases.
@Bojhan:
I ain't sure I understand what you mean here: could you expand on this?
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.
Comment #32.0
plachIssue summary
Comment #32.1
plachminor cleanup
Comment #33
cosmosian CreditAttribution: cosmosian commentedI 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.
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:
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:
-- Just my couple of cents :)
Comment #34
plachThanks for sharing your ideas, it would be nice if @Bojhan, @Gabor and @webchick could tell us what they think about this.
Comment #35
yoroy CreditAttribution: yoroy commentedI 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 :)
Comment #36
plachThis 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.
Comment #37
plach@yoroy:
Crossposted. I'll try to provide some screenshots tomorrow.
Comment #38
johnvI 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?
Comment #39
KarenS CreditAttribution: KarenS commentedWe 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.
Comment #40
plachI 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 '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.
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.
Comment #41
cosmosian CreditAttribution: cosmosian commentedWorkflow 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
Editing the node translations later on
Workflow that appears more preferable
Creating a node with translations
Editing the node translations later on
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
Comment #42
webcultist CreditAttribution: webcultist commentedI'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...
Comment #43
GiorgosK@webcultist
I don't think this is relevant to ET multilingual form ...
please open up a new issue giving as much information as possible
Comment #44
webcultist CreditAttribution: webcultist commentedOk, sorry. I thought it's maybe related to the new interface or the core patch. In the normal, unpatched version it works correctly.
Comment #45
plachHere are some screenshots, updated the issue summary.
@webcultist:
It seems something broke during the last commits. I'll fix it soon.
Comment #45.0
plachUpdated issue summary.
Comment #46
yoroy CreditAttribution: yoroy commentedThanks, that is so very, very helpful to understand the challenge. I'll have to respond more in-depth later, but yes, thank you :)
Comment #47
webcultist CreditAttribution: webcultist commentedThank 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 =)
Comment #48
plach@yoroy, @Bojhan:
FYI, this issue belongs to the D8 content language UI battleplan.
Comment #49
plachUpdated the branch with some bug fixes.
Comment #50
bforchhammer CreditAttribution: bforchhammer commentedI 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.Comment #51
plachCommitted, thanks!
Comment #52
reglogge CreditAttribution: reglogge commentedI'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.
Comment #53
plachAs 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.
Comment #54
Kristen Pol@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
Comment #55
GN CreditAttribution: GN commentedI 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.
Comment #56
plachWe are getting close, I just pushed a working taxonomy translation implementation :)
Here is the core patch needed to make things work.
Comment #57
plachSorry, this is the right one.
Comment #58
plachThe 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.
Comment #59
pixeliteHere'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.
Comment #60
Kristen PolFeedback on #59 from @pixelite:
Overall, it feels like this is a good direction to go as it deals with:
Comment #61
pixeliteHere's an updated version of the mockup with a couple changes to better capture our discussion:
Comment #62
KarenS CreditAttribution: KarenS commentedI 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).
Comment #63
Gábor Hojtsy@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.
Comment #64
Kristen PolI 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.
Comment #65
johnvFYI, 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)?
Comment #66
BerdirWondering 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.
Comment #67
plachThere 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:
Comment #68
klonosPerhaps 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):
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.
Comment #69
johnvAs 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)
Comment #70
klonosOr use country flags instead of full text in such cases perhaps?
Comment #71
Robin Millette CreditAttribution: Robin Millette commented-1! Country flags don't represent languages.
Comment #72
johnvBut we do have language icons.
Sounds like there are enough ideas for a new 'Entity Translation Language Selector ' module :-)
Comment #73
Robin Millette CreditAttribution: Robin Millette commentedI'm sorry, but those icons are still country flags. How many languages does India have, for instance?
Comment #74
klonosAs I said in #68 these must be edge cases:
My suggestion in #70 was not intended as a solution to the problem of having too many languages. What I meant was more like:
To that extend, a contrib "Entity Translation Language Selector" module does sound like an idea ;)
Comment #75
plachPlease, 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.
Comment #76
klonosWhat 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:
- 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:
- The "article" part of the help text should be dynamic and change to the content-type-name of that node.
Comment #77
Maksym Kozub CreditAttribution: Maksym Kozub commentedThis 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 ;)?
Comment #78
bforchhammer CreditAttribution: bforchhammer commentedSee plach's note on disabled widgets in #23 ("Disabled widgets are a pain").
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 :-)
Comment #79
plachCommitted #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 :)
Comment #80
GN CreditAttribution: GN commentedThank 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?).
Comment #81
Gábor HojtsyGN: 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.
Comment #82
plach@GN:
What Gabor said :)
Comment #83
plachAnd 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 :)
Comment #85
plachI forgot to fix tests. The attached patch is green locally but tests won't pass here until the core patch is committed.
Comment #87
plach@todo:
Trailing whitespace.
Comment #88
plachFixed a couple of bugs introduced in the latest commits. Setting to postponed to avoid triggering the testbot. Testing/reviewing is welcome.
Comment #89
GN CreditAttribution: GN commentedGá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"?
Comment #90
Gábor Hojtsy@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?
Comment #91
GN CreditAttribution: GN commented@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?
Comment #92
Gábor Hojtsy@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.
Comment #93
plachUpdated patch
Comment #94
plachThe core patch as landed, this is going to be committed soon!
Bot?
Comment #96
plachRerolled
Comment #97
plachGreen :)
This will be committed just after alpha-2 is released, see #1624830: Plan for Entity Translation 7.x-1.0 release for details.
Comment #98
Bojhan CreditAttribution: Bojhan commentedWorking on a UI
Comment #99
Bojhan CreditAttribution: Bojhan commentedI 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..
Comment #100
Bojhan CreditAttribution: Bojhan commentedIn 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.
Comment #101
Wolfgang Reszel CreditAttribution: Wolfgang Reszel commentedBojhan, 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?
Comment #102
Bojhan CreditAttribution: Bojhan commentedThat new design is part of #1510532: [META] Implement the new create content page design
Comment #103
plach@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.
Comment #104
Bojhan CreditAttribution: Bojhan commented@plach Sure, commit! Could you perhaps ping me on IRC to provide more context to the "language switcher" supporting two different usecases?
Comment #105
plach@Bojhan:
This is what I was referring to in #103. I guess I'm not getting your point.
Comment #106
Bojhan CreditAttribution: Bojhan commentedSo 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?
Comment #107
Gábor Hojtsy@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.
Comment #108
Gábor HojtsyAlso, 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?
Comment #109
plachMerged the new UI into the new 7.x-1.x branch (whoo-hoo!), status back to active.
Comment #110
plachComment #111
plachRetitling to avoid misunderstandings.
Comment #112
steinmb CreditAttribution: steinmb commentedDid you merge it? Checked out 7.x-1.x branch but do not see those UX canges mention in #105.
Comment #113
plachNo UX work has been committed, since we have no clear consensus on something actionable yet. The plumbing part has been merged one month ago.
Comment #114
bojanz CreditAttribution: bojanz commentedI 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?
Comment #115
plach@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.
Comment #116
bojanz CreditAttribution: bojanz commentedAh, okay, I misunderstood thinking no Ui changes were merged.
Comment #117
plachYes, they are, and if you could have a look to #1495570: Update Entity translation integration it would really be great ;)
Comment #118
bojanz CreditAttribution: bojanz commentedAdded to my todo list. We want to use entity translation in Kickstart v2 (or at least document & support it), so that issue is critical.
Comment #119
steinmb CreditAttribution: steinmb commented@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.
Comment #120
plachThat 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.
Comment #121
renat CreditAttribution: renat commentedMaybe we should just rename "Language" to "Original language"? That way it shouldn't be confusing.
Comment #122
Kristen Pol"Original language" sounds good to me... I don't think that is confusing, but agree that just "Language" by itself is.
Comment #123
colan"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.
Comment #124
tsvenson CreditAttribution: tsvenson commentedWhat 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.
Comment #125
Kristen PolIs "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.
Comment #126
tsvenson CreditAttribution: tsvenson commentedBoth 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 :)
Comment #127
Robin Millette CreditAttribution: Robin Millette commented"Open source" was a journalist thing, first, for instance.
Comment #128
plachWe 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.
Comment #129
tsvenson CreditAttribution: tsvenson commentedYeah, 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
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.
Comment #130
plach@tstevenson:
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".
Comment #131
tsvenson CreditAttribution: tsvenson commented@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?
Comment #132
plachCurrently it shows the language of the original text.
Comment #133
tsvenson CreditAttribution: tsvenson commentedHm, 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:
When source and original language is different:
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.
Comment #134
Maksym Kozub CreditAttribution: Maksym Kozub commentedThomas, 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.
Comment #135
tsvenson CreditAttribution: tsvenson commented@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.
Comment #136
Maksym Kozub CreditAttribution: Maksym Kozub commented@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.
Comment #137
tsvenson CreditAttribution: tsvenson commented@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.
Comment #138
Maksym Kozub CreditAttribution: Maksym Kozub commented@tsvenson:
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).
Comment #139
bforchhammer CreditAttribution: bforchhammer commentedNote: 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).
Comment #140
Gábor HojtsyThere 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).
Comment #141
drupalina CreditAttribution: drupalina commentedThe 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.
Comment #142
sinasalek CreditAttribution: sinasalek commented@drupalina's Yes i used that module in wordpress , very useful and easy to use
Comment #143
das-peter CreditAttribution: das-peter commentedI'm not advocating for any solution but if you talk about:
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.
Comment #144
drupalina CreditAttribution: drupalina commented@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.
Comment #145
plach@drupalina:
There's a setting to hide those.
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.
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: Plan for Entity Translation 7.x-1.0 release, hence if any viable improvement is proposed here, it will certainly be done before the first stable release.
Comment #145.0
plachAdded screenshots
Comment #146
Taran2L@drupalina
Please check my sandbox project: https://drupal.org/sandbox/taran2l/2162979
Comment #149
steinmb CreditAttribution: steinmb commentedFirst of all, a big thanx to @plach for a ton of commits! :)
Looking at the commits and the branches they where commited/merged to. These are not changes that goes to the one making out the latest dev. What is the reason and thinking behind that?
remotes/origin/HEAD -> origin/7.x-1.x
And are you asking for any feedback in these commit in this issue? Looked at #1624830: Plan for Entity Translation 7.x-1.0 release though that did not make me any smarter. This issue is getting big and long and harder and harder to track/test/help.
Comment #150
plachI have no idea why #147 and #148 were posted. Actually those commits were already merged in the 7.x-1.x branch long time ago. This is still open as we might want to improve the UX after that merge, but at this point I am not very confident we will make any progress on that side. At least here.
Comment #151
drewmacphee CreditAttribution: drewmacphee commentedAs an outside observer on this issue, Drupalina's per field switching is a lot more intuitive.
There's no doubt which language you are editing.
What I suggest is that the per node language buttons that already exist, switch each field's tab to that language, unless there isn't yet a translation setup for that field. (then it would highlight the "add language" button for that field)
Also some kind of highlighting on any "All Language" fields or even "No Language" fields, depending on if there is a default language or not. That way you know where they apply across the board or where they are missing, and that you need to "add" a language to a field.
You'd still have the option of switching each fields language. Perhaps if you're in a mixed language setup those top per node language buttons all are not active, so it doesn't "look" like you are on a specific language page. They would only be active if you are seeing a full page of field in that language, or "all language" or "no language"
Comment #152
joseph.olstadWe just completed an evaluation of the contrib module 'Create and Translate' it provides a save and translate button which is saving clicks (what we want) but it only works with content translation, we would like to bring this workflow improvement to entity_translation.
If time permits we will either make a patch for the 'Create and Translate' module OR make a patch to entity_translation that provides this functionality in a way compatible with entity_translation.
Comment #153
joseph.olstadFollowup on comment #152.
I've created a patch that adds entity_translation support to the 'create_and_translate' module.
A patched/modified version of this create_and_translate module could be added to entity_translation as a sub-module to entity_translation, OR, a patch based on this could be created for entity_translation to do the same thing.
Basically this module adds a 'create and translate' button to the add node form, clicking this instead of 'save' improves the UX by saving a mouse-click taking the user directly to the translation page. This might seem like a small improvement however when copious amounts of content are being created this does significantly improve the workflow.
Here's the aforementioned patch:
#2918170-2: add create_and_translate support for entity_translation
patch is for create_and_translate
Comment #154
joseph.olstadsee related issues:
#2918196: UX improvement, create_and_translate button that improves translation workflow
and
#2918170: add create_and_translate support for entity_translation
Comment #155
joseph.olstadbzaher came up with an even better solution. There is a sandbox module available to radically improve the UX for entity_translation and radically improve the translation workflow.
We should consider making this new module a sub-module of the entity_translation module.
See screenshot:
The module code will be added soon.
Comment #156
sinasalek CreditAttribution: sinasalek at Practicalidea commentedThat's a great idea, this way it becomes possible to separate different language fields into dynamic tabs, or all fields for each language into a separate dynamic tab, and even separate non translatable fields from translatable ones in UI
Comment #157
joseph.olstadmodule is ready for review.
https://www.drupal.org/project/entity_translation_unified_form
For now use git clone to get the code
I will also tag a release of it
Comment #158
mohaly CreditAttribution: mohaly commentedIts a good solution joseph.olstad, we wish you work in Drupal 8 release soon.
Comment #159
joseph.olstadhow about a 2.0 release of entity_translation that adds a submodule called entity_translation_unified_form https://www.drupal.org/project/entity_translation_unified_form enabled by default in 2.0
now that 1.0-rc1 has released, could start work on a 2.x branch
Comment #160
james.williams CreditAttribution: james.williams at ComputerMinds commentedSo many years ago now, but back in comments 33 & 41, cosmosian suggested what I guess is the opposite of what that entity_translation_unified_form module does. Instead of putting all the widgets from all translations into a single form, the idea was to separate the shared fields into their own form (as well as each translation being in its own form).
I'm very glad this issue didn't get too hung up on being too ambitious too early, as the '(all languages)' hint that got added, and the setting for hiding shared elements on the translation forms, is fine for the majority of use cases. But just as there are cases where it makes sense to put all the translations into a single form, there are cases (like cosmosian's, and now mine) where it makes sense to split the shared fields out into their own form. On my site, we have a 'product' node type, with hundreds of fields. Anything that can be done to make the form smaller is worthwhile - but also there is no real advantage to the original translation of a node being the one that gets to 'own' the shared fields. Editors would like to be able to edit the untranslatable fields on the product without interfering with the original translation.
Unless anyone's already aware of ways this can be achieved already (I couldn't find any modules that have been created to do it, even though it's been 8 years since cosmosian's suggestion!), I might get building a new contrib project to do this, more or less along the lines of cosmosian's suggested UX of a 'Shared fields' secondary tab.
Comment #161
joseph.olstadentity_translation_unified_form for D7 has a tabbed view option
I've also created a patch for the D8 version which does side-by-side view of two languages on one form
The Drupal 7 version of this module is mostly bulletproof from what I have seen it is very good.
In D8, I have it running for a couple of my clients, I'm not fully satisfied with it yet but it's slowly improving.
Some mysteries into D8 core that were not a problem using contrib modules like file_entity in D7. However the media entity was introduced in D8, references to these in two languages on one form do not behave in a way that is very friendly to this type of a use case.
I've been having to run core patches in D8 for a lot of things, there's a few mysteries in D8 core that I haven't resolved but overall with patches there's some highly functional capabilities. D7 is really tough to beat though for multilingual use cases of all kinds.
Comment #162
joseph.olstadforget what I said earlier about a submodule of entity_translation, this module is doing very well in contrib.
from just 2 installs on November 18, 2017
to over 100 installations in may 2020.
Comment #163
james.williams CreditAttribution: james.williams at ComputerMinds commentedThanks for the info joseph.olstad. What I'm looking for though, is an interface that allows editing the untranslatable/shared fields on their own separate form page. Something like cosmosian's screenshot in comment 33 suggests:
I don't see any way that entity_translation_unified_form provides that? I'm also only interested to use this in conjunction with entity_translation in D7, for now.
Comment #164
joseph.olstad@james.williams, interesting concept and I am not against this however I would suggest that entity_translation_unified_form provides gracefully provides a very smart way to deal with this because the non-translateable fields show up only once for all languages on the form for the source language of the entity, all other fields show up in all the available languages.
there is a helpful status message when using other interface languages other than the source language mentionning this.
Comment #165
james.williams CreditAttribution: james.williams at ComputerMinds commentedI have no doubt ETUF is super handy for many sites / use cases, sure :-) I found the patch that adds the tabs to the interface, as you’ll have noticed by my re-roll.
My use case needs something quite different though. I have one node type with well over 100 fields, and several languages. So making a single edit form even bigger is definitely not an option. Our editors want to avoid running into conflicts, as they already run into them because it’s too easy for one editor to spend so long on one translation before saving, whilst another makes changes in another language.
So splitting the node form into smaller pieces would be ideal for me. As it happens, one of our editors suggested an idea almost identical to that one from cosmosian, so I’m keen to pursue it. Thanks for helping me understand what is currently possible. ETUF is another good tool to have in the arsenal for future.
Hopefully our client can help sponsor the work for us to implement cosmosian’s approach. I’ll post it here if it happens!
Comment #166
james.williams CreditAttribution: james.williams at ComputerMinds commentedFor anyone else (especially cosmosian & joseph.olstad) following the recent posts - I got around to producing a (D7) module for splitting the untranslatable fields / shared elements of translation forms into their own page: Entity Translation: Separated shared elements form (ETSSEF)
Naming is hard ;-)
For sites that have a lot of fields, this is especially useful as this allows splitting forms down to each be smaller, taking the opposite approach of entity_translation_unified_form. Some sites will suit one or the other of these approaches, as each has their own advantages & disadvantages, which I've tried to summarise on the project page for ETSSEF.
@joseph.olstad - you might want to link to ETSSEF in the 'Similar modules' on your entity_translation_unified_form project page?
---
To get this issue back on track, I'm tempted to think that the remaining tasks (at least according to the issue summary) around shared widgets & original values might now have been resolved (for those that care enough) via these contrib options? I suspect the shared_fields_original_only setting itself in ET might be enough for the majority of cases, so it might be fair to leave the larger solution to either of these additional modules rather than try & merge their work into ET itself.
There's a lot of in this ticket though, I think there may have been other remaining tasks? e.g. changing the secondary tabs to work better when there are too many languages to display nicely as tabs. So I'm adding the 'Needs issue summary update' tag.
To be honest, it may just be worth picking out anything that could be valuable to raise for D9 core, and then consigning this ticket to history?
Comment #167
joseph.olstadHi james.williams, if you eventually end up doing this in D8, please consider making it a patch for the D8 version of entity_translation_unified_form , a sort of optional mode would be great.
I've been doing a lot of work on the D8 version of etuf (entity_translation_unified_form) , the D7 version however is very mature, too bad you didn't decide to patch that one too.
maybe at some point we could combine the two projects, make this an optional mode.
Comment #168
james.williams CreditAttribution: james.williams at ComputerMinds commentedOh sure, sorry! I guess what I have done is pretty much the opposite of your module's name, 'unified form', though so I hadn't really even considered that. It's a good suggestion in theory though, as yes, our module's functionality would be mutually exclusive, and probably configured to be used in the same place.
I certainly don't mean to avoid working together - very happy to do that where it makes sense so thanks for the encouragement/invitation!