UI telling you a field is shared across languages is way too subtle

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.

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:

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

@Bojhan:

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

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 :)

@Bojhan: do you have a solution in mind?

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

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

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?)

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.

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.

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?

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).

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

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

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

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!

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

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

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.

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.

@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.

Thanks @jhodgdon. Icon uploaded as a zip.

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.

@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?

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

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?

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?

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.

Does it even have to be an icon?

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

Could even use an applicable html tag for it!

@yoroy looks good to me :)

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

@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.

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

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:

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

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

See this comment

With the updated mark theme function this patch should work.

Updated the patch. It works in combination with https://www.drupal.org/files/issues/unpublished_status_of-867830-188.patch

Working on test

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

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

My bad, the fix in #64 also requires #867830: "Unpublished" style of rendered entities is not accessible (and looks bad) to land first.

Perhaps we should add a tooltip?

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.

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

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

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" style 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?

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

#79Yes, its the only requirement for this.

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

Made "all languages" translated.

Keep testing it.

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.

Postponing on #867830: "Unpublished" style of rendered entities is not accessible (and looks bad).

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.

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'

I just pushed #867830: "Unpublished" style 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.

@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.

No, #867830: "Unpublished" style 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.

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

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.

I agree with @Pancho, @jhodgdon and @plach. Using labels like "Shared" or "All language" makes it sounds like the field has no language, but it is not true. Since the field has its own language, I think it should be editable only on the original language. We could display the field as non-editable on different languages to provide the necessary context to translators. A label could say that the field is "Not translatable, from {langname}" and points users to the original language to edit it.

it should be editable only on the original language.

I think from a users view there are many cases where it is desirable to be able to edit un-translatable field together with the translation, and such a solution would end up become limiting if it is not at least possible to configure these fields to be editable also on translation form.

If this is how this issue will be solved I think it would be very important to first solve #2451693: Operations links on the translations overview page do not link to the correct route, because if a websites language detection is based on domain detection then it will only be possible to edit the original language using the UI of original language, so only a person speaking the original language would then be able to edit the untranslatable field; a really horrible multilingual experience I guess.

Ran across this randomly from another issue; adding the appropriate tag so we go over it in the weekly UX meetings eventually. :)

@webchick:

Please note that we are adding the option to hide untranslatable fields (always, no JS toggle) on translation forms in #2878556: Ensure that changes to untranslatable fields affect only one translation in pending revisions, as part of the work to make Content Moderation play nice with multilingual entities.

@plach / #110
Just to bring up an issue I just encountered: Hiding untranslatable fields does not work with Paragraph / ERR fields, because pararaph fields are not translatable (but the fields of the paragraph entity are and should be translatable). So if you enable this option, all paragraphs are hidden too, even though the paragraphs (sub-fields) need to be translated.

In general I really like the idea of hiding untranslatable fields, would be nice though if there was a way to use it with Paragraphs.