Closed Bug 943979 Opened 9 years ago Closed 4 years ago

Figure out inheritance for localized zones

Categories

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

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: openjck, Unassigned)

References

Details

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.
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?
Either we have this happen automatically, or it's a localization issue.
So this is two issues: fix the pages already done, and automate the process of zonification of localizations in the future.
Also, the localized zones should inherit CSS from en-US.
Duplicate of this bug: 943997
We should be sure this also fixes the issue described in bug 943997.
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.
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
(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.
(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
(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.
Duplicate of this bug: 948438
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.
Summary: Translated Zones do not look like Zones → Localized zone should inherit CSS from the zone of localization parent
Severity: normal → minor
Priority: -- → P2
Assignee: eshepherd → nobody
Component: General → Wiki pages
Product: Developer Documentation → Mozilla Developer Network
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.
Severity: minor → major
OS: Windows 7 → All
Hardware: x86 → All
Summary: Localized zone should inherit CSS from the zone of localization parent → Figure out inheritance for localized zones
+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.
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.
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
Flags: needinfo?(mars)
Flags: needinfo?(hoosteeno)
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.
Flags: needinfo?(mars)
Flags: needinfo?(hoosteeno)
fwiw, A) is actually bug 944186.
Duplicate of this bug: 1054269
Duplicate of this bug: 1104467
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
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.
Duplicate of this bug: 1187221
We're planning to remove zones entirely.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
Product: developer.mozilla.org → developer.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.