Closed Bug 476789 Opened 15 years ago Closed 15 years ago

"Translate this page" should copy additional category info

Categories

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

task
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: cilias, Assigned: paulc)

Details

(Whiteboard: tiki_bug, tiki_upstreamed)

When using the "Translate this page" function, it currently does not place the translation in the same categories as the original article. For instance, if the original article is in the help, Firefox3.0, and Firefox 3.1 categories, those boxes are not check marked when creating a translation.
Taking this. I'm not sure if it could still make it in 0.8.2, when is the freeze date again?
Assignee: nobody → paul.craciunoiu
Target Milestone: --- → 0.8.3
There will be no 0.8.3.
From today's meeting: Laura wanted to combine 0.8.2 and 0.9, but we really need bug 474842 pushed ASAP, so 0.8.2 is whatever was committed today (for push on Thursday). The rest go to 0.9.

One thing I should mention about this bug that might be a problem is that if someone creates a translation of a KB article, that translation should be created in the staging area. However, if someone creates a translation of an article in the admin or how to contribute category, the translation should be created in the same category.
Target Milestone: 0.8.3 → 0.9
r21988 / r21989
Modified a few lines in several files. Tested locally, both radio buttons and checkboxes are transmitted from article.

As per #c2: If article is in KB, translation defaults to staging. Otherwise radio button option stays unchanged.

Since staging doesn't seem to pick up the changes, as per bug 476759, I'm not sure if the files are updated to reflect changes, so far it seems no.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Target Milestone: 0.9 → 0.8.2
Chris, would you mind helping out with the verification of this, so I don't screw something up/miss something?
Before this, whenever I translated a page, it would be put to the Staging Area category by default. But now, no main category is selected! Is that fine?

You can take a look at this screenshot:
http://img267.imageshack.us/img267/8121/bugxg2.png
NGUYỄN: Can you tell me the URL that starts with tiki-edit_translation.php?... that leads you to that page?

For example:
https://support-stage.mozilla.org/tiki-edit_translation.php?locale=en-US&page=Clearing+Location+bar+history

When I put something in there, and click on "Create translation", the Staging Area category is selected.
I tried clicking on the "translate this page" link of some random pages, sometimes this bug occurred, sometimes it didn't. But it seems to be fine now. Maybe some cache issues?

Has the new change been pushed to the live site yet? If yes, then this bug occurred on every pages.
(In reply to comment #7)
> I tried clicking on the "translate this page" link of some random pages,
> sometimes this bug occurred, sometimes it didn't. But it seems to be fine now.
> Maybe some cache issues?
> 
> Has the new change been pushed to the live site yet? If yes, then this bug
> occurred on every pages.

Yes, 0.8.2 has shipped.  Are you saying it's completely fixed now?  If so, I can mark it as verified.  Thanks!
Err, no, I meant that the bug is only fixed on support-stage.mozilla.org, but not on the support.mozilla.com site.

For ex, I followed this link:
https://support.mozilla.com/tiki-edit_translation.php?locale=en-US&page=Clearing+Location+bar+history
typed a title and clicked "Create translation", no main category is selected.
NGUYỄN, I can't reproduce this... I get the same results as on staging and my local host.
Stephen, can you help verify? Maybe try using what OS/FF version NGUYỄN is using.
I see "staging" checked when I try to reproduce this; NGUYEN, what browser version/OS are you using?
I'm using FF 3.0.6. I've made some tests on both Windows XP SP3 and Ubuntu 8.04 with two accounts. On XP SP3, I also tested on vi-FF 3.1 and IE7. And the bug is still there.

Here are the screenshots of my test account preferences and the bug on IE 7 and Shiretoko:
http://img8.imageshack.us/img8/1307/bugieml1.png
http://img527.imageshack.us/img527/1236/bugshiretokoyr0.png

Here is the screenshot of the bug on Ubuntu. You may also want to notice the red highlight. (I didn't enable interactive translation).
http://img8.imageshack.us/img8/3776/bugubuntulq2.png
Does it happen when you disable AdBlock Plus (try disabling all your add-ons?)
The bug is still there even without any addons enabled.
http://img17.imageshack.us/img17/3763/bugshiretokonoaddonsex6.png
I'm not all denying the screenshots; I definitely see a bug in your screenshot, sorry.  I just can't seem to reproduce thus far, with multiple locales.

I've set the "qawanted" keyword so that other folks can try to reproduce the problem so we can assess a fix.
Keywords: qawanted
This looks fixed with an admin account, but not with a non-admin account.
(In reply to comment #16)
> This looks fixed with an admin account, but not with a non-admin account.

Great troubleshooting; I can confirm that using:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.1b3pre) Gecko/20090206 Shiretoko/3.1b3pre on:

http://support.mozilla.com/tiki-editpage.php?locale=en-US
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Don't know, maybe the above should've been a separate bug with a solution to set that radio button and its text to "disabled", rather than empty, for non-Admin accounts, or maybe Paul will gracefully fix that here.

But if it's fixed on staging, then shouldn't it just need a push?  It was fixed two days ago.
I thought you always tested with every kinds of accounts. :) (I have created 4
accounts until now :p)
Yeah, let's file a separate bug. This one is already pushed to prod; so changing the target milestone might confuse things.
Status: REOPENED → RESOLVED
Closed: 15 years ago15 years ago
Keywords: qawanted
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
Bug 477543 filed.
Whiteboard: tiki_bug
Upstreamed without the part where categories were hardcoded.

The category selector is now visible when creating the translation. Can be hidden through styling if desired.
Whiteboard: tiki_bug → tiki_bug, tiki_upstreamed
You need to log in before you can comment on or make changes to this bug.