This is a follow-up in response to #1188388-54: Entity translation UI in core comment 54 item 5

Problem

It's hard to find the location of the setting to enable translation on fields. Following a pattern of showing a hint as to the value of a setting in a collapsed fieldset or in a vertical tab, the entity translation ui can be improved.

proposed resolution

A) add a message automatically
or
B) pre-fill the revision log

Remaining tasks

Implement a resolution.

User interface changes

Suggested change: http://drupal.org/files/et-ui-s005-can revisions tab be translation aware 2012-10-03_1248.png

API changes

Are there API changes/additions that would affect module, install profile, and theme developers?

Comments

YesCT’s picture

Gabor's comments from comment 57 in the original issue:

#54/5: on revisions; through the UI people can only edit one translation at once, so we could theoretically inject some log message information on which language they edited; not sure what language would that log message be? also would it be injected after the user provided message? should we automate that or just prefill the log message and let the user edit it as needed/intended? on the diff module side-note, yes, diff module should be compatible with this, the underlying field language support was already in Drupal 7 :)

YesCT’s picture

Title: Autofill revision log with text that describes action like: German translation added or Spanish translation edited [Follow-up] » Autofill revision log with text that describes action like: German translation added or Spanish translation edited

adding to the list of follow-ups at #1836086: [meta] Entity Translation UI improvements

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.

miro_dietiker’s picture

We recently started improving the Revision tab in diff.

See Diff issue #2462731: Check RevisionLogInterface for summary and provide
We are overriding the Revision tab anyway, so we are applying custom logic to the revision summary.
If the Entity has no revisionLogInterface or the text is empty, we are autogenerating it.
Our first implementation just indicates the changed fields with excluding technical fields such as "changed" that always change.
While this allows to have a feasible message, it leads to overhead: We need to compare each revision with its predecessor to get the message. If you want to avoid this overhead, you can generate and persist the message.

For Entities without revisionLogInterface we still might want to provide the fallback.
Also we need to consider that storing this message makes it untranslatable.
Plus to alter / improve it, i would like to know that the message is autogenerated, so i can replace it.
Semantically, the autogeneration explains "what" while chances are the user notes would also explain "why".
As long as we can't detect if autogeneration happened, i would vote against storing it as it seems the overhead is limited.

miro_dietiker’s picture

People asked at Diff to show both at the same time:

  • What: Show field names for changed fields
  • Why: Show the message

So it seems this should not be a fallback, but we should do both at the same time?
See #2811937: Show revision log message on node revision overview page