Closed Bug 900961 Opened 12 years ago Closed 12 years ago

French article shows English breadcrumbs

Categories

(developer.mozilla.org Graveyard :: General, defect)

Product:
developer.mozilla.org Graveyard
Component:
General
Platform:
All
Other
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: FredB, Assigned: groovecoder)

References

Details

(Whiteboard: [specification][type:bug])

What did you do? ================ 1. Once upon a time, there was bug 876738 2. The pages seemed to remain still 3. But the young contributor from far far away recently discovered that some pages moved in a weird weird country. What happened? ============== The pages I give later have a borked breadcrumb showing both en-US string with a valid URL. The URL points to the docs/Web/CSS that was the tentative destination. What should have happened? ========================== In the first time, the whole tree should have moved without batting an eyelid. Then, if the page move would have been successful, the content would be accessible as docs/Web/CSS/ and no redirection should have happened. Is there anything else we should know? ====================================== Pages affected: https://developer.mozilla.org/fr/docs/CSS/font-size https://developer.mozilla.org/fr/docs/CSS/outline And maybe more to come.
Summary: Bogus CSS French docs moved → French article shows English breadcrumbs
And a new major one (which happen after an edit once again): https://developer.mozilla.org/fr/docs/CSS
Hmm ... can you explain a little more about this? When I look at these, all the breadcrumb links are /fr/ links? Or do you mean the text of the breadcrumbs?
The links are /fr/ indeed, yet the text is in English, and matches the English structure. The breadcrumbs shows that the /fr/docs/CSS/word-wrap is a sub-page of /fr/docs/Web/CSS/word-**** which is wrong. Trying to avoid redirect by adding ?redirect=no on /fr/docs/Web/CSS/word-wrap doesn't work. (Ends up as a HTTP 302 while after a move it would throw a 301) Might these be remnants of bug 876738 ?
Have these already been fixed manually? Not seeing the issue on the word-wrap page, or random selection of other pages linked above.
Flags: needinfo?(fredbourgeon)
Those pages haven't been fixed manually AFAIK. By that I assume you mean recreate the link between children and translation parent. Well, in that case no, or at least not all of those pages (some might though).
Flags: needinfo?(fredbourgeon)
I am still seeing the issue on the word-wrap page -- the content of the article is French, but the Breadcrumb text is English.
Flags: needinfo?(mozbugs.retornam)
Blocks: 902599
Flags: needinfo?(stephen.donner)
This is still not fixed I'm still seeing French articles with English breadcrumbs on prod. Can dev or stage get DB dumps from prod to make testing on dev or stage with locales other than English easier.
Flags: needinfo?(stephen.donner)
Flags: needinfo?(mozbugs.retornam)
I manually fixed the one listed here as I needed them to be correct for some statistic. But I noticed that new ones appeared today, without involving a page move, only by editing translated articles.
Commits pushed to master at https://github.com/mozilla/kuma https://github.com/mozilla/kuma/commit/c55b5e05357552f284125eae9a332e5572217f80 Bug 900961: Provide a way to (sometimes) repair bad breadcrumbs. This doesn't prevent the problem from recurring; doing that will probably require digging down into the page-move code and figuring out what exactly went wrong that broke the breadcrumbs in the first place. This also will not fix every broken document; some are too bad for this sort of fix to work on, and will have to be repaired manually. For ease of UI, a view is provided, accessible to superusers, which can be linked from a document detail page to perform the repair. https://github.com/mozilla/kuma/commit/9a8a8ee3783b59a06327a803d94c6d2a929418f6 Merge pull request #1270 from ubernostrum/breadcrumbs-900961 Bug 900961: Provide a way to (sometimes) repair bad breadcrumbs.
Can anyone confirm that bug 916731 (https://developer.mozilla.org/fr/docs/Mozilla/Firefox_pour_Android) is the same issue?
Flags: needinfo?
Also, did we intentionally choose not to close this bug with the commit message from comment 11? Is there still more work to do?
Flags: needinfo? → needinfo?(jbennett)
(In reply to John Karahalis [:openjck] from comment #13) > Can anyone confirm that bug 916731 > (https://developer.mozilla.org/fr/docs/Mozilla/Firefox_pour_Android) is the > same issue? From what I can see, breadcrumbs on this page are ok but someone may have fixed them. Additional input would be appreciated. IIRC, what has landed is a way to fix the breadcrumbs on the spot, but does not fix the issue that borks them. The latter fix which is part of a larger feature set, but James can tell more about it for sure.
Each edition of a translated document corrupt the database. Each morning I'm manually fixing those of HTML, SVG, CSS, JavaScript, MathML and Reference to prevent nasty things to happen if somebody move anything, and also to have correct information about where we stand in our work.
Whoa, *every* edit corrupts the breadcrumbs again? Is that consistent behavior? What are the steps to reproduce it?
Yes, it is consistent. Step to reproduce 1. Go to a page in French, like https://developer.mozilla.org/fr/docs/CSS/padding-bottom (which is not corrupted now) 2. Edit 3. Save Corrupted. The Parent Topic is set to the Parent value. By manually fixing it, the problem goes away of course.
(In reply to John Karahalis [:openjck] from comment #14) > Also, did we intentionally choose not to close this bug with the commit > message from comment 11? Is there still more work to do? The commit provided a somewhat-simpler way to repair the problem in the common case, but did not diagnose what causes the problem or how to prevent it from recurring. So this bug, or some sort of bug for that part of it, should remain open.
Flags: needinfo?(jbennett)
Assignee: nobody → lcrouch
Assignee: lcrouch → jbennett
I dug into this a bit before CfA Summit, but kicked it away when I left. :ubernostrum - any progress here? What do I need to know to dive back into it?
I'm at Heisenbug status at the moment; been steeping through the view code and trying to catch where it happens, and failing. As I think we talked about a while back, though, it may be a good idea to just go ahead and split up the translation view into multiple separate (logical, if not public-facing-URL-physical) views, since the overall complexity of it is probably a culprit in masking the bug. Want me to take a stab at that?
It's no longer heisenbug for me - I can reproduce it locally. So I'm going to jump into this so :ubernostrum can stay on page-move.
Assignee: jbennett → lcrouch
Woohoo!
Commits pushed to master at https://github.com/mozilla/kuma https://github.com/mozilla/kuma/commit/79954e5c243980c876e3fcddcea4cc1e1c4faee3 fix bug 900961 - don't update topical parent https://github.com/mozilla/kuma/commit/ef5bf70e0f21da756b3376650f2c8bf72307ff2c Merge pull request #1538 from groovecoder/translation-breadcrumbs-900961 fix bug 900961 - don't update topical parent
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Product: developer.mozilla.org → developer.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.