788823 - Research: How should we ensure breadcrumbs do not change between localizations?

Status: RESOLVED FIXED

(developer.mozilla.org Graveyard :: Wiki pages, defect)

Description

[John Karahalis [:openjck]]

There are many different ways we could implement this, each with some drawbacks. Lets discuss some possibilities here and try to reach a decision.

I will open a new bug about implementation after we reach a decision.

Comment 1

[Les Orchard [:lorchard]]

Could you explain more about what you mean? How *do* breadcumbs change between localizations?

Comment 2

[John Karahalis [:openjck]]

Here's one example. The breadcrumbs are different in these three localizations of the same article.

* https://developer-new.mozilla.org/fr/docs/Mozilla/Boot_to_Gecko
* https://developer-new.mozilla.org/en-US/docs/Mozilla/Boot_to_Gecko
* https://developer-new.mozilla.org/pt-PT/docs/Mozilla/Boot_to_Gecko

I think Luke mentioned that this is because an article does not necessarily have the same parents in other localizations. We couldn't decide on how we should fix this (fake the breadcrumbs? copy parent and grandparent articles over? something else?) so we opened this bug about discussing some different possibilities.

Comment 3

[Les Orchard [:lorchard]]

Maybe the title's confusing me... Breadcrumbs aren't actively *changed*, right? (ie. no one's going around modifying them)

It's just that there isn't an exact correspondence between the topic hierarchy chain for a given page and the translations at each step in the chain.

Not sure if this counts as performing the research task, but...

So, maybe we want something like this:

 en    / docs / CSS / CSS_Reference
 de    / docs / CSS / CSS_Referenz
 pt-BR / docs / CSS / Refência_CSS

Where, in the above, horizontal paths are topic hierarchy and translations match up vertically.

But, currently instead we have this:

 en    / docs / CSS / CSS_Reference
 de    / docs /       CSS_Referenz
 pt-BR / docs /       CSS_Reference

From what I can tell, even though there are de/CSS and pt-BR/CSS translations, they are not set as the topic parents of the respective translations of CSS_Reference.

I don't think our translation system accounts for topic hierarchy at all, so breadcrumbs probably just aren't set for new translations at all. Any existing topic hierarchy relationships were probably established as a part of migration.

So, here's my first suggestion for a task:

* Attempt to mirror the topic hierarchy across locales during translation: When a new document is created as a translation based-on an existing document, find the topic parent of the based-on document. If a translation of the based-on-parent exists in the locale of the new document, use that as the topic parent for the new document.

This raises an issue: What happens when there *is* no corresponding translation for the based-on topic parent? 

That is, I translate CSS_Reference (en-US) into Català (ca) - but no one translated CSS first (ie. the en-US topic parent for CSS_Reference). There's a hole in the hierarchy, and we don't have anything to point to as a topic parent from CSS_Reference in Català.

Comment 4

[Les Orchard [:lorchard]]

Some options off the top of my head:

* We could refuse to allow translation of documents before their corresponding topic parents. This feels like an easier implementation, but sounds like a contribution roadblock.

* If a translated topic parent doesn't exist, just create it from the based-on locale content to fill in the gap. Do this in the background, and don't interrupt the user's translation of the child document. Hopefully someone will come by and translate that parent, someday. (Maybe needs-translation feed will help here?)

Comment 5

[Les Orchard [:lorchard]]

Another option:

* "Phantom" topic parents. That is, just pretend that the based-on topic parent is the breadcrumb for the translation until the topic parent is translated. This could save us from the creation of untranslated content, but feels like it could be possibly error-prone and convoluted to implement. Not really a fan of this option, but wanted to throw it out there.

Comment 6

[Les Orchard [:lorchard]]

Oh, but as for "repairing" the document structure we already have... If we treat the en-US translation / topic matrix as authoritative, we could do something like this:

* walk through the en-US topic structure

* iterate through translations at each point in the topic structure

* ensure each of translation has a topic parent, itself translated from the topic parent of the current en-US document. Do this either by finding an existing translation or generating a new one.

Comment 7

[Les Orchard [:lorchard]]

(In reply to John Karahalis [:openjck] from comment #2)
> Here's one example. The breadcrumbs are different in these three
> localizations of the same article.
> 
> * https://developer-new.mozilla.org/fr/docs/Mozilla/Boot_to_Gecko
> * https://developer-new.mozilla.org/en-US/docs/Mozilla/Boot_to_Gecko
> * https://developer-new.mozilla.org/pt-PT/docs/Mozilla/Boot_to_Gecko
> 
> I think Luke mentioned that this is because an article does not necessarily
> have the same parents in other localizations. We couldn't decide on how we
> should fix this (fake the breadcrumbs? copy parent and grandparent articles
> over? something else?) so we opened this bug about discussing some different
> possibilities.

Hmm, these examples raise some more issues. It looks like this sequence of events happened:

* Boot_to_Gecko was created in en-US
    https://developer-new.mozilla.org/en-US/docs/Mozilla/Boot_to_Gecko

* Boot_to_Gecko was translated to pt-PT (maybe pre-Kuma? has a topic parent)
    https://developer-new.mozilla.org/pt-PT/docs/Mozilla/Boot_to_Gecko

* Boot_to_Gecko was translated to fr (post Kuma? no topic parent at all)
    https://developer-new.mozilla.org/fr/docs/Mozilla/Boot_to_Gecko

* Boot_to_Gecko was renamed to Firefox_OS in en-US (redirect generated)
    https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS

* Boot_to_Gecko was renamed to Firefox_OS in fr (redirect generated)
    https://developer.mozilla.org/fr/docs/Mozilla/Firefox_OS

* pt-PT did not rename, so this still exists:
    https://developer.mozilla.org/pt-PT/docs/Mozilla/Boot_to_Gecko

* pt-BT instead created a new translation (no topic parent):
    https://developer.mozilla.org/pt-BR/docs/Mozilla/Firefox_OS

So, I'm seeing a few issues in the above:

* As mentioned before, creating a new translation in Kuma does not assign topic parents. (my guess in the fr locale and Firefox_OS in pt-br)

* Renaming a page in one locale has no effect on another locale, thus the case where pt-BR still has Boot_to_Gecko and Firefox_OS pages

I have suggestions for the first, but no idea what to do about moving a page in one locale and its effect (or non-effect) on another locale to keep the matrix in sync

Comment 8

[Les Orchard [:lorchard]]

One more thought: Do we really want to keep topic hierarchy in lock-step across locales? (ie. en-US defines the site structure, and other locales just provide translations with no control over their local doc structure?)

I guess the distinction to make here is to correct divergence from en-US topic structure where it's inadvertent (eg. from Kuma bugs), yet allow divergence where intentional (eg. a locale wants to restructure or simplify a part of the site).

Comment 9

[Les Orchard [:lorchard]]

Okay I lied, last thought:

If we absolutely, positively want the en-US topic hierarchy to be the consistent, authoritative nav structure for the site:

* nuke topic parents for all non-en-US pages
* when building the breadcrumb path for a fr page:
    * consult en-US translation parent, 
    * step back through en-US topic parents, 
    * look up fr translation for each topic parent, punt to en-US where missing.

That might make implementation simpler, leave contributors in non-en-US locales rather unhappy.

Comment 10

[Luke Crouch [:groovecoder]]

I generally dislike the idea of "phantom" docs - agree they're too error-prone. I like the approach of:

1. Repair translated docs' breadcrumbs by transplanting current en-US topical hierarchy to the other locales
2. When translating an article, use the source article's topical hierarchy to create the translation's topical hierarchy
2a. If source article's ancestors have translations, use those
2b. If source article's ancestors DO NOT have translations, create un-translated stubs and use those


Jean-Yves, From the comments above, we specifically need to know:

Do we want to keep breadcrumbs hierarchy in lock-step across locales? (ie. en-US defines the site structure, and other locales just provide translations with no control over their local doc structure?)

Comment 11

[Jean-Yves Perrier [:teoli]]

I've  to think a bit about it . I'll come back with an opinion on Tuesday (or Monday afternoon) after Mozcamp. Several contributors should also be there, so I will talk to them about this.

Comment 12

[Luke Crouch [:groovecoder]]

Jean-Yves, post-mozcamp bump.

Comment 13

[Jean-Yves Perrier [:teoli]]

Ok, I don't have a definitive opinion but a few elements:
1) The urgent problem that needs to be solved is the non-existence of breadcrumbs in translation. Our site navigation rely on them heavily right now and it basically broke it in non-English languages.
2) There is no editorial need to have them sync between several languages. But there is no reason to have them not sync either.
3) In English, moving pages should definitively update the breadcrumbs and not lose the link with translations. In other languages it looks to me that is would be logical.

I tend to say, no need for a hard synchronization, but maybe for a synchronization when creating a new translation.

But not an absolute opinion. The 1) is the important element to solve.

I have added a few people in cc/ to get more opinions.

Comment 14

[Luke Crouch [:groovecoder]]

Unless we hear an opposing viewpoint, the two bugs described in comment 10 should address all of those issues. Let's file those two bugs and close this one tomorrow unless we hear otherwise.

Comment 15

[Jean-Yves Perrier [:teoli]]

Looks good to me.

Comment 16

[Luke Crouch [:groovecoder]]

Created https://bugzilla.mozilla.org/show_bug.cgi?id=792417 and https://bugzilla.mozilla.org/show_bug.cgi?id=792418