943979 - Figure out inheritance for localized zones

Status: RESOLVED WONTFIX

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

Description

[John Karahalis [:openjck]]

Some translated Zones do not use the correct style (with the tall header and the Zone image). Others do use this style, but do not use format the content section like English zones do (with the three main boxes, etc.).

Some examples:

* https://developer.mozilla.org/pl/docs/Mozilla/Firefox
* https://developer.mozilla.org/es/docs/Mozilla/Firefox
* https://developer.mozilla.org/de/docs/Mozilla/Firefox

I am filing this as a documentation bug, but more fundamentally I think we should solve this problem by building constraints into the editing interface. If zones should look consistent, the editing interface should foster and enforce that consistency.

Comment 1

[Eric Shepherd [:sheppy]]

Yeah, this is a fundamental issue: if the English version of a page is converted into a zone, should the translations automatically become zones too?

Comment 2

[Eric Shepherd [:sheppy]]

Either we have this happen automatically, or it's a localization issue.

Comment 3

[Eric Shepherd [:sheppy]]

So this is two issues: fix the pages already done, and automate the process of zonification of localizations in the future.

Comment 4

[Eric Shepherd [:sheppy]]

Also, the localized zones should inherit CSS from en-US.

Comment 6

[John Karahalis [:openjck]]

We should be sure this also fixes the issue described in bug 943997.

Comment 7

[Les Orchard [:lorchard]]

Just for clarification, zones are currently per-page & per-locale as mentioned over here:

https://bugzilla.mozilla.org/show_bug.cgi?id=948438#c1

A translation of a page does not imply creation of a zone on the translated page.

A zone needs to be created for each page, in each locale, independently.

We can change this, but the implications need to be thought out.

Comment 8

[Les Orchard [:lorchard]]

Some things that need thinking in particular:

* If a zone is created in en-US, should it apply to the content trees of all its translation children? How should that work? The en-US zone has en-US content for CSS, navigation, and URL remaps.

* If a zone is created on a translation, should it completely supersede the en-US version? How should that get handled?

There's a tension between consistency and flexibility, here. We want consistency between zones & to minimize repeat work. But, localization is all about differences between locales. The current solution is to lean entirely toward flexibility in localization. Not sure what we'd need to give up to gain more consistency

Comment 9

[Eric Shepherd [:sheppy]]

(In reply to Les Orchard [:lorchard] from comment #8)
> Some things that need thinking in particular:
> 
> * If a zone is created in en-US, should it apply to the content trees of all
> its translation children? How should that work? The en-US zone has en-US
> content for CSS, navigation, and URL remaps.

No. Translated versions of the en-US zone would only become zones if explicitly converted to a zone. Once they are converted, however, they would use the same CSS as the en-US version.

> * If a zone is created on a translation, should it completely supersede the
> en-US version? How should that get handled?

If the French version of a page were converted to a zone, but the English version isn't yet, the CSS would still be set up in the same place, so that when the English zone is created, it would use the established CSS for that zone.

> There's a tension between consistency and flexibility, here. We want
> consistency between zones & to minimize repeat work. But, localization is
> all about differences between locales. The current solution is to lean
> entirely toward flexibility in localization. Not sure what we'd need to give
> up to gain more consistency

The differences between locales generally don't require changes to the stylesheet though. The only time this happens is for LTR/RTL issues, and those can be handled in the same stylesheet. Since admins have to manage the CSS anyway, we're not making things harder on these localizers by sharing a stylesheet, and we thereby get to share styles among all the LTR and all the RTL locales.

Comment 10

[Les Orchard [:lorchard]]

(In reply to Eric Shepherd [:sheppy] from comment #9)

> No. Translated versions of the en-US zone would only become zones if
> explicitly converted to a zone. Once they are converted, however, they would
> use the same CSS as the en-US version.

So, then you no longer think the zones should be created automatically as per comment 2 & comment 3?

> If the French version of a page were converted to a zone, but the English
> version isn't yet, the CSS would still be set up in the same place, so that
> when the English zone is created, it would use the established CSS for that
> zone.

I don't think I understand what you mean, here.

If a French page is converted to a zone, the custom zone CSS lives in the DocumentZone attached to the French page.

If the English translation parent is later converted to a zone, that would be a second DocumentZone object with its own CSS field.

So, two different DocumentZones, each with its own distinct CSS field. They don't share data.

> The differences between locales generally don't require changes to the
> stylesheet though. The only time this happens is for LTR/RTL issues, and
> those can be handled in the same stylesheet. Since admins have to manage the
> CSS anyway, we're not making things harder on these localizers by sharing a
> stylesheet, and we thereby get to share styles among all the LTR and all the
> RTL locales.

"generally don't" or absolutely won't? 

Because if translation parent (en-US) zone CSS simply supersedes the translated child (fr) zone CSS, there can never be per-locale customizations to zone CSS.

We might be able to do something with sticking the locale as a class name on the <body> element to get per-locale styles in the translation parent. Just want to get this right, though

Comment 11

[Eric Shepherd [:sheppy]]

(In reply to Les Orchard [:lorchard] from comment #10)
> (In reply to Eric Shepherd [:sheppy] from comment #9)
> 
> > No. Translated versions of the en-US zone would only become zones if
> > explicitly converted to a zone. Once they are converted, however, they would
> > use the same CSS as the en-US version.
> 
> So, then you no longer think the zones should be created automatically as
> per comment 2 & comment 3?

That's correct; I no longer than they should be, because of the content issues that will arise. I do think that some notification should be provided, somehow, to the localization team so they know to check on this.
 
> > If the French version of a page were converted to a zone, but the English
> > version isn't yet, the CSS would still be set up in the same place, so that
> > when the English zone is created, it would use the established CSS for that
> > zone.
> 
> I don't think I understand what you mean, here.
> 
> If a French page is converted to a zone, the custom zone CSS lives in the
> DocumentZone attached to the French page.
> 
> If the English translation parent is later converted to a zone, that would
> be a second DocumentZone object with its own CSS field.
> 
> So, two different DocumentZones, each with its own distinct CSS field. They
> don't share data.

They need to share data; that's the point. They should share the same CSS field.

> > The differences between locales generally don't require changes to the
> > stylesheet though. The only time this happens is for LTR/RTL issues, and
> > those can be handled in the same stylesheet. Since admins have to manage the
> > CSS anyway, we're not making things harder on these localizers by sharing a
> > stylesheet, and we thereby get to share styles among all the LTR and all the
> > RTL locales.
> 
> "generally don't" or absolutely won't? 
> 
> Because if translation parent (en-US) zone CSS simply supersedes the
> translated child (fr) zone CSS, there can never be per-locale customizations
> to zone CSS.

I can't think of any reason they should have different CSS. For consistency's sake, translated zones should look just like the English one other than text language and LTR vs RTL, which can be addressed in the same style sheet.

Comment 13

[Les Orchard [:lorchard]]

Just sounds like bug 948438 is a dupe of this one. 

Is there anything to this bug with zones, other than how CSS is applied?

Copying over :sheppy's last comment from bug 948438.

(In reply to Eric Shepherd [:sheppy] from comment #5)
> OK, let's try this on:
> 
> All localizations of a zone should pull in the CSS from the translation
> parent *PLUS* from the translated zone. That way, localized zones get the
> CSS that they probably want automatically, but have the ability to customize
> it.

Comment 14

[Florian Scholz (Open Web Docs)]

This bug needs resolutions to implement solutions. Two things I see that need addressing: A and B.

== A) Inheriting CSS or not is not a big problem here.== 

The CSS is also very small oftentimes and repeated code so often. I propose to look into outsourcing it into a shared CSS file (ZonesCSS) – something managed by the front-end devs. That way it is shareable among different zones (often the only difference is the icon) and among all locales.

== B) What is more problematic and major is the URL remapping for zones. ==

When we launched the Developer Edition this week, links broke for all non-En-US users. The first run page contains links like this one:
https://developer.mozilla.org/docs/Tools/Network_Monitor or https://developer.mozilla.org/Firefox/Developer_Edition/Reverting

Both documents are in zone areas which remap the URL. If you don't provide a DocumentZone in localized articles, these links are all leading to 404.

I am proposing:
1) When creating a new translation of an English document that has a zone, copy that zone and apply it with the same settings as the English zone to the localized document. In other words: A translation of a zoned page implies creation of a copied zone on the translated page.

2) If you create a zone later on and the English document has translations already: do nothing. The zone creator is responsible to add a zone to existing localized docs. (Of course, once the zone is there and new translations are created to that English doc, it should get copied as part of creating a new translated doc, see case 1.)


All: This bugs is about finding a resolution for A) and B). Please discuss what I proposed. Once we agree on what to implement, we can file actual implementation requests for A and B. I am happy to answer questions/discuss this further.

Comment 15

[Eric Shepherd [:sheppy]]

+1 to Florian's proposals. This is a good plan. We need to ensure that every page (across all locales) is either a zone or not, regardless of whether or not they've been translated yet.

Comment 16

[Jean-Yves Perrier [:teoli]]

A corollary to point B is also that a page that is a zone in en-US, but not yet translated in a given language, say fr, must not give a 404. It must give the en-US content with the call for translation banner, like for a regular non-zone page.

Comment 17

[Jean-Yves Perrier [:teoli]]

I'm also feedbacking :hoosteeno and Maris. We need this bug to be retriaged too and technical solution should be proposed for prioritization. The launch of Fx Dev Edition showed how big a problem it is

Comment 18

[Justin Crawford [:hoosteeno] [:jcrawford]]

The renewed urgency around this bug is due to a big link we added last week directing visitors to an unlocalized zone url for the Developer Edition. Visitors to such a URL from a locale that doesn't have a corresponding zone page get a 404. 

There is a workaround for this: We can manually create the zone in all of our locales. That relieves some of the immediate urgency. Jean-Yves is doing that now.

Of course we can't control who links to what at what URL, from inside or outside MDN. The deeper issue here will remain a risk and we should resolve it. Meanwhile, if you see bugs coming from this issue, consider the workaround above.

Comment 19

[Florian Scholz (Open Web Docs)]

fwiw, A) is actually bug 944186.

Comment 22

[John Karahalis [:openjck]]

I just met Mantaroh (copied here) who is interested in helping to fix this bug. Mantaroh found another page where this happens.

English: https://developer.mozilla.org/en-US/docs/MDN/Contribute
Japanese: https://developer.mozilla.org/ja/docs/MDN/Contribute

Comment 23

[proreco]

Works the {zones + locales}-concept with suchlike languages how japanese and arabic? Details in german:

Folgende grundsätzliche Überlegung dazu - die mit Zones anvisierte strikte Strukturierung von Inhalten ist nicht zielführend. Und zwar aus dem gleichen Grund, warum die Mehrheit der User sich von Katalogen wie Yahooo und DMOZ abgewendet und sich für eine auf ein Eingabefeld reduzierte Navigation entschieden hat.

Der Aufwand ist schlicht und einfach zu groß, permanent eine Zonenstruktur zu erfinden, diese Struktur aktuell zu halten - und das noch mit einer zusätzlichen Einschränkung, dass die CSS zonen- und sprachübergreifend funktionsfähig bleiben müssen.

Meine CSS-Kenntnisse der CSS-Konzepte sind nicht so tiefgreifend, aber ich kann mir vorstellen, dass erhebliche - vlt. auch unlösbare Probleme dann entstehen, wenn man versucht, für die japanische oder arabische Webseiten die gleiche CSS-Formatierungen zu verwenden die man für en-US- oder ähnliche westliche Sprachfamilien-Webseiten  aufwendig programmiert hat.

Comment 25

[Florian Scholz (Open Web Docs)]

We're planning to remove zones entirely.