Implement diff picker for updating translations

RESOLVED FIXED

Status

Mozilla Developer Network
Localization
P1
enhancement
RESOLVED FIXED
4 years ago
3 years ago

People

(Reporter: fscholz, Assigned: jezdez, NeedInfo)

Tracking

(Blocks: 1 bug)

Details

(Whiteboard: [specification][type:feature][LOE-ux:s][LOE:8][needs-tech-eval][needs-definition])

Attachments

(1 attachment)

(Reporter)

Description

4 years ago
What problems would this solve?
===============================
Keeping our localized pages up to date is critical. One important feature for updating pages properly, is a diff picker that lets you choose which English revisions you want to compare.

If a localizer saves a page during translation or updating, the diff is no longer shown because the logic assumes that  - with the edit date being more recent - the content is up to date and no diff is needed.

Who would use this?
===================
Localizers who keep pages up to date.

What would users see?
=====================
A modal dialog letting you choose which revisions you want a diff for.

What would users do? What would happen as a result?
===================================================
Localizers would be able to see the diff they need to the keep the page in sync with the English one.

Is there anything else we should know?
======================================
Already noted as a todo in the code :)
{# TODO: 'change revisions' link and modal selector #}

https://github.com/mozilla/kuma/blob/master/apps/wiki/templates/wiki/translate.html#L74
(Reporter)

Updated

4 years ago
Component: General → Localization
(Reporter)

Comment 1

4 years ago
Created attachment 8439382 [details]
Diff picker on sumo
(Reporter)

Comment 2

4 years ago
fwiw, I'm pretty sure this bug would improve the workflow of many localizers. I encounter this problem myself when trying to keep German articles up to date and then not being able to see the correct diff.
Assignee: nobody → design
Whiteboard: [specification][type:feature] → [specification][type:feature][LOE-ux:?]

Updated

4 years ago
Severity: normal → enhancement
Flags: needinfo?(shobson)
I confirm this would help a lot the workflow of our translators.
Most of the UI elements for this already exist in one way or another. Not too much work from a UX or front-end perspective.
Whiteboard: [specification][type:feature][LOE-ux:?] → [specification][type:feature][LOE-ux:s]
Whiteboard: [specification][type:feature][LOE-ux:s] → [specification][type:feature][LOE-ux:s][LOE:?]
It'd be great if any lightbox type of thing this uses is provided as a widget that can be used by other code; we have many things that eventually we'll want presented in lightbox format (likely on-site messaging stuff at times, other diff functions, etc).
Blocks: 1032321
(Assignee)

Updated

3 years ago
Assignee: design → jezdez
Punted to Luke to help hammer down the specific requirements.
Flags: needinfo?(lcrouch)
Keywords: productwanted
Whiteboard: [specification][type:feature][LOE-ux:s][LOE:?] → [specification][type:feature][LOE-ux:s][LOE:?][needs-tech-eval][needs-definition]
Basically, for :hoosteeno - do we want to copy SUMO's UX for this? That will tell us how to estimate this.
Flags: needinfo?(shobson)
Flags: needinfo?(lcrouch)
Flags: needinfo?(hoosteeno)
We already have a diff picker on MDN (https://developer.mozilla.org/en-US/docs/Web/XPath/Functions/floor$history), I imagine it would be easier to embed ours in a lightbox with different buttons.
SUMO's interface is satisfactory: We can use it. Let's do an LOE evaluation of this.
Flags: needinfo?(hoosteeno)
Keywords: productwanted
Priority: -- → P1
We already have an endpoint to get the content diff table between arbitrary revisions of a doc. E.g.:

https://developer.mozilla.org/en-US/docs/User:codegroover$compare?to=643705&from=642397&raw=1
https://developer.mozilla.org/en-US/docs/User:codegroover$compare?to=643705&from=639903&raw=1

(This is how we render the diffs in the revision dashboard)

So, one way to implement this is:

1. User clicks diff-picker link
2. Modal opens with $history view of the English doc
3. User chooses 'from' and 'to' revisions
4. Modal closes, triggers ajax call to $compare?...&raw=1
5. Inject response HTML into the page's diff view container

We would need to:

1. Add UI elements (2 days)
2. A way to open $history view in this "modal mode" (2 days)

Issues:

1. We should remove the title, slug, and comment since those aren't included in the raw compare HTML, so we couldn't update them to the new from revision values. (SUMO doesn't show these either, since translators (I think) are not allowed to edit them anyway?)

So, I say LOE:5 unless we want to preserve title, slug, and comment in the compare viewer. Then I would say LOE:10 because we would have to do either a whole new compare view, or re-write the current one to include those elements.
Whiteboard: [specification][type:feature][LOE-ux:s][LOE:?][needs-tech-eval][needs-definition] → [specification][type:feature][LOE-ux:s][LOE:5][needs-tech-eval][needs-definition]
> "SUMO's interface is satisfactory: We can use it. Let's do an LOE evaluation of this."

Based on our 70/30 discussion, do we want to do better than "satisfactory", where maybe we sketch out exactly what we want, or is this exactly what we want?
:davidwalsh - do you want to sketch out something beyond SUMO's interface before starting?
Flags: needinfo?(dwalsh)
Not necessarily -- I just wanted to make sure we aren't "settling" for this widget, and it's what we want.  "SUMO's interface is satisfactory: We can use it." sounded hesitant or like "better than nothing".  I want to make sure everyone is giggles about this.  I'll proceed as though people are.
Flags: needinfo?(dwalsh)
Whiteboard: [specification][type:feature][LOE-ux:s][LOE:5][needs-tech-eval][needs-definition] → [specification][type:feature][LOE-ux:s][LOE:8][needs-tech-eval][needs-definition]
(Assignee)

Updated

3 years ago
Assignee: jezdez → nobody
:r1cky - do you have any analytics or metrics on how often the SUMO diff-picker is used? Would like to know what we might expect to see on MDN.
Flags: needinfo?(rrosario)
Dev notes from our call to estimate the amount of work to build this: https://etherpad.mozilla.org/l10n-diff-picker-estimate
Sorry for the late reply. My GA-foo is weak, but the URLs look like this:

https://support.mozilla.org/en-US/kb/<slug>/compare?locale=<locale>&to=<revision_id_1>&from=<revision_id_2>

Maybe Kadir can help?
Flags: needinfo?(rrosario) → needinfo?(a.topal)
(In reply to Ricky Rosario [:rrosario, :r1cky] from comment #16)
> https://support.mozilla.org/en-US/kb/<slug>/
> compare?locale=<locale>&to=<revision_id_1>&from=<revision_id_2>

errr.

https://support.mozilla.org/<locale>/kb/<slug>/compare?locale=<locale>&to=<revision_id_1>&from=<revision_id_2>
Wow, okay that looks like a tiny fraction of traffic. 1,302 page-views out of 63,500,000 = 0.00002%.

I'll take that to mean we should expect small usage.

Kadir - how valuable is that comparison diff-picker for SUMO translators?
(In reply to Luke Crouch [:groovecoder] from comment #18)
> Wow, okay that looks like a tiny fraction of traffic. 1,302 page-views out
> of 63,500,000 = 0.00002%.

This is not the right way to measure it. As we all editorial toosl, the impact comes from the increase of traffic from extra pages translated (or extra up-to-date translated pages), not the visits of the page.
What if we measure the increase in pages translated with the diff-picker tool?
(Assignee)

Updated

3 years ago
Assignee: nobody → jezdez
Status: NEW → ASSIGNED
(Assignee)

Updated

3 years ago
Depends on: 1093237
(Assignee)

Comment 21

3 years ago
https://github.com/mozilla/kuma/pull/2876

Comment 22

3 years ago
Commits pushed to master at https://github.com/mozilla/kuma

https://github.com/mozilla/kuma/commit/08d3e725cae33974751c7a68009b5a645c418c02
fix bug 1024649 - add ability to change diffed revisions on translation page

https://github.com/mozilla/kuma/commit/dde106141e8204f9e0bcf270aa1bfd390dcfe227
Merge pull request #2876 from jezdez/bug1024649

fix bug 1024649 - add ability to change diffed revisions on translation page

Updated

3 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.