Closed Bug 775520 Opened 7 years ago Closed 6 years ago

A localized article should have the same breadcrumbs as the article it's based on

Categories

(developer.mozilla.org :: Localization, defect, P1)

defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: FredB, Unassigned)

References

Details

(Whiteboard: [localization])

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20100101 Firefox/14.0.1
Build ID: 20120713134347

Steps to reproduce:

I browsed https://developer-new.mozilla.org/fr/docs/Mozilla/Boot_to_Gecko and it's english and portuguese equivalents https://developer-new.mozilla.org/en-US/docs/Mozilla/Boot_to_Gecko https://developer-new.mozilla.org/pt-PT/docs/Mozilla/Boot_to_Gecko


Actual results:

I saw three different breadcrumbs on three equivalent pages. The most concerning case is on the fr page, which has basically no breadcrumb.


Expected results:

On every page I should get a similar breadcrumb structure.
Confirmed. Thank you for reporting this, Frédéric. I will be sure we look at it.
Status: UNCONFIRMED → NEW
Ever confirmed: true
It looks like all pages created during the Porto Alegre translation sprint suffer from this.

https://developer-new.mozilla.org/pt-BR/docs/CSS
https://developer-new.mozilla.org/pt-BR/docs/HTML
Component: Docs Platform → Localization
Priority: -- → P1
Whiteboard: s=2012-08-22
Whiteboard: s=2012-08-22 → s=2012-08-22 p=3
Whiteboard: s=2012-08-22 p=3 → s=2012-08-22 p=3 s=2012-08-29
Summary: Inconsistent breadcrumbs among translated pages → A localized article should have the same breadcrumbs as the article it's based on
Whiteboard: s=2012-08-22 p=3 s=2012-08-29 → p=3
Depends on: 788823
Jean-Yves: We were wondering if you had any thoughts on priority. Would our SEO improve if the Breadcrumbs show up correctly in other locales?
No, not as long as the breadcrumb is not used by <title>.
Version: Kuma → unspecified
Depends on: 792417
Depends on: 792418
Whiteboard: p=3
Should *always* have the same breadcrumbs, or *start* with the same breadcrumbs by default?

If *always*, then breadcrumbs for all non-en-US locales are determined by and locked to en-US locale. If *start* with, then non-en-US locales may edit and change their own breadcrumb structures.

Lots of discussion in bug 788823, and this may be addressed by bug 792418
Also, there's bug 792417 for assigning sensible topic parents to pages without them.
Depends on: 791276
Do we need to complete bug 791276 as part of this, or can we break that off as a separate feature for later?

Anyway, Les explained the state of the state in IRC today. There are basically three problems.

1. New translations get no parent (this will be fixed with bug 792418)
2. That has caused recent translations to have not parent (this will be fixed with bug 792417)
3. Some translations have parents already but don't match en-US, possibly intentionally (we are going to leave this as-is for now, since the differences may be intentional)
No longer depends on: 791276
Whiteboard: p=3
Whiteboard: p=3 → [tracker] p=3
Depends on: 797571
Whiteboard: [tracker] p=3 → [localization]
Need to fill in requirements here - what's the ongoing issue? bug 792417 and bug 792418 are both fixed.

Do we want to do anything else? The breadcrumbs on:

https://developer.mozilla.org/pt-BR/docs/CSS

don't match the breadcrumbs on its English source:

https://developer.mozilla.org/en-US/docs/Web/CSS

because the English CSS article was moved to Web/CSS. But surely we don't want to try to automatically move translations around while we move English docs around?! We should let pt-BR doc writers move it to Web/CSS?
Chipping in as the original reporter (with vague memory of the original reason).

It seems that the breadcrumbs have been fixed. And we certainly don't want to auto-move content as you said.

Seems like all that was to be fixed has been, or just that this bug report is totally irrelevant. Though, I'm not sure how to set the status for this bug.
I'll mark it resolved:fixed. If we need to re-open we can.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.