Closed Bug 682730 Opened 13 years ago Closed 12 years ago

Checkbox to keep the version diff of a translation revision

Categories

(support.mozilla.org :: Knowledge Base Software, task, P2)

Product:
support.mozilla.org
Component:
Knowledge Base Software
Type:
task

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
2012Q4

People

(Reporter: thomas.lendo, Assigned: rrosario)

References

Details

(Whiteboard: u=contributor c=l10n p=2 s=2012.20)

Attachments

(2 files)

Finish editing modal window
86.18 KB, image/png
Details
Show same diff checkbox.
137.31 KB, image/png
Details 
Sometimes a user is correcting a spelling error or is inserting a new screenshot in an article. This action marks the translation of an English article as up-to-date. But in such case this isn't true and when somebody (other) wants to update the article text there is no version diff anymore.

If someone is only inserting a screenshot or correcting a spelling error, e.g. he/she should be able to uncheck a checkbox. Then the article translation is not marked as up-to-date and the next translator can do the text update with the correct version diff.
Yeah, this makes sense to me, but I don't know the internals of how we determine whether a translation is up to date or not. Erik, is this easily possible?
Right now a translation is up-to-date if there is a revision after the most recent "ready for l10n" revision of the English document.

This would be a pretty big switch, since we'd have to start taking into account revision significance on translations.

Is the real issue that the diff is gone? That's easier to fix.
I guess the issue is also that those articles vanish from the dashboard as needing updates.
Thanks, Kadir and James.

Issues are:
1) Diff is gone with that you should update the translation.
2) Such edited articles vanish from dashboards and nobody can't see anymore that their text must be updated.

The way to solve these issues is irrelevant for me. :) But it's a real issue for localization teams with more than 1 person and if a "guest user" is editing something.
My 2 cents. The one who approved this minor fix shouldn't have done it. You can accept minor fixes only when the localization of the last RFL English revision is achieved.
(In reply to Scoobidiver from comment #5)
> My 2 cents. The one who approved this minor fix shouldn't have done it. You
> can accept minor fixes only when the localization of the last RFL English
> revision is achieved.

This is the only solution now, yes. But then some edits have to wait for months for their approvals if we haven't time to update the whole article right after the minor fix (e.g. https://support.mozillamessaging.com/de/kb/tastaturkuerzel/review/4086 is an current example on SUMOMO).
You can have two approval levels for localizers, one minor that won't make the article disappear from the localization dashboard and one normal.
But a reviewer can also made a mistake and approve a normal approval as minor because the English update is minor.

In conclusion, if you add more steps, you have more chance to make mistakes.
Reviewers must reject or let unreviewed valid fixes if nobody has time to fully update the article.
A new step adds a new chance for making mistakes, that's right, but reviewers/approvers should know what they do. A checkbox with short description[*] near the approve/dismiss buttons when reviewing an edit should be sufficient. If you remove the check mark then the article will not vanish from the localization dashboard. If you remove the check mark accidentally then you only have to edit the article again and save it without any edit. No harm, only few seconds of more work.

The English articles shoudn't have this checkbox, only translations of it.


[*] Description example: next edit of this article should show the English diff again and the article won't vanish from the dashbaord.
The description should not say that this checkbox is for "minor" edits, because "minor" is a term used in another context.
Whiteboard: u=contributor c=l10n p=
Blocks: 790785
Target Milestone: --- → 2012Q4
It sounds like, other than simply adding that checkbox, we would also need to write the description in such a way that it’s non-jargony, and very clear to contributors old and new. Having a clear label would prevent misclick. Unfortunately, for features like this that are hard to explain, we tend to use short jargons than user-accessible words.

The basic idea behind this option is to be able to convey:
My revision does not bring this article up to the most current state. Please leave the English diff on for the next round of edit, so those who edit it next won’t think that this article is already up to date.

So, the description text might say something like:
* My revision does not update the article (sounds negative)
* This article is revised, but not up to date yet (confusing)
* This edit does not update the article
* Show English diff on the next edit

In addition to the label, we could also show a small screenshot/diagram, or show a question mark that expands into a tooltip that explains what will happen.

But the label is the easiest solution here.
Bram, your 4th (last) suggestion for description text seems the clearest for me (variation: "Show English diff on the next edit __again__"). It is short and 
says what will happen after changing the checkbox.

A tooltip is a good idea in this situation to explain more precisely what you can do here and what will happen.
There are a couple of things this has to convey:

1. This is explicitly marking the current state as a draft
2. Saving this won't send out a message to anyone
3. This would not go on the L10n dashboard as ready for review
4. The diff would still be shown the next time someone build upon this

So, maybe something more abstract would be better. I like the tooltip idea, explaining what it does, like the level in the review dialog. 


Here is an idea:

1. On the page you have just one button "save"
2. When you click it, we open a dialog box (like the review one)
3. In the dialog you have 2 radio buttons:
o save as draft
o submit for review

4. Hover over each one gives you more info about what it does.
(In reply to Kadir Topal [:atopal] from comment #11)

This is an interesting idea, and because we’re putting the information in a separate modal window, we have more space to convey all the info we need.

Here’s the behavior for this proposal:
* The entry point will be a button called either ”Save” or “Finish Editing”
* A modal window pops up with two buttons: Save as draft and Submit for review
* The tooltip will be one line of text that explains what each button will do
Sounds good to me. Thanks, Bram!
Adding to current sprint. I think this should take 1-2 days.
Whiteboard: u=contributor c=l10n p= → u=contributor c=l10n p=2 s=2012.20
Priority: -- → P2
This bug took a huge turn in Comment 11. This isn't what the bug reporter wanted. They want to be able to make revisions to an article without it changing the revision it is based on. That way it stays "out of date". Having a "Save as draft" is something completely different and doesn't solve that problem.
Here is my proposal for the original bug description.
(In reply to Ricky Rosario [:rrosario, :r1cky] from comment #16)
> Created attachment 673868 [details]
> Show same diff checkbox.
> 
> Here is my proposal for the original bug description.

By default, the checkbox would be unchecked.
I discussed this with Kadir, and we cleared up the confusion. We are going with the checkbox proposal here and the Save Draft will be taken care of in Bug 619284.
Now that this is cleared up, I'll grab it.
Assignee: nobody → rrosario
Two small comments about wording:
* “Diff” sounds technical, but if our contributors understand it, then it’s okay
* Explaining why contributor might want to select the option to keep diff is important

Consider something like:
“This edit does not make this article up to date. The English difference table should not change on the next edit.”
Thanks Bram! I'll go with that or something close to that.
Landed and deployed by :rdalal

83aa09b2662316f4580fac8b600bc71c29cac450
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Hey guys,

We got some feedback that the explanation of this feature isn't really clear. Also, this feature can de facto be used as "save as a draft", if the localizer explains that the article isn't up to date. 

Any ideas on how to improve the working? I know we already put a lot of effort, but it still seems to be confusing.

Thanks,

Rosana
Hey Rosana, thanks for the feedback. Is this about changing the wording or the functionality of this feature? Also, could you elaborate on what specific issues people reported? I guess filing a new bug would be a better way to go forward.
Hi Kadir,

It's more about the wording. Also we can use this feature as a "save as a draft", we just have to specify how. So it's not about the functionality. Should I open a bug for the working?

Thanks
Rosana
Thanks for the info, Rosana. Yes, please file a bug and please cc Bram and Verdi.
(In reply to Rosana Ardila from comment #26)
> Also we can use this feature as a "save as a draft", we just have to specify how.

Can we merge this into bug 619284? I can start working on it this week, if we want.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: