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:
API changes
Are there API changes/additions that would affect module, install profile, and theme developers?
Comments
Comment #1
YesCT CreditAttribution: YesCT commentedGabor'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 :)
Comment #2
YesCT CreditAttribution: YesCT commentedadding to the list of follow-ups at #1836086: [meta] Entity Translation UI improvements
Comment #5
miro_dietikerWe 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.
Comment #6
miro_dietikerPeople asked at Diff to show both at the same time:
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
Comment #10
matsbla CreditAttribution: matsbla commentedI created this issue that might be a good solution for this issue #2978701: Replace the revision log message with a comment field
Comment #11
miro_dietikerWe recently removed the code that autogenerated a diff message (based on effective field change) if the revision log was empty.
#2880936: Remove runtime generated summary: Diff overhead on revisions gets exponential
We realised that displaying the field name of the changed field wasn't helpful at all. Instead an inline content change preview would be best.
Our goal for diff is now much more to persist a minified content diff that we generate when a revision is saved.
And we don't want to save this in the "revision log" field as that should only be used for human input.
That said, beside outputting the affected language, there's also need to display workflow transitions.
Not sure how the proposed solution (using a comment field) would improve the situation. We need extra fields / properties and a way to hook into revision display to enrich status / summary information.
Comment #12
matsbla CreditAttribution: matsbla commentedOkay it sounds like a good idea! Doesn't that make this issue obsolete? Anyway I think we should be careful to make assumptions about how the revision table should be for all sites. I think the best solution would be to solve #1863906: [PP-1] Replace content revision table with a view and then provide a fields formatter for the diff. Then site builders can configure and have full control of how the revision table should look like on their site.