Closed
Bug 639806
Opened 13 years ago
Closed 13 years ago
Let editors mark an article as ready for localization
Categories
(support.mozilla.org :: Knowledge Base Software, task, P1)
support.mozilla.org
Knowledge Base Software
Tracking
(Not tracked)
VERIFIED
FIXED
2011-06-21
People
(Reporter: atopal, Assigned: erik)
References
Details
(Whiteboard: [2011-06-16])
Especially before we releases we want to have a way to let people know which articles are already updated and localizable and which ones aren't. Also for testing purposes we want to be able to test drive article edits without localizers working on the translation of those articles in the mean time. Proposition: Add checkbox to edit section that reads: ready for localization [x] When that checkmark is removed the articles is removed from the localization dashboards. When the box is checked it is put on the dashboards again with the appropiate status and an update message is sent to localizers if applicable. The latest approved revision should carry the flag (to decide what to do on dashboards)
Reporter | ||
Updated•13 years ago
|
Target Milestone: --- → 2011Q2
Comment 1•13 years ago
|
||
For the record: why doesn't the existing "Allow localizations" checkbox cover this use case? It does everything there except send an update to localizers.
Reporter | ||
Comment 2•13 years ago
|
||
At least in my tests it was not possible to toggle the flag once an article was localized into another language. The dashboard would just not allow that. Otherwise we could re-use that flag and just add it to the article-description section of the edit article UI. It should do the messaging thing though.
Comment 3•13 years ago
|
||
(In reply to comment #2) > At least in my tests it was not possible to toggle the flag once an article was > localized into another language. The dashboard would just not allow that. No, it is not, once an article has localizations, marking it unlocalizable doesn't make sense. > Otherwise we could re-use that flag and just add it to the article-description > section of the edit article UI. It should do the messaging thing though. So, it seems like there's a ton of overlap between what's requested here and what we have right now, but this "ready for l10n" feature is a little more powerful. I'd like to *replace* the current "allow l10n" flag with this "ready for l10n" (on a per-revision basis, instead of per-document, correct?) feature. A document can be effectively kept out of L10n dashboards and unavailable for l10n by simply never marking it as "ready for l10n". Maintaining both "allow l10n" and "ready for l10n" (which can do everything "allow l10n" can and more) is just extra complication/code.
Reporter | ||
Comment 4•13 years ago
|
||
The problem we want to solve is: approving new revisions of articles without disturbing localizers. There are several different scenarios where this is needed. 1. When experimenting with an article on the production site to improve the helpfulness rating. 2. When we know we are going to edit the article again in the near future 3. When we are close to a release and want the top articles on the dashboard not reflect top articles that are only applicable for the old version. I'm not sure how you'd solve that in the back-end, either with the existing flag or a new one, but we need to be able to toggle the flag after the articles has been localized already by some locales.
Comment 5•13 years ago
|
||
It seems like an option is to use the current per-document "allow l10n" flag but not have it actually enforce anything: just hide or show the document in l10n dashboards. (And relabel it.) In this case you could toggle it on or off at will, even with existing localizations of a document. It wouldn't necessarily prevent you from localizing the document (though maybe we would still hide the "Localize" tab) but it would keep it out of dashboards. I think that addresses all the use cases.
Reporter | ||
Comment 6•13 years ago
|
||
Sounds good to me, but it would also need to send a message to localizers that an article is ready for localization when you flip the switch. Also we should add UI to the description section of an article for this.
Comment 7•13 years ago
|
||
The UI is there, but it'll need to be updated with a more descriptive label and explanation.
Comment 8•13 years ago
|
||
There is a risk to forget to tick again this check box and create a permanent inconsistency between English and localized KBs. To monitor this, it would be helpful to be able to do queries on articles based on different categories (version, OS, article category, topic, allow l10n status). Kadir, is there a need for that? If yes, file a new bug.
Reporter | ||
Comment 9•13 years ago
|
||
James, Scoobi has a point, we should be able to filter for the flag in the /admin (In reply to comment #7) > The UI is there, but it'll need to be updated with a more descriptive label and > explanation. This should be on the front end, I can't see it there: http://awesomescreenshot.com/03bajto01
Comment 10•13 years ago
|
||
(In reply to comment #9) > James, Scoobi has a point, we should be able to filter for the flag in the > /admin Easy. > (In reply to comment #7) > > The UI is there, but it'll need to be updated with a more descriptive label and > > explanation. > > This should be on the front end, I can't see it there: > http://awesomescreenshot.com/03bajto01 That document has localizations, so in the current implementation, the checkbox is hidden (in the current implementation, making a localized document non-localizable is not allowed). Check any new or unlocalized document.
Reporter | ||
Comment 11•13 years ago
|
||
oh, okay, so in the future implementation it would show up on all documents, right?
Updated•13 years ago
|
Whiteboard: see comment 5
Target Milestone: 2011Q2 → 2.8.1
Assignee | ||
Updated•13 years ago
|
Assignee: nobody → erik
Assignee | ||
Comment 12•13 years ago
|
||
Ran into some interesting consequences while implementing: 1. Suddenly, a very visited translation will drop off the board because somebody writes a draft of the original that they aren't ready to have translated yet. Similarly, the % Translated numbers in the Overview readout get a bit interesting to calculate. (My favorite approach so far is to treat any document with an existing translation as if it were "ready for translation", for the purposes of all l10n dashes.) 2. Somebody won't be able to (short of editing the URL) translate a perfectly good older version of an article if it has a just-testing, unlocalizable revision now. I'm going to let those percolate in my head overnight.
Comment 13•13 years ago
|
||
Oh here's an additional problem I thought of — with the new release cycle we'll need to mark an article as ready for localization and then turn around and start revising it for the next version of Firefox while localizers are still working on the previous version. That wasn't originally envisioned when we thought of this but it'll be the new reality soon.
Updated•13 years ago
|
Target Milestone: 2.8.1 → 2.8.2
Assignee | ||
Comment 14•13 years ago
|
||
The results of a call with me, Kadir, and Michael: Make *revisions*, not documents, ready-for-localization. Add a dashboard that shows the ones that have their latest revision in not-ready status. On at least the top-20 dashboard, indicate which articles have not-ready revisions so localizers can make an informed judgment whether to spend time on them. For l10n dashboards metric purposes, treat articles just as if the not-ready revisions don't exist.
Assignee | ||
Comment 15•13 years ago
|
||
Moving this to next week, since we just figured out what it should look like.
Target Milestone: 2.8.2 → 2.8.3
Comment 16•13 years ago
|
||
We can't take this for tomorrow at this point => 2.8.4.
Target Milestone: 2.8.3 → 2.8.4
Updated•13 years ago
|
Whiteboard: see comment 5
Assignee | ||
Updated•13 years ago
|
Target Milestone: 2.8.4 → 2011Q2
Assignee | ||
Comment 17•13 years ago
|
||
Let's see if amazing things happen and I can do this in one day.
Target Milestone: 2011Q2 → 2011-06-07
Updated•13 years ago
|
Priority: -- → P1
Target Milestone: 2011-06-07 → 2011-06-14
Comment 18•13 years ago
|
||
Looks like this didn't make 2011-06-07. Would really love it if this could make 2011-06-14. Thanks.
Assignee | ||
Comment 19•13 years ago
|
||
It's now my first priority!
Assignee | ||
Comment 20•13 years ago
|
||
Do we want to change the behavior of the "hey, a new article revision in locale X was approved!" email notification, perhaps including in it an indication of whether the revision is ready for localization?
Comment 21•13 years ago
|
||
I think this is the current message (at least this is what I see in English all the time): Subject: [[Name of Article]] (en-US) has a new approved revision A new revision has been approved for the document [[Name of Article]]. To view the updated document, click the following link, or paste it into your browser's location bar: [[Link to Article]] Maybe we can use something like this: Subject: [[Name of Article]] (en-US) is ready for localization A revision of [[Name of Article]] has been approved for localization. To view the updated document, click the following link, or paste it into your browser's location bar: [[Link to Article]] Now that I think about it, I'm not quite sure how this feature will work logistically. I'm thinking marking a revision as ready for l10n would be separate from approving or rejecting a revision. How will this work for localizers? Will they just go to an article, click edit and the English version on the left will be the ready for l10n revision?
Assignee | ||
Comment 22•13 years ago
|
||
What I had in mind was to keep revisions immutable. When it's time to mark one as ready for localization, what you actually do is to make a new revision and tick the "Ready for localization" box on the Edit page. Consequently, we can harness the on-submit or on-approve emails to notify folks of localization readiness with a simple wording change if we like. Do we like?
Comment 23•13 years ago
|
||
For the record, I support Erik's plan in comment 22.
Comment 24•13 years ago
|
||
Ok that works.
Assignee | ||
Comment 25•13 years ago
|
||
When somebody hits the Translate tab on an article, should they be given the current English revision to base their work on or the newest ready-for-l10n revision?
Comment 26•13 years ago
|
||
I'd like to hear from Kadir on this (he's out today) but I'm thinking they should get the newest ready for l10n. It's possible that if there are newer revisions we might end up with a new ready for l10n revision soon after but it's not a guarantee. If they translate just the latest revision it's a guarantee that there will be either a new ready for l10n version or we'll roll back to the previous one.
Reporter | ||
Comment 27•13 years ago
|
||
Yes, what Michael says. Also, no localizer messages should go out for revisions that are approved but are not marked as ready for localization. Once those articles are marked as "ready for L10n" localizers should be informed.
Assignee | ||
Comment 28•13 years ago
|
||
Thanks, Kadir!
Assignee | ||
Comment 29•13 years ago
|
||
Hmm. Kadir, I'm with you in spirit on the notify-only-when-ready mails, but there's a tricky bit: right now, people are subscribed to simply "approvals in a locale". If we change the meaning of that to "ready approvals in a locale", the effect of approvals of non-English revisions won't change (which is good), but approvals of English articles will be sent only for "ready" ones. This sounds good on its face, but, if I surmise correctly, there are 2 audiences for English notifications: native English speakers who, for some reason, want to know when English revisions are approved; and localizers who want to know when material is available to translate. Does the former group exist, and, if so does it matter if they are notified of only "ready" articles? There are lots of alternatives here, but I'll leave it at one question to start. Cheers!
Comment 30•13 years ago
|
||
There are people who want to know when each English revision is approved - they're the people who work on the English KB. They're the ones tracking changes between ready for 110n revisions so they want to know about each approval. Localizers are a much bigger group that don't care about each revision and only want to know when the article is ready for them to work on it. FWIW, there is a little bit of overlap between these two groups.
Reporter | ||
Comment 31•13 years ago
|
||
Hmm, good point indeed. We do have a group that contributes to English KB articles. I see two ways to solve this: 1) Put a disclaimer on top of notification emails, if the articles is approved but not L10n ready yet. Localizers getting those mails can than quickly discard them, but everyone else is still informed about ongoing changes to the KB. Likewise L10n ready mails would go out to everyone and English KB contributors would ignore them. 2) Tie the notification emails to the localization dashboard. Have a button on the l10n dashboard that says something like "subscribe to get emails when English articles are ready to be localized." Those E-Mails would then be in sync with the l10n dashboard, which will display articles based on whether they are ready to be localized. I do like version 2) much more, but if that takes too long to implement to make the next release, let's go with 1) as the stop-gap solution. How does that sound to you guys?
Comment 32•13 years ago
|
||
(In reply to comment #30) > They're the ones tracking > changes between ready for 110n revisions Also articles that are never intended for L10n and so *never* marked "ready."
Assignee | ||
Comment 33•13 years ago
|
||
Landed on master: http://github.com/jsocol/kitsune/commit/c4356c2 Landing on next is to come.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 34•13 years ago
|
||
Since this is such a sweeping change and since I'll be out Monday and Tuesday, it would be too risky to land this on such short notice. Pushing to 6/21.
Target Milestone: 2011-06-14 → 2011-06-21
Assignee | ||
Comment 35•13 years ago
|
||
Okay, change of plans: this will go out Thursday 6/16 if testing goes well.
Updated•13 years ago
|
Whiteboard: [2011-06-16]
Comment 36•13 years ago
|
||
Verified check-box works correctly with the localization dashboard with new articles and article edits.
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•