Closed Bug 619284 Opened 15 years ago Closed 10 years ago

Create a "draft" status for unfinished translations

Categories

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

Tracking

(Not tracked)

RESOLVED FIXED
Future

People

(Reporter: underpass_bugzilla, Assigned: safwan)

References

Details

(Whiteboard: u=contributor c=l10n p=3 s=)

Attachments

(1 file)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; it; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13 Build Identifier: If a contributor wants to translate a long document, he or she might not be able to finish the work in one session (especially for long articles like "Browsing basics"). It would be better if he could leave the translation in draft status to finish the work later without the need to submit it for approval. Hence my proposal of creating a "draft" status for a translation. Unfinished translation should appear in a separate section of the Localization Dashboard as "Unfinished translations" (or simply "Drafts"). Reproducible: Always
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
An easy workaround is to save your edit in a text file on your computer so that you can cancel your edit and continue offline or in a later session on SUMO.
Sure it is, but it's not very easy to understand for new localizers. Apart from this, there should be a way to easily doewnload the article source in order to translate it offline (now by now you must login, edit or translate an article, select all, copy and past into an editor).
(In reply to comment #2) > Apart from this, there should be a way to easily doewnload the article source > in order to translate it offline (now by now you must login, edit or translate > an article, select all, copy and past into an editor). Bug 616326 should help with that.
Priority: -- → P3
Whiteboard: u=contributor c=l10n p=3 s=
Target Milestone: --- → 2012Q4
Whiteboard: u=contributor c=l10n p=3 s= → u=contributor c=l10n p=3 s=2012.22
Whiteboard: u=contributor c=l10n p=3 s=2012.22 → u=contributor c=l10n p=3 s=2012.23
Dropped to next sprint during planning
Whiteboard: u=contributor c=l10n p=3 s=2012.23 → u=contributor c=l10n p=3 s=2012.24
Whiteboard: u=contributor c=l10n p=3 s=2012.24 → u=contributor c=l10n p=3 s=2013.1
Target Milestone: 2012Q4 → 2013Q1
There is no significant interest in this from the English KB editing side, we'll need to assess the need from the localizers side. This would be quite an intricate project. Moving to next sprint.
Whiteboard: u=contributor c=l10n p=3 s=2013.1 → u=contributor c=l10n p=3 s=2013.2
Whiteboard: u=contributor c=l10n p=3 s=2013.2 → u=contributor c=l10n p=3 s=2013.3
Kadir: Comment #7 sounds like you're not sure whether this should be done or not. If you're on the fence, it shouldn't be in a sprint at all.
I'm moving this out of the sprints until we have a clear understanding whether it would make sense to go forward with it.
Whiteboard: u=contributor c=l10n p=3 s=2013.3 → u=contributor c=l10n p=3 s=
Q1 is in the past. Moving to the future.
Target Milestone: 2013Q1 → Future
No longer blocks: 790785
(In reply to Kadir Topal [:atopal] from comment #7) > There is no significant interest in this from the English KB editing side, > we'll need to assess the need from the localizers side. This would be quite > an intricate project. Moving to next sprint. Really? .. I would love this for the English KB and not just for localizers..
If I remember correctly, this as not seen as a priority for English, because we have the "changes needed" field, where you can mention that the article is not ready yet. No such feature exists for localized articles.
Sorry, is there any plan to have this bug solved?
I'm looping in vesper so he can make the call for L10N.
Flags: needinfo?(mdziewonski)
If we want this as a feature, it needs to be built & tested. We can add this to our backlog and see when we'll have dev time to get to it. In the meantime, I can update the l10n process description to mention that if you can't finish a long article in one go, you can "Submit" your work with a note saying "work in progress, do not publish" - and make both localizers and reviewers aware of that. Simone, what do you think about that?
Flags: needinfo?(simone.lando)
Flags: needinfo?(mdziewonski)
Hi Vesper, sorry but it is not the same thing. The feature is needed in order not to loose the "chain" with en-us versions of articles. Currently I cannot submit an incomplete version since it would break the link with en-us edits.
Flags: needinfo?(simone.lando)
Hi Simone, Do you have any examples of a similar feature around (or outside of) Mozilla? Safwan mentioned MDN that has autosaving built into Kuma, the content platform used there. Would that be a good solution? I am also wondering how this would differ from the current system. I tried saving my unfinished work as a revision and it worked OK. I don't think I lost any link with the en-US edits - usually, we translate whatever the current EN-US version is into our locales, so I would overwrite other people's (or my own) older revisions, if they were not submitted, reviewed, and published, the same way. Maybe I'm doing it wrong (that's always a possibility :-)) Some more questions: Where would the "draft" versions be visible in the history page of the wiki document? Would anyone be able to access my drafts? What happens with my draft if a new version in my locale is submitted, reviewed, and published before I finish working on my draft? Does it get deleted? Automatically updated to the latest locale version? The longer story here is that this is a feature that would probably take a lot of time and effort to put into Kitsune. Joni is working to make the KB bigger (= more articles), but shorter (= shorter articles). So, we may not need "draft" saving "for later". If you could translate an article in 15 minutes or less, what would be the point of saving unfinished work? If you couldn't sit down for 15 minutes to translate an article, should you be starting at all?
Flags: needinfo?(simone.lando)
Hello, the situation is incredibly common. A very long article could be translated in various steps (one paragraph for session). I wish to avoid cluttering the revision table with dozens of unfinished revisions. That's all.
Hi Simone, I understand the need, and I have the same wish. How do you think should the feature look like? As an aside - I tested keeping an article tab open between days, with my edits in it, to see if keeps my edits. It does. Would that be an acceptable tip to our localizers: "If you haven't finished localizing an article, just keep the tab open when you close your browser and the tab should keep and show your edits the next time you open your browser, as long as you don't delete your cache."?
> Would that be an acceptable > tip to our localizers: "If you haven't finished localizing an article, just > keep the tab open when you close your browser and the tab should keep and > show your edits the next time you open your browser, as long as you don't > delete your cache."? Please don't do that. The risk to lose data is too high. One lost half article translation can frustrate our localizers. I know that from the past. What is the planned max. line number of new articles? This feature is not only useful for long articles but for localizer teams with more people.
> This feature is not only useful for long articles but for localizer teams > with more people. Agreed with Thomas. @Vesper: each draft should be linked to its "master" en-us document, and should not count as an approved revision. It should be clearly recognizable (say "Draft") should bear at least two links: "Save as revision" and "Discard draft".
Flags: needinfo?(simone.lando)
This is something that is a need, and not a want for KB contributors. If this was added, it might help with the revising of articles to be easier and more efficient. Of course, this does depend on when SUMOdev has the time to do such thing, unless contributors are available to take this project and try to implement it.
I am very surprised that this bug is still unresolved after more than 5! years and that some people doubt the necessity of this feature. Needless to say, it is necessary! Translating articles which can be very long is not the same as translating some more or less long strings. Even for emails which are mostly short a draft mode is available in mail clients as such like Thunderbird. So, why not for long articles? It should be a given to make translating easier to translaters as effectively as possible. I think, there is no need for a version history for the draft mode. The only purpose of the draft mode should be to buffer the recently translated text. Translating offline in an external editor can be a workaround only.
I think this might be implemented as a small update of revision workflow, something like mark a revision not ready for review or be able to have living revision until submitted for review. Two new Czech contributors were asking about this feature (if it exists), and we decided to workaround this using revisions and marking them WIP in comments. So there is an option how to achieve that, but not ideal, as the translation status is the same as of those ready for review.
So the very very long wait maybe come to an end. I have been working on a patch which will implement the feature. It will works following # Contributor go to the Translation page and beside the submit button, they will see a "Save Draft" Button # If the contributor clicks on the draft button, the title, slug, keywords, content and the other things which the user have entered will be saved on the sumo server # Next time when the contributor goes to translate the page, he will see a message that a draft has been saved and will see two button "Restore" and "Discard" ## If he press "Restore", the page will be reloaded with the data which the contributor saved as draft ## If he press "Discard, the draft will be discarded from the server Things to be noted: * This feature will only available in the translation page. So only localizers will get the feature * The based on will be honoured. Means that if a contributor saves a draft which is based on "xx" revision, in the next time, if he restore the draft and submit it, the revision will be based on the "xx" revision. ** Initially, when a localizers submit a revision, it is always based on the latest localization revision of english one. But restoring the draft revision will be an exception. What do you think about the feature? Vesper,
Flags: needinfo?(thomas.lendo)
Flags: needinfo?(milupo)
Flags: needinfo?(mdziewonski)
Would be possible to see drafts of other users? E.g. when I am a locale reviewer and want to discuss with some editor about his work in progress without submitting it?
(In reply to Michal Stanke (Mozilla.cz) [:MikkCZ] from comment #27) > Would be possible to see drafts of other users? E.g. when I am a locale > reviewer and want to discuss with some editor about his work in progress > without submitting it? I think seeing drafts of other user should be covered by another bug. I am trying to get the work done and then we can add more feature. For now saving as draft maybe enough and we can implement seeing others drafts in future with other bug.
(In reply to Safwan Rahman from comment #28) > (In reply to Michal Stanke (Mozilla.cz) [:MikkCZ] from comment #27) > > Would be possible to see drafts of other users? E.g. when I am a locale > > reviewer and want to discuss with some editor about his work in progress > > without submitting it? > > I think seeing drafts of other user should be covered by another bug. I am > trying to get the work done and then we can add more feature. For now saving > as draft maybe enough and we can implement seeing others drafts in future > with other bug. Thank you. :) Just curious if drafts will be publicly listed, or just for their authors. Great to have them at all!
This sounds great and looks like it addresses the original request. By giving the draft option only to the translator that worked on it and not including it in the dashboard (at the moment), we can avoid confusion and help the localizer finish a longer article. I am wondering about one more scenario: 1. localizer A starts localizing the article, saves a draft 2. the source (en-us) gets updated 3. localizer B localizes the whole article based on the new en-us update, submits the new revision 4. localizer A goes back to his/her draft, wants to submit the revision based on the old version Would it be possible to show a warning that there is a more recent revision, so that localizer A does not create a revision? In the end, it's all about the reviewer to approve or defer, so maybe that is not *critical*, but could be useful? What do you think Safwan?
Flags: needinfo?(mdziewonski)
> I am wondering about one more scenario: > > 1. localizer A starts localizing the article, saves a draft > 2. the source (en-us) gets updated > 3. localizer B localizes the whole article based on the new en-us update, > submits the new revision > 4. localizer A goes back to his/her draft, wants to submit the revision > based on the old version > > Would it be possible to show a warning that there is a more recent revision, > so that localizer A does not create a revision? In the end, it's all about > the reviewer to approve or defer, so maybe that is not *critical*, but could > be useful? What do you think Safwan? Sure. Its possible to show a warning there. Can you please let me know, what message should be written in the warning?
(In reply to Safwan Rahman from comment #31) > Sure. Its possible to show a warning there. Can you please let me know, what > message should be written in the warning? Maybe we could reuse the existing string: "This version is outdated, but there is a new version available." #: kitsune/wiki/templates/wiki/review_translation.html:44 from LC_MESSAGES/django.po
Attached file Proposed Patch
The patch has successfully merged into master. Waiting for the deployment into production.
Assignee: nobody → safwan.rahman15
Status: NEW → ASSIGNED
Flags: needinfo?(thomas.lendo)
Flags: needinfo?(milupo)
Thanks a lot Mythmon, Rehan and brittanystoroz for the Review.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Hello, thanks for all. Could you put the same button even at the bottom of the page (where the other set of buttons lie)? Thanks again.
See Also: → 1761997
See Also: → 1520567
See Also: → 1857726
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: