Postponed on #867830: "unpublished" status of rendered entities is not accessible (and looks bad).

Problem/Motivation

When setting up an entity bundle to be translatable, people have a choice of making each field translatable or not. The user interface signals untranslatable fields with (all languages) on the UI but that is way too subtle.

Proposed resolution

Make the marker more recognizable.

Remaining tasks

1. Add a tooltip.
2. Decide on text of marker.
2. Get #867830: "unpublished" status of rendered entities is not accessible (and looks bad) in first.
3. Get this in.

User interface changes

A better marker for fields shared among all languages.

API changes

None.

Data model changes

None.

Files: 
CommentFileSizeAuthor
#87 ui_telling_you_a_field-2290101-87.patch2.06 KBMaouna
FAILED: [[SimpleTest]]: [PHP 5.5 MySQL] 113,248 pass(es), 2 fail(s), and 0 exception(s). View
#87 83-87-interdiff.txt1.15 KBMaouna
#83 ui_telling_you_a_field-2290101-83.patch2.04 KBMaouna
FAILED: [[SimpleTest]]: [PHP 5.5 MySQL] 113,219 pass(es), 2 fail(s), and 0 exception(s). View
#83 82-83-interdiff.txt799 bytesMaouna
#82 ui_telling_you_a_field-2290101-82.patch2.04 KBMaouna
FAILED: [[SimpleTest]]: [PHP 5.5 MySQL] 113,232 pass(es), 1 fail(s), and 0 exception(s). View
#82 64-82-interdiff.txt778 bytesMaouna
#77 Create English translation of Sample article | drupal 8.0.0-beta15 2015-09-26 12-50-53.png244.75 KBGábor Hojtsy
#76 screenshot_new_mark_shared.png92.43 KBMaouna
#76 screenshot_new_mark_all_languages.png94.14 KBMaouna
#76 screenshot_current.png93.1 KBMaouna
#64 ui_telling_you_a_field-2290101-64.patch2.03 KBStryKaizer
FAILED: [[SimpleTest]]: [PHP 5.5 MySQL] 113,743 pass(es), 1 fail(s), and 0 exception(s). View
#64 TEST-ONLY-SHOULD-FAIL_ui_telling_you_a_field-2290101-64.patch1.04 KBStryKaizer
FAILED: [[SimpleTest]]: [PHP 5.5 MySQL] 113,745 pass(es), 1 fail(s), and 0 exception(s). View
#56 2290101-shared-mark-56.patch1022 bytesMaouna
FAILED: [[SimpleTest]]: [PHP 5.5 MySQL] 113,575 pass(es), 1 fail(s), and 0 exception(s). View
#46 shared field marked 2.png49.05 KByoroy
#40 shared field marked.png44.68 KByoroy
#39 shared field.png41.86 KByoroy
#34 2290101 shared multilingual fields.png18.05 KByoroy
#32 Create Article | sf27e3f41d30f2e9.s3.simplytest.me 2014-10-14 16-01-54.png256.97 KBGábor Hojtsy
#30 2290101-shared-fields-icons.png110.76 KByoroy
#29 Globe-icon.svg_.zip2 KBmemoo
#24 Globe-icon.png453 bytesmemoo
#20 2290101_20.patch3.31 KBcsakiistvan
FAILED: [[SimpleTest]]: [PHP 5.5 MySQL] Unable to apply patch 2290101_20.patch. Unable to apply patch. See the log in the details link for more information. View
#20 drupal8-node-edit.png18.43 KBcsakiistvan
#20 drupal8-admin-structure-menu-item-1-edit-translations-add-en-hu.png132.25 KBcsakiistvan

Comments

webchick’s picture

Issue tags: +D8MI, +Usability

Tagging for the multilingual and UX folks. I remember being concerned about this back when it went in but this was the best idea we could think of at the time. Couldn't really comment on the feasibility/usability of the "lock" option but that definitely feels the most explicit in terms of explaining what's happening. Colours are sub-optimal because not everyone can see colors (so we'd need other visual styling that might also not get the point across), and confirm boxes are irritating noise that most people skip through without reading anyway. We should definitely brainstorm though because I can completely see this being a terribly easy mistake to make.

plach’s picture

I spent quite some time experimenting with this stuff in contrib and thinking about alternative solutions for core. Actually I think there are entity types where contextual editing is less important and most of the times the desired behavior is simply seeing just translatable fields. An example would be for instance menu links, as implemented in #2256521: [META] New plan, Phase 2: Implement menu links as plugins, including static admin links and views, and custom links with menu_link_content entity, all managed via menu_ui module: most of the entity form is composed of untranslatable fields so having to find the translatable bits is quite awkward. On the other hand nodes may have many translatable fields (or most, or even all), so in that case contextual editing and the ability to edit also untranslatable fields makes sense.

I think a possible approach to reconcile these two scenarios would be to make untranslatable fields hidden by default, when the entity form is not in the entity default language, they could be turned on/off through a simple JS toggle.

Also I think we should improve the styling of untranslatable fields, @Bojhan posted a proposal way prettier than what we have now in #1282018-99: Improve UX of language-aware entity forms:
untranslatable field widget

plach’s picture

plach’s picture

Issue tags: +language-content
plach’s picture

Bojhan’s picture

Yhea, unless we are looking into grouping or visually screaming the best alternative would be for a switch.

plach’s picture

@Bojhan:

Would you mind posting a proposal of how the switch could look like and where it should be positioned?

Gábor Hojtsy’s picture

The lots of (all languages) notes can get boring fast, people may not notice. I agree something better would be great. We did not want this to be the final solution either :)

Gábor Hojtsy’s picture

Issue tags: +Needs design

@Bojhan: do you have a solution in mind?

Bojhan’s picture

It kinda depends on what we are looking to do, are we hiding everything that isn't the shared language or something else?

plach’s picture

I think the opposite: we are hiding everything that is not translatable, at least when language is not the original

matsbla’s picture

I would hide it even for the original language, maybe make a collapsed block at top/bottom named "Global settings" or similar.
(Just as we have global settings for the fields the untranslatable fields are maybe like global settings for the node?)

plach’s picture

What's the point of hiding them on the original language form? Untranslatable fields are regular fields you may wish to edit like any other, they are just somehow confusing on "translation" forms.

matsbla’s picture

As these are global values, I guess it doesn't make more/less sense to hide them in any language, even the original one? They are not just values for the original language?

I would prefer to display the global values only on node creation, and then hide them in a collapsed block when editing any language version (incl. original one). Because when I click to edit a language version of the node I intuitively think that I now only edit a language version (not global values). What if I look at the original source languages and make changes, thinking that these changes will only effect that language version? But then in fact I change the values for all language versions.

It would be more intuitively if I need to click on something like "Global values" before I can edit untranslatable fields (Just like clicking on a language name indicate that you want to edit translatable fields).

Also, I think it happens less often that you edit global values, but maybe more often that you change translatable fields, like text. So it would not only be more intuitive, but also make the edit form look more clean (also for original language).

At least collect all non-translatable fields in one block, then webmasters can control themselves where and when they want it to be collapsed or not.

jhodgdon’s picture

I disagree with #14. If you click "Edit" to edit the node, you should see all editable values, whether they are shared across languages or specific to the original language of the node.

And I don't think that completely hiding these fields when you are editing a translation is the right approach either -- it might be useful to see them (for context). I'm not even sure they shouldn't be editable when you are editing a translation.

It just needs to be made pretty obvious that if you change them, whether you're editing the original or a translation, that you're changing them across all translations.

Gábor Hojtsy’s picture

If we would need to hide them in a box / field set, that would need to contain both fields from the left and right columns, or both columns would have such box at the bottom. Is that what was intended with the suggestion?

Bojhan’s picture

Oke, so from a design point what needs to happen is:

We need to "elevate" the all languages signal. That's all - lets not overdo this.

Some ways to do this:
1) Right-align it
2) Add a icon or any other more visual indicator than just text. (on the left of the text).

csakiistvan’s picture

I see the screen on #2 comment, but it missed the required star element, where is that?

plach’s picture

I think it should keep staying next to the field label, so on the right of the left side :)

csakiistvan’s picture

FileSize
132.25 KB
18.43 KB
3.31 KB
FAILED: [[SimpleTest]]: [PHP 5.5 MySQL] Unable to apply patch 2290101_20.patch. Unable to apply patch. See the log in the details link for more information. View

I think it is not a best solution, see the screenshot please.

Bojhan’s picture

Thanks for working on this, its great to see this patch being worked on. Its a hairy problem, so we might need to do a bit more exploration.

Hmm, maybe just an icon - just after the description?

Don't patch just yet, I need to explore this a lot more!

Bojhan’s picture

Adding some ideas; perhaps we can use a "globe icon" ?

memoo’s picture

I created a Globe icon. But can not upload the .svg ;(

memoo’s picture

FileSize
453 bytes
jhodgdon’s picture

At the size of that PNG, I cannot tell that it is supposed to be a globe.

You can upload an SVG in a zip file.

plach’s picture

I think the current solutions are improving the situation but are not actually addressing all the issues reported in #2. I still think a toggle to hide/show untranslatable fields (without moving them around) would be a good compromise. In ET we have the ability to configure whether hiding untranslatable fields for each entity type/bundle, so that different UIs can have different solutions. Maybe such a setting is too much for core, but at least a toggle could help.

yoroy’s picture

How about making shared fields disabled initially, with a link to unlock them? Would still need a visual indicator, I like the globe icon idea but the styling for that is not quite there yet.

plach’s picture

@yoroy:

As I was mentioning above, the main problem I'd like to address is that forms with many untranslatable fields can become quite hard to "read", for instance:

I was proposing to hide untranslatable fields by default (on translation forms, i.e. where current language != original language) as this would greatly reduce visual clutter in such cases. Moreover it would be consistent with what we display to translators, who are not allowed to edit untranslatable fields and thus cannot see the related widgets. If we go the way I am proposing, editors would see by default (more or less) the same forms translators always see.

memoo’s picture

FileSize
2 KB

Thanks @jhodgdon. Icon uploaded as a zip.

yoroy’s picture

Thanks plach, I see what you mean. Still not sure that hiding is the way to go, because of losing context, as jodgdon says in #14. Further exploring ideas: attached some variations on the globe icon and some with variations on "linked". All icons found on http://thenounproject.com.

jhodgdon’s picture

Instead of completely hiding the fields, would it make sense (both for editors and translators) to have them displayed as output rather than widgets? or disabled fields? If editors need the context, wouldn't translators too? (I didn't realize the fields were completely hidden for translators)... If translators do not need the context, do editors?

Gábor Hojtsy’s picture

@yoroy: I think it makes a ton of sense to display the icon by side of the field and not the label, but the fields may be arbitrary long, possibly full length. Here is a quick screenshot of the node form with possible fields that may be shared or not (set aside for now that the menu widget here is not yet multilingual unfortunately, it should eventually be).

With the icon on the right of the widget, it would need to make the widget smaller if normally it would be full width?

Bojhan’s picture

Ohh, I really like that globe where you can see the continents - that is quite a compact but useful representation.

yoroy’s picture

So putting the icon to the right side (in LTR cases) of the form element is problematic.

Alternatives:

1. Icon, directly after the label. Will visually clash with the required asterisk but does not take up critical space. Icon will have to quite small to not increase the space between label and form element
2. Icon after the label, floated right to the end of the form element. Less visible, will likely look less nice. Not sure this is feasible from markup/css perspective
3. Put the icon in front of the label. Will be very visible, look less nice because it throws of the vertical rhythm of the labels
4. As a background floated right *in* form elements. Will clash with auto complete fields, does not work for all types of form elements
5. As a background floated left *in* form elements. Will be obscured by content of the field, does not work for all types of form elements
6. In front of form elements, keeping form element in place. Takes up new space and I suspect will be a fragile approach
7. In front of form elements, moving the form element to the right. Very visible because quite ugly. Extra space can be countered by making the form element less wide.

Maaaaaybe, in front of the label (3) is the most sensible approach?

jhodgdon’s picture

Assuming the icon is very clear, I like (1) or maybe (3)... visually I kind of prefer (1) because it's near the * for required...

But if that is the only indication, the icon would have to be immediately recognizable. I mean, the * is very clear because everyone uses it. But the globe... I'm not convinced. I guess you'd have a hover/alt/title text for it that would tell you what it means, which would help.

Gábor Hojtsy’s picture

I agree 3 would at least work with widget groups too. Eg. if the whole menu widget needs the icon, would we add the icon on the widget group or each widget individually?

omar’s picture

I think I'd also lean towards (3) and the "globe with continents" (perhaps flipping between the positive/negative versions when the field is in focus).

While (1) has the advantage of not breaking the alignment of the labels, and putting the icon next to the "*" as makes for some sort of functional grouping, IMHO, keeping the icon and the "*" apart as in (3) gives them each more emphasis, which is part of the goal.

jhodgdon’s picture

I change my vote to #3. ;)

yoroy’s picture

FileSize
41.86 KB

Does it even have to be an icon?

Not sure the color should be "error" red, but it does stand out nicely this way.

yoroy’s picture

FileSize
44.68 KB

Could even use an applicable html tag for it!

Gábor Hojtsy’s picture

@yoroy looks good to me :)

andypost’s picture

I'd prefer to move separator "|" into css so showing contrib an approach to use for such properties

yoroy’s picture

@andypost: I agree, this should definately not be a character but done through CSS.
@gabor: cool :-)

Next up:

- Tweak the design: should it be uppercase? background & foreground color, etc.
- A patch implementing this. Would be good to have something that we can really test to see where it might break things.

Gábor Hojtsy’s picture

Issue tags: -Needs design +sprint
Bojhan’s picture

What about using our warning color for this? (not background, just foreground).

yoroy’s picture

Ah, I was just mocking it up but as background :-)

As text color there will probably issues with legibility in some cases, like in this sidebar:

mkalkbrenner’s picture

Assigned: Unassigned » mkalkbrenner
Maouna’s picture

Assigned: mkalkbrenner » Maouna
emma.maria’s picture

We have a similiar implementation of a yellow label/marker in this issue #867830: "unpublished" status of rendered entities is not accessible (and looks bad). We should combine effort and implementation together for this component.

Maouna’s picture

After a discussion LewisNyman, we decided do as mentioned in #49

LewisNyman’s picture

Maouna’s picture

FileSize
1.6 KB
FAILED: [[SimpleTest]]: [PHP 5.5 MySQL] 113,533 pass(es), 1 fail(s), and 1,021 exception(s). View

With the updated mark theme function this patch should work.

mkalkbrenner’s picture

Status: Active » Needs review

The last submitted patch, 20: 2290101_20.patch, failed testing.

Status: Needs review » Needs work

The last submitted patch, 52: 2290101-shared-mark-51.patch, failed testing.

Maouna’s picture

Assigned: Maouna » Unassigned
Status: Needs work » Needs review
FileSize
1022 bytes
FAILED: [[SimpleTest]]: [PHP 5.5 MySQL] 113,575 pass(es), 1 fail(s), and 0 exception(s). View

Status: Needs review » Needs work

The last submitted patch, 56: 2290101-shared-mark-56.patch, failed testing.

The last submitted patch, 20: 2290101_20.patch, failed testing.

The last submitted patch, 52: 2290101-shared-mark-51.patch, failed testing.

The last submitted patch, 56: 2290101-shared-mark-56.patch, failed testing.

Maouna’s picture

mgifford’s picture

Issue tags: +Needs tests
StryKaizer’s picture

Assigned: Unassigned » StryKaizer

Working on test

StryKaizer’s picture

FileSize
1.04 KB
FAILED: [[SimpleTest]]: [PHP 5.5 MySQL] 113,745 pass(es), 1 fail(s), and 0 exception(s). View
2.03 KB
FAILED: [[SimpleTest]]: [PHP 5.5 MySQL] 113,743 pass(es), 1 fail(s), and 0 exception(s). View

Attached is a fix for current tests to succeed, which does not require #867830: "unpublished" status of rendered entities is not accessible (and looks bad).

Once #867830: "unpublished" status of rendered entities is not accessible (and looks bad) lands, we can add more detailed testcoverage for this

StryKaizer’s picture

Assigned: StryKaizer » Unassigned
Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, 64: ui_telling_you_a_field-2290101-64.patch, failed testing.

The last submitted patch, 64: ui_telling_you_a_field-2290101-64.patch, failed testing.

StryKaizer’s picture

jhodgdon’s picture

Just a question about the UI...

Do you think the word "shared" is sufficient to get across the point that the field value is shared across all languages?

jhodgdon’s picture

To expand on that, it seems to me that in the context of content editing, "shared" could be confusing. For instance, taxonomy term names are "shared" across all content items classified by them, and user name of the author is "shared" across all content they authored. ???

Bojhan’s picture

Perhaps we should add a tooltip?

yoroy’s picture

Having a word instead of an icon is already better. People will only have to learn the specific meaning of it once, so a tooltip would be good indeed.

Maouna’s picture

And how about keeping as text "all languages"? It is quite long, but less confusing...

Maouna’s picture

FileSize
93.1 KB
94.14 KB
92.43 KB

I made some screenshots. The first one is how it is now. And two proposals using the mark theme function.

Gábor Hojtsy’s picture

YesCT’s picture

1
I agree with @matsbla in #75

Let's keep "All languages" phrase.
It will help those with D7 experience not confuse the message with how we used to be able to share (re-use) fields in content types.

2
@mgifford in #62 you added the needs tests tag, but what tests coverage are we missing that we need to add?

3
#867830-208: "unpublished" status of rendered entities is not accessible (and looks bad) might be isolating the change to markup to use the mark tag. do we want to do that similarly in another new issue for this?

Gábor Hojtsy’s picture

Issue summary: View changes

Updated summary. #867830: "unpublished" status of rendered entities is not accessible (and looks bad) is the only requirement we have before this right?

jhodgdon’s picture

+1 for keeping the text "all languages" and making it orange or some suitably bright color, rather than changing the text to 'shared'. "Shared" is just slightly shorter, while "all languages" is MUCH MUCH clearer, since it actually tells you what is going on.

StryKaizer’s picture

#79Yes, its the only requirement for this.

Maouna’s picture

FileSize
778 bytes
2.04 KB
FAILED: [[SimpleTest]]: [PHP 5.5 MySQL] 113,232 pass(es), 1 fail(s), and 0 exception(s). View

As there are good reasons to stick with "all translations", I updated the patch using this string instead of "shared".

Maouna’s picture

FileSize
799 bytes
2.04 KB
FAILED: [[SimpleTest]]: [PHP 5.5 MySQL] 113,219 pass(es), 2 fail(s), and 0 exception(s). View

Made "all languages" translated.

Gábor Hojtsy’s picture

Status: Needs work » Needs review

Keep testing it.

The last submitted patch, 82: ui_telling_you_a_field-2290101-82.patch, failed testing.

Status: Needs review » Needs work

The last submitted patch, 83: ui_telling_you_a_field-2290101-83.patch, failed testing.

Maouna’s picture

FileSize
1.15 KB
2.06 KB
FAILED: [[SimpleTest]]: [PHP 5.5 MySQL] 113,248 pass(es), 2 fail(s), and 0 exception(s). View

Sorry, I forgot to update the test, too. Just realised it now. Anyway, the test will fail as long as we are waiting for https://www.drupal.org/node/867830. But locally, with both patches applied, the tests are passed.

Gábor Hojtsy’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, 87: ui_telling_you_a_field-2290101-87.patch, failed testing.

The last submitted patch, 82: ui_telling_you_a_field-2290101-82.patch, failed testing.

The last submitted patch, 83: ui_telling_you_a_field-2290101-83.patch, failed testing.

The last submitted patch, 87: ui_telling_you_a_field-2290101-87.patch, failed testing.

Gábor Hojtsy’s picture

Issue summary: View changes
Status: Needs work » Postponed
YesCT’s picture

Issue summary: View changes
Issue tags: -Needs tests

taking shared as an option out of the issue summary, we did decide (see #78 #80 #82)

and I think we have tests... so removing the needs tests tag.

matsbla’s picture

In #2465907: Node revision UI reverts multiple languages when only one language should be reverted the untranslatable field ended up being refered to as 'content shared among translations'
Maybe it could be a good idea to use expressions in a coherent way? Like 'all translations'.
I also think that 'all translations' is a little bit more clear than 'all languages'

webchick’s picture

I just pushed #867830: "unpublished" status of rendered entities is not accessible (and looks bad) to 8.1.x, since it's a "pre-existing condition" and the impact vs. disruption balance doesn't really weigh out for me.

However, this one is definitely worse, since it was a problem introduced in D8. Why is this one postponed on the other? They seem unrelated.

Gábor Hojtsy’s picture

@webchick: they use the same UI element / design / twig template / css:

+++ b/core/modules/content_translation/src/ContentTranslationHandler.php
@@ -543,7 +543,12 @@ protected function addTranslatabilityClue(&$element) {
-      $suffix = ' <span class="translation-entity-all-languages">(' . t('all languages') . ')</span>';
+      $build = array(
+        '#theme' => 'mark',
+        '#status' => t('all languages'),
+        '#type' => 'warning',
+      );
+      $suffix = drupal_render($build);

This is what the patch docs :) The 'mark' theme is introduced there.

jhodgdon’s picture

Can we steal the part of the patch on the other issue that we need, and add it to this issue's patch instead?

Gábor Hojtsy’s picture

No, #867830: "unpublished" status of rendered entities is not accessible (and looks bad) modifies the existing mark template to be generic and reusable. We can come up with our own custom marker template here with a copy of their CSS/library definitions if we **really** need to which would become obsolete again when they introduce their more general one.

Gábor Hojtsy’s picture

Version: 8.0.x-dev » 8.1.x-dev
Issue tags: -sprint

Given the dependency on #867830: "unpublished" status of rendered entities is not accessible (and looks bad), moving to Drupal 8.1.x. Also off the sprint.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Pancho’s picture

Status: Postponed » Needs work

Agree with @webchick in #96 that this serious usability bug should not necessarily be postponed on that other issue. Anyway, IMO @jhodgdon hit the nail earlier in #31:

Instead of completely hiding the fields, would it make sense (both for editors and translators) to have them displayed as output rather than widgets? or disabled fields?

While we would always show all fields to provide translators with the necessary context, untranslatable fields would only be enabled when editing the original language, which would better convey their cross-language nature than any colorful or wordy hint.

To cater for some other, non-standard use cases, contrib may still add an edit icon to unlock the shared field, so it may still be updated within any language's context. But in 98% of all cases this would not be considered a good idea.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.