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?
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.
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.
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.
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
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.
Bug 477543 filed.
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.