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)
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.
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.
(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.
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.
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.
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.
The UI is there, but it'll need to be updated with a more descriptive label and explanation.
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.
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
(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.
oh, okay, so in the future implementation it would show up on all documents, right?
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.
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.
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.
Moving this to next week, since we just figured out what it should look like.
We can't take this for tomorrow at this point => 2.8.4.
Let's see if amazing things happen and I can do this in one day.
Looks like this didn't make 2011-06-07. Would really love it if this could make 2011-06-14. Thanks.
It's now my first priority!
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?
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?
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?
For the record, I support Erik's plan in comment 22.
Ok that works.
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?
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.
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.
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!
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.
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?
(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."
Landed on master: http://github.com/jsocol/kitsune/commit/c4356c2 Landing on next is to come.
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.
Okay, change of plans: this will go out Thursday 6/16 if testing goes well.
Verified check-box works correctly with the localization dashboard with new articles and article edits.