Closed Bug 487598 Opened 16 years ago Closed 16 years ago

Localized articles should inherit en-us page categories

Categories

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

Product:
support.mozilla.org
Component:
Knowledge Base Software
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: underpass_bugzilla, Assigned: paulc)

References

Details

(Whiteboard: tiki_bug, tiki_upstreamed)

Attachments

(1 file)

patch, v1
10.38 KB, patch
laura
: review+
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (X11; U; Linux i686; it; rv:1.9.0.8) Gecko/2009032608 Firefox/3.0.8 Build Identifier: In my opinion there is no reason why localized page should have their own category option. For example, only by a matter of chance I found that these two pages: https://support.mozilla.com/it/kb/Recovering+important+data+from+an+old+profile?bl=n https://support.mozilla.com/it/kb/Recuperare+dati+personali+da+un+vecchio+profilo?bl=n have different categories ("This is a support/troubleshooting article" for the former, "This is a help article" for the latter) If we consider an en-us page as the *master* for any possible localization, every translated page should conform to the categories of the en-us one. In this way, when a page is changed in category (or a new category is added for a page), there would be no need for the locale teams to change their version accordingly. This is very important, for example, when a page is adapted for a new program version (as it is happening for Firefox 3.5). Maybe there are reason I can't see. In this case, could you please explain? Thanks :-) Reproducible: Always
What about cases where the en-US version has been updated for a new version of Firefox, but the translation has not been updated yet? It's also worth mentioning that bug 476789 ["Translate this page" should copy additional category info] was pushed in February, whereas <https://support.mozilla.com/it/kb/Recuperare+dati+personali+da+un+vecchio+profilo?bl=n> was created in July.
(In reply to comment #1) > What about cases where the en-US version has been updated for a new version of > Firefox, but the translation has not been updated yet? Maybe in this case there is still the warning "This page needs to be updated". There is also a good notification system for the translators to keep track of what change is needed.
Sorry for the late reply. Right now, I'm liking this idea, but we have one hurdle: If we update an article for 3.5, it should mark translations as out of date, because 3.5 has not been released. Maybe we can postpone this until after 3.5 is released? Any other ideas?
Status: UNCONFIRMED → NEW
Ever confirmed: true
The idea of making sure that a _new_ translation inherits the categories as the existing en-US article makes a lot of sense to me. Is that what this bug is essentially about? However, automatically changing the categories of _existing_ translations when the en-US would be problematic, since, as Chris says, the translations may or may not be updated already.
Then maybe there should be two "families" of categories, one referring to the type of article ("This is a support/troubleshooting article" and "This is a help article") and another for the supported OS and version. I mean, it is unlikely that a single article is changed in its original purpose and, should it happen, this kind of category should be applied to all the translations regardless of the status of its update. The real problem, however, is how to manage the updating of the version category, since I think that - as I already said to you - going through the updating and approving the category change of 200 articles is a struggle I wish to avoid for version 4 ;-)
I don't foresee us having to change additional categories on articles after the the 3.5 update. If we implement this after most locales are updated for 3.5, we localizers don't have to make the superfluous edits. Bo also complained about the tediousness of having to edit so many articles, just to add it to the Firefox 3.5 category; so for the next major release, we can look at some other way of adding articles to a new category without having to edit the article.
Now that 3.5 is released, I think it's okay to implement this. Targeting to 1.3.
Target Milestone: --- → 1.3
So what are the expected results here? Creating new KB translation pre-fills those category checkboxes with the ones currently in the en-US version?
Assignee: nobody → paul.craciunoiu
Creating a new translation already pre-fills, so this bug is about: - picking up any changes to additional categories from the en-US article. - not making the additional categories editable on translations. Maybe they can be grayed out in the editor?
Define "additional categories"?
https://support.mozilla.com/tiki-browse_categories.php?locale=en-US&parentId=15&deep=off&type= :-) In other words, the categories that appear as checkboxes in on the right-hand side in the editor.
Okay, that's what I said in comment 8, except you want them to constantly stay in sync. So does this basically mean: * on edit of translated article, get checkbox-categories of en-US article * set those to the translated article * mark all checkboxes read only?
yes :-) In addition, if those checkboxes get checked/unchecked for the en-US article, that change is applied to all translations of the article.
If we go for this change, what if the English article was updated to support 3.5, but the translated article hasn't yet been updated? Will that be indicated somehow, e.g. with the "potentially outdated" flag? Will that happen automatically, and if not, how will we be able to keep track of which translations have been updated for 3.5 and which haven't (despite the fact that they inherited the 3.5 category)?
Right, I think that this occurence could trigger the "potentially outdated article" condition.
When updating articles for 3.5, contributors were instructed to use the "Alert translators" checkbox when article content was updated for 3.5. That way, localizers had a list of articles that needed to be translated in the l10n dashboard and we could keep track of which locales were updated for 3.5.
Proposed behavior (please review): * All existing translations are batch-updated to have the English version's categories (SQL patch?). If some have no English version, they are free to have any categories they wish. * When creating a new translation, the categories fields are marked disabled and pre-loaded with the values from the English version (this may add page load time) - concerns b/c of bug 480415 * When updating the English version, sync categories over all translations - again concerns b/c of bug 480415 Additionally, I have some questions about the process: * Detaching a translation is easy, can be done on tiki-edit_translation.php -- How about reattaching, is that possible? * Is it possible for a translation to start off with a non-English article, and then have an English translation added? Are we going to consider this case? There may be things I missed. Chris, David: you are more familiar with the features available for localizing articles. Any other concerns?
(In reply to comment #17) > Proposed behavior (please review): > * All existing translations are batch-updated to have the English version's > categories (SQL patch?). If some have no English version, they are free to have > any categories they wish. > * When creating a new translation, the categories fields are marked disabled > and pre-loaded with the values from the English version (this may add page load > time) - concerns b/c of bug 480415 > * When updating the English version, sync categories over all translations - > again concerns b/c of bug 480415 That all looks correct to me. I just want to make sure it is clear that we are talking about categories under "Additional categories" only. > Additionally, I have some questions about the process: > * Detaching a translation is easy, can be done on tiki-edit_translation.php -- > How about reattaching, is that possible? Yes. That is also part of tiki-edit_translation.php, at the bottom under "Add existing page as a translation of this page". When that happens, it should take on the additional categories of English article in the translation table. If it is an English article being added, then it will cause the reverse action (all articles in the translation table will inherit the additional categories of the newly added English article). > * Is it possible for a translation to start off with a non-English article, and > then have an English translation added? Are we going to consider this case? Yes, it is possible. I don't recall it happening, but it is technically possible. If that happens the additional categories are not inherited from any language and editable.
Thanks Chris, I think this concludes all possibilities. Patch soon (unless other stuff happens)
Marking blocked by time-outs. It would be good to (at least try to) improve editpage again before we add more stuff to it.
Depends on: 480415
Chris: does this bug apply to non-KB articles?
yes
Attached patch patch, v1 — — Splinter Review
This patch does the following: * Disables changing "Additional categories" when editing an article using the radio-buttons version of the editor (KB + staging articles most notably). The checkboxes are only disabled when editing NON-ENGLISH articles * Forces articles not in the above situation to inherit categories (HTC + Administration most notably). In other words, because for the other version of the editor we use a multiple select, I cannot enforce "read only" in the UI without javascript. We can discuss switching to checkboxes, or leave it for the editor redesign sometime in the future. * Adds a pref for turning inheritance on or off. With the pref OFF, everything should behave as before the patch. ("Non-English articles inherit...") * Adds a pref for choosing which categories should be inherited. This should be initialized to additional category ids: "13,14,17,18,19,25", in tiki-admin.php?locale=en-US&page=category * Saving an English article syncs categories for all translations (articles listed for the respective article under tiki-edit_translation.php?locale=en-US&page=<pageName>) * Approving a staging version of an English article syncs categories for all translations TODO for this bug to take full effect: * Discuss if any UI enforcement for the multiple select (see bullet 1 above) * Sync current staging articles to their English version categories. This is because the patch does not account for the case when approving a non-English staging article overwrites the categories for the live version. The staging article will then overwrite the existing article's categories, and hence cause articles to be out of sync. A solution to this is to re-save the English version, but this shouldn't be done for all articles. All in all, we will still need to fix bug 496936, otherwise we would have to put in additional code that would only be really used for the sync... It's a pretty complex patch, so it will need good QA -- hence I included a pref to disable the whole thing just in case it turns evil :)
Attachment #391776 - Flags: review?(smirkingsisyphus)
Attachment #391776 - Flags: review?(laura)
Attachment #391776 - Flags: review?(laura) → review+
Attachment #391776 - Flags: review?(smirkingsisyphus)
r48736 / r48737 This needs extensive QA. I enabled the pref on stage: https://support-stage.mozilla.org/tiki-admin.php?locale=en-US&page=category
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
The recent sync from prod must have reset those prefs. Can you post which prefs need to be set and to what?
Do we need run a script to make all current articles inherit en-US categories? In <https://support-stage.mozilla.org/tiki-editpage.php?locale=en-US&page=*Using+the+Flash+plugin+with+Firefox>, the "Firefox 3.5" category is check marked. In the French version <https://support-stage.mozilla.org/tiki-editpage.php?locale=en-US&page=*Flash+%28fr%29>, "Firefox 3.5" is not check marked and grayed out. Also, could you be more specific about which pref it is?
Enable/disable pref: --- Non-English articles inherit additional categories (set list below): --- List of categories to inherit: --- Non-English articles inherit these category IDs (comma delimited) --- As per my comment 23 above, articles are NOT synced. We need to either resave them ALL after enabling the pref, or run a script that does it.
Okay, thanks. If it happens whenever we edit the en-US article, I don't think we need to run a script.
You should try it out just to make sure ;)
There is still one problem: it's not clear from the UI that the categories are disabled in non en-US languages. The checkboxes _looks_ the same, but they can't be checked, which makes it feel like the form is broken. We must at the very least gray the checkboxes out, but might want to think of adding a label explaining that they are inherited from the en-US article. For the sake of 1.3 sanity, I'm fine with only the former for now.
They are greyed out on my end...
When I tested this yesterday I didn't see a difference - was CSS updated to make them gray? In that case maybe my Firefox was reading the CSS from cache? I'll try again when support-stage.mozilla.org decides to wake up again...
The text isn't gray, only the checkboxes are. If you want the text gray, David, can you file a separate bug please?
(In reply to comment #30) > You should try it out just to make sure ;) I just tested it, and it appeared not to work. "Firefox 3.5" is not check marked in <https://support-stage.mozilla.org/tiki-editpage.php?locale=en-US&page=*Flash+%28fr%29>. But when I switch it from editing the staging copy to directly editing the KB version "Firefox 3.5" /is/ check marked. <https://support-stage.mozilla.org/tiki-editpage.php?locale=en-US&page=Flash+%28fr%29> So it appears that staging copies of translations are inheriting additional categories.
I'm a bit confused about what works vs not?
Reopening per comment 35; I don't really understand how to test this either.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
To test this, 1. Go to <https://support-stage.mozilla.org/en-US/kb/Using+the+Flash+plugin+with+Firefox>. 2. In a separate tab, go to <https://support-stage.mozilla.org/en-US/kb/Flash+%28fr%29?bl=n>, which is the French translation. 3. On each of the two articles, click on "Edit this page". 4. Compare the category checkboxes (if the same checkboxes are marked, bug is fixed). Complications: - If the checkboxes are out of sync, editing the English article should re-sync it. - When you click on "Edit this page", it opens the *staging copy* in the editor, not the KB article. * What I found in comment 35, is that category info on the *staging copy of the translation* is not in sync with the KB version of the translation. IMO, fixing that can be pushed to a future release.
(In reply to comment #38) > * What I found in comment 35, is that category info on the *staging copy of > the translation* is not in sync with the KB version of the translation. IMO, > fixing that can be pushed to a future release. Given the load for 1.3 and 1.4, why don't we make this a feature for 1.5 or Q4? It's probably not very hard, but given the problems we have and the timeline, I'd rather not risk it... Does that sound acceptable?
Are you saying to back out the current code?
No, I'm saying to fix that part later.
Great! We're in complete agreement.
Blocks: 514210
Filed bug 514210 as a spin off.
Status: REOPENED → RESOLVED
Closed: 16 years ago → 16 years ago
Resolution: --- → FIXED
Component: Knowledge Base Articles → Knowledge Base Software
QA Contact: kb-articles → kb-software
Thanks -- verified per comment 39 and comment 42.
Status: RESOLVED → VERIFIED
Whiteboard: tiki_bug
I like this one. Great idea on the list of categories that can be inherited. However, it remains a bit English-centric. Would there be a problem with making all category changes anywhere propagate to the other pages? Then possibly have an option to prevent changing categories in those 'foreign' languages?
Whiteboard: tiki_bug → tiki_bug, tiki_discuss
For SUMO, English pages are the "originals" and we want non-English translations to inherit their categories. I believe we want changes to go only one way: English => other languages (Chris, feel free to correct me if that's not the case). It sounds like making all translations stay in sync is what we want, with the option of not syncing when: <<an English version exists AND the current page being updated is not in English>>, right?
It seems like if we want to generalize this, there are two main scenarios for a wiki: A) A main language that most (or all) articles originate from. This is the case with SUMO, and our main language is English. B) All languages are equal, like Wikipedia. This is the case LPH is talking about (I think) in comment 45. LPH: is it possible to make both work? We (SUMO) are only interested in A) but it seems like you also want B). Thanks!
Implementation is different as it's built on newer code. category_i18n_sync and category_i18n_synced are used, both changeable from category admin.
Whiteboard: tiki_bug, tiki_discuss → tiki_bug, tiki_upstreamed
(In reply to comment #6) > > Bo also complained about the tediousness of having to edit so many articles, > just to add it to the Firefox 3.5 category; so for the next major release, we > can look at some other way of adding articles to a new category without having > to edit the article. From tiki-admin_categories.php, you can mass add pages to a given category M ;-)
(In reply to comment #49) Is this new? From my recollection, tiki-admin_categories was so incredibly non-performant that we couldn't mass-do anything.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: