Problem/Motivation

The upcoming editing form for entities will allow to edit translatable and non-translatable values on the same form.
To maintain the usability the form elements should have a way to indicate whether the are language specific or not.

Proposed resolution

Introduction of a new form element property e.g. #multilingual that allowes to define whether a field element is language specific or not.
The behavoir should be equal to the #tree property, which means child elements inherent the property value from the parent but can override it if necessary.

Remaining tasks

User interface changes

API changes

Related issues

#1807776: Support both simple and editorial workflows for translating entities postponed on this issue.
D7 #1282018: Improve UX of language-aware entity forms
#1188388: Entity translation UI in core

Files: 
CommentFileSizeAuthor
#4 add-2012-12-26_0023.png59.19 KBYesCT
#4 af-2012-12-26_0024.png59.84 KBYesCT

Comments

YesCT’s picture

YesCT’s picture

Issue summary: View changes

Updated issue summary.

YesCT’s picture

Issue summary: View changes
YesCT’s picture

related background see #1188388-54: Entity translation UI in core/2 and #57

Also, #1188388: Entity translation UI in core has a work around to do a simple version.

plach’s picture

Title: UX: Introduce a #multilingual key (or similar) for form element » Introduce a #multilingual key (or similar) for form element
Issue tags: +Usability
YesCT’s picture

When adding content, the fields are not noted with what would be shared across languages if translated.

add-2012-12-26_0023.png

When adding a translation, it shows which fields, when changed, would change every translation (and the actual content/node). Those are marked with (all languages) on the field labels.

af-2012-12-26_0024.png

Next steps:
determine if this issue is still needed or if it is solved as part of the previous work.
if it is still needed: add more detail in the form of specific next steps to take.

YesCT’s picture

Issue summary: View changes

Updated issue summary to put related issues together under related issue heading and added et-ui 1188388 as a related issue

plach’s picture

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

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should 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.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should 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.

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

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should 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.