Closed Bug 744271 Opened 12 years ago Closed 11 years ago

Make universal tab localizable

Categories

(www.mozilla.org :: General, defect)

Product:
www.mozilla.org
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
Future

People

(Reporter: Nukeador, Assigned: osmose)

References

Details

(Whiteboard: u=contributor c=l10n p=3) 

Hi,

Since we are implementing the new universaltab in Mozilla Hispano site, we would need it to be localizable. This means:

* Being able to translate the text.
* Being able to add community/locale relevant links.

Some changes were suggested here months ago:

https://github.com/mozilla/tabzilla/issues/4
https://github.com/mozilla/tabzilla/issues/3
I have the same request, but would like also to replace/remove some of the current links. i.e., we might want to focus more on localized content than the project in a whole. There should also be some kind of moderation and a guidelines of what can be changed and what should always be kept as it is for consistency between Mozilla sites.

Also please pay attention to the issue below, where I've suggested to *disable* RTL support unless there will be localized RTL content in the future. 

https://github.com/mozilla/tabzilla/issues/2
(In reply to Tomer Cohen :tomer from comment #1)
> I have the same request, but would like also to replace/remove some of the
> current links. i.e., we might want to focus more on localized content than
> the project in a whole. There should also be some kind of moderation and a
> guidelines of what can be changed and what should always be kept as it is
> for consistency between Mozilla sites.

Tomer, good point.  The idea was that the universal tab should have some elements that were always in place to provide a consistent way to move across any Mozilla site.

We also wanted to have some flexibility to add context-specific links -- for instance, if you were on hg.mozilla.org then maybe there are some developer links that showed up.

Maybe that means adding an optional column that sites can turn on and fill however they want?  Just one thought -- probably lots of different ways to go about handling context-specific links.
(In reply to David Boswell from comment #2)
> Maybe that means adding an optional column that sites can turn on and fill
> however they want?  Just one thought -- probably lots of different ways to
> go about handling context-specific links.

That sounds good, for example the current "Get involved" link points to a page in English when we have a specific page in our portal with all the information in Spanish, mentors emails...
David's suggestion in comment #2 sounds great to me.
(In reply to David Boswell from comment #2)
> Maybe that means adding an optional column that sites can turn on and fill
> however they want?  Just one thought -- probably lots of different ways to
> go about handling context-specific links.

I am not sure if we should allow sites to manipulate with the displayed links (at least not allow it officially), but I think there should be some categories where the custom column will support. For example, a "Mozilla Hacker" category should be common to both hg.mozilla.org, bugzilla.mozilla.org and also mxr.mozilla.org, and will contain some links meant to developers. It will be easier if these categories would be managed in a centralized place, so changing some of the custom category links won't require yelling people to update the themes on every site. 

On the other hand, people are screaming every time Google changes the order of items on their top navigation bar, and move services into the the submenu, and I hope we don't want to have such horrible experience in our implementation.
I, personally, also am against making a localized version of tabzilla as default for any Mozilla-site. Many members from different communities & language groups visits neighboring community sites etc. who will feel lost here.

Although, I do understand the necessity of a localized version of the tabzilla for the native users of that community. Giving it a thought for a while, I could come up with 2 possible solutions (applicable for 2 distinct purposes):

1. In the right-most column, before the search, we can include a link/button to toggle the language of tabzilla to a predefined l10n (say, Spanish for Hispanic site, Hebrew for Israeli). The default will always be English.

2. In the same column, same place, we can add a drop-down selection to choose from a list of available languages. Same as before, it will be set default to English.

Thoughts?
(In reply to Soumya Deb [:Debloper] from comment #6)
> I, personally, also am against making a localized version of tabzilla as
> default for any Mozilla-site. Many members from different communities &
> language groups visits neighboring community sites etc. who will feel lost
> here.

I don't see the problem of offering the tabzilla content in the user preferred language.

The content would be only different when visiting certain sites, but you won't "lose" any content for using tabzilla in other languages. SUMO tabzilla will have the same content in all languages and maybe an extra column with community links related with your language.
Just started to work on it today, as I got some free time.
Here's a working demo: http://debloper.github.com/tabzilla

Just the working prototype, still too many things to implement for the betterment of its operation. Plus, need more l10n strings from the community. For bug-report/feature requests please use GitHub Issues of the main-repo, as it's already being used for that purpose.

Will update the page with details soon & will call the community for string-submission. Stay tuned.
(In reply to Soumya Deb [:Debloper] from comment #8)
> Here's a working demo: http://debloper.github.com/tabzilla
>

Wouldn't it be better to use the xreflang attribute instead of the data-locale one? It is more semantical.

<a href="http://www.mozilla.org/" id="tabzilla" xreflang="de-DE">mozilla</a>
->
<a href="http://www.mozilla.org/" id="tabzilla" data-locale="de-DE">mozilla</a>
(In reply to Fernando García Gómez, stripTM from comment #9)
> Wouldn't it be better to use the xreflang attribute instead of the
> data-locale one? It is more semantical.

0. I think you mean hreflang, if I'm not mistaken.

1. If my understanding is correct, then hreflang is an anchor-attribute that refers the language of the reference page (i.e. http://www.mozilla.org/ here) - which is clearly not the case. We aren't mentioning the language of the pointing page in here at all (in fact, we're subverting opening the link completely).
Reference: http://www.w3.org/TR/html401/struct/links.html#adef-hreflang

2. I don't know how it makes that more semantic. While I am not particularly inclined/biased to use a data-attribute - but here it seems to be the only good, safe, future-proof & neutral way to hold a persistent data in an element, without causing any side-effect.
0. Yes, I meant hreflang.
1. I don't like the use of Attribute data because Universal tab will be included in HTML 4 pages, and even it works, the page will not validate. I decided to use hreflang instead of class because the content showed is localized. The ideal would be that the Mozilla.org home is localized too.
What do you think about having as much js. as the localized versions we have?
In example:
<script src="https://raw.github.com/debloper/tabzilla/master/media/js/locale_es-ES.js"></script>
(In reply to Fernando García Gómez, stripTM from comment #11)
> 1. I don't like the use of Attribute data because Universal tab will be
> included in HTML 4 pages,
Really? Who'll be interested in making HTML4-only pages now, or in future?

> and even it works, the page will not validate.
I am not sure there is any mozilla-site or community site, which uses properly validated HTML4 (without any HTML5 feature). Can you please refer me one?

> I decided to use hreflang instead of class because the content showed is
> localized.
hreflang is used for the target's language, if I wasn't clear last time, not of the content. Class is a DOM feature to classify an element. Both are inappropriate for storing data. As we are trying to attach a persistent data to the element, HTML5 implemented data-attribute just for that particular purpose & t suits just fine. Using class or hreflang is of course a (hacky) way of doing the same, but not appropriate for this purpose.

> The ideal would be that the Mozilla.org home is localized too.
What if the Spanish community site wants the tabzilla to be in English (for all visitors' convenience) i.e. the tabzilla's default language is different than the site's? How are you planning to handle that decoupling?

> What do you think about having as much js. as the localized versions we have?
> In example: <script
> src="https://raw.github.com/debloper/tabzilla/master/media/js/locale_es-ES.
> js"></script>
So, each time the page loads, it has to make 70 HTTP GET requests to the server for those 70 languages - is that your suggestion? Sorry bro, sounds awful.
> Really? Who'll be interested in making HTML4-only pages now, or in future?
Unfortunately during some time there will be community sites built in html4

> I am not sure there is any mozilla-site or community site, which uses properly validated 
> HTML4 (without any HTML5 feature). Can you please refer me one?

Some weeks ago http://mozilla-hispano.org was properly validated. My mission is to make it possible again ;-) that's why I'm so obsessed about not including html5

> Using class or hreflang is of course a (hacky) way of doing the same, but not appropriate for this purpose.

You are right, but for html4 there are more options and even html5 is more advanced, it is not standard yet.

> What if the Spanish community site wants the tabzilla to be in English (for all visitors'
> convenience) i.e. the tabzilla's default language is different than the site's? How are you
> planning to handle that decoupling?

In Mozilla Hispano we would like to have *only* Spanish content, to have everything translated. Having sentences in different languages is very odd.

> So, each time the page loads, it has to make 70 HTTP GET requests to the server for those 
> 70 languages - is that your suggestion? Sorry bro, sounds awful.

We would only ask for the Spanish language, we are not interested in other languages. It is similar to the products. If I download Thunderbird in french, I will not download strings in german.
>What if the Spanish community site wants the tabzilla to be in English (for all visitors' convenience) i.e. the tabzilla's default language is different than the site's? How are you planning to handle that decoupling?

There should be no decoupling, the universal header is part of the page and should be localized too and fallback to English if it is not translated, we don't want a part of the page to be in Spanish and another one to be in English and we certainly don't want to manage two language switchers on the same page, one for tabzilla and one for the page itself.
All mozilla pages expose the page language in a lang attribute on the html element that can be used for locale detection with a DOM-based approach and is backward compatible with HTML4 or XHTML pages, what is the rationale for using a data-locale attribute duplicating this information in the tabzilla link instead?
(In reply to Pascal Chevrel:pascalc from comment #15)
> All mozilla pages expose the page language in a lang attribute on the html
> element that can be used for locale detection with a DOM-based approach and
> is backward compatible with HTML4 or XHTML pages

That's way more preferable than using hreflang, and can be easily implemented.


> what is the rationale for using a data-locale attribute duplicating this
> information in the tabzilla link instead?

The only reason was (which doesn't hold anymore, by popular demand), what if a community wants their tabzilla in other language than the page content? Since the decoupling is not required, I will remove the language detection from the data element to the anchor - and handle it with html-lang attribute instead.
Pascal & Soumya I think it is a great idea, If the html lang attribute was not present, the English version would be taken by default.
Ping here, it's been a long time since last update. How are the things going? What's needed for this to be finished?

Thanks.
Who had the action on this bug as it is not assigned to anyone? Currently, the websites team is currently focused on a responsive CSS/layout for Mozilla.org and Firefox for mobile updates for the end of June.
Patch awaiting review & merge: https://github.com/mozilla/tabzilla/pull/9
Assignee: nobody → debloper
Status: NEW → ASSIGNED
Target Milestone: --- → 3.0
Target Milestone: 3.0 → 3.5
debloper, any idea why your changes weren't committed yet?
(In reply to Rubén Martín [:Nukeador] [PTO till 20/8] from comment #21)
> debloper, any idea why your changes weren't committed yet?

May be because I'm ugly. And fat. Mostly because ugly. :P

Well, the tabzilla team was busy making a responsive & accessible port of it. And localization wasn't a priority. And they also weren't decided how to approach the localization (or is that even necessary for the sites).

To avoid making point why tabzilla has to be l10n'd everywhere, I later came up with a suggestion, to make a l10n branch in the main repo & only bastardize that branch, if the master/production branches are to be left untouched (i.e. make a parallel implementation, making it opt-in to use l10n version over the original). But closest I got is, :cmore leading me to #www & till today I'm waiting there... :-/
CC'ing Pierros and Giorgos just in case they can help with webdev team.

There are currently a lot of local sites using tabzilla because it was supposed to be localizable, and we didn't fork it because of this, but this is taking forever having in mind the hard work Debloper has done to minimize webdev work load.
Whiteboard: u=l10n c=contributor p=5
Whiteboard: u=l10n c=contributor p=5 → u=contributor c=l10n p=5
Whiteboard: u=contributor c=l10n p=5 → [sp-2012-08-14] u=contributor c=l10n p=5
Component: www.mozilla.org → General
Product: Websites → www.mozilla.org
This is long overdue. My apologies for this.

I think we're not gonna continue in the current direction. Localising static files like that is not sustainable. We want to bring Tabzilla into Bedrock so that it can use the same L10N mechanism.

One concern Debloper discussed with me on IRC was:
"Can websites choose a specific locale or let Tabzilla decide for the best locale?" (I'm rephrasing, might not be accurate)
I think we can do that with the current L10N system on Bedrock.
- Websites that want to force a specific locale would link to www.m.o/{locale}/js/tabzilla.js
- Websites that want Tabzilla to decide would link to www.m.o/js/tabzilla.js

I'm really sorry this took so long and some efforts have been wasted but I believe this is a better direction.

If anyone wants to submit a pull request to import this into Bedrock, it will be my higher priority to review it and help to get this moving.
Hi,

Sorry but I have problems understanding the current situation.

* What could be the perils of adding this before bedrock?
* Why Debloper's code can't be used/modified to use whatever bedrock needs?
* Do we have a ETA for this feature?

Having a l10n ready tabzilla it's been a desire for communities since day one, and we decided to wait and use the official implementation instead of forking it. It seems we have been going back and forward all the time dealing with different people all the time.

Please, is it possible move this forward?

Thanks.
Hi Ruben.

* What could be the perils of adding this before bedrock?

Pros: In the Python-based system that has our built-in standard localization methods. We will be able to extract strings for additional locales without having to do something on-off just for the current static tabzilla.

Cons: Other sites would be fully relying on Bedrock/Python. We should have automated tests in place to prevent regressions or issues with Tabzilla in Bedrock.

* Why Debloper's code can't be used/modified to use whatever bedrock needs?

Rik could probably provide more rationale, but the way I understand is that we want to put the logic in Python and not JS and have the strings baked into a Django jinja template. The locale detection and URLs are already in place on Bedrock and thus we wouldn't have to invent a new way to handle a localized piece of content.

* Do we have a ETA for this feature?

Rik is on PTO this week and he will return next Monday. We just need to get everyone on the same page and then focus on the move into Bedrock. We were going to have the move into Bedrock to happen this 2-week sprint, but just couldn't make it due to other priorities and availabilities.
Adding a depends on here for serving the font (and probably the other files) from bedrocks servers.

If we use the same font/path we will avoid double loading on mozilla sites. Woo!
Depends on: 790806
Whiteboard: [sp-2012-08-14] u=contributor c=l10n p=5 → u=contributor c=l10n p=3
Target Milestone: 3.5 → Future
Assignee: debloper → anthony
Priority: -- → P1
Annnnnd a pull request has been submitted.

https://github.com/mozilla/bedrock/pull/507
Priority: P1 → --
Commit pushed to master at https://github.com/mozilla/bedrock

https://github.com/mozilla/bedrock/commit/641ead07349321d7953c28673ad6e77ceae039d5
Import Tabzilla into Bedrock

- Make it localisable
- Add redirects for backwards compatibility
- Adds a js_escape filter

bug 744271
Assignee: anthony → mkelly
Jumping on this now that Rik is but a ghost of the past. :P

So it looks like the remaining steps are:

- Push to production (likely happening sometime tomorrow).
- Test with /b/ urls to ensure that Tabzilla still works as expected.
- Add /b/ redirects to all environments (and test each).
- Remove tabzilla external from SVN and update the tabzilla repo README to point to bedrock.
- Over time, the strings will be translated via bedrock's normal translation process and more locales will become available.

Let me know if any of those steps are wrong or if something's missing. 

Also, question for pascal: I'm a bit unfamiliar with how bedrock l10n works, is there anything we have to do at this point to get the strings available for localization?

Also also, are we going to do anything about the fact that you sort've need an instance of bedrock running to contribute to Tabzilla now?
Flags: needinfo?(pascalc)
(In reply to Michael Kelly [:mkelly] from comment #30)

> Also, question for pascal: I'm a bit unfamiliar with how bedrock l10n works,
> is there anything we have to do at this point to get the strings available
> for localization?

Nothing, I started looking yesterday and it works :)
Flags: needinfo?(pascalc)
Commits pushed to master at https://github.com/mozilla/bedrock

https://github.com/mozilla/bedrock/commit/5b66838764159c41a54dc2ab5ddcca176a9d2cdc
Bug 744271: Do not use new tabzilla URLs in base template.

If we use the new tabzilla URLs in the base template, the JS will fail
to load without a /b/ redirect, but we want this out in production
before putting out that redirect. So we'll stick to the old URL, which
will work before and after the switch.

https://github.com/mozilla/bedrock/commit/5a84349b038dcd706de4d3c65888ac2ed9ae928e
Bug 744271: Serve dev CSS if TEMPLATE_DEBUG is true.

Adds the ability to use callables as redirects and uses that to send a
different redirect for the Tabzilla CSS if TEMPLATE_DEBUG is true.
Localized tabzilla is live! Thanks to everyone involved in helping us make it this far. <3

Here's a revised list of next steps (some of which may be out-of-scope for this particular bug):

- Fix redirect bug that prevents sites from selecting a specific locale using the old tabzilla URL.
- Remove tabzilla external from SVN and update the tabzilla repo README to point to bedrock.
- Determine if we can find some way to support tabzilla development without needing a Bedrock instance locally.
- Investigate storing tabzilla on a CDN.
Nice job everyone!!!
Do we need to change the js path on local sites in order to get it localized?

I'm still getting English version.

(For example here http://www.mozilla-hispano.org/)
(In reply to Rubén Martín [:Nukeador] from comment #36)
> Do we need to change the js path on local sites in order to get it localized?
> 
> I'm still getting English version.
> 
> (For example here http://www.mozilla-hispano.org/)

You will have to change the path to force a certain locale. For example, if you want to always use es regardless of the user's preferences, you'd use:

//mozilla.org/es/tabzilla/media/js/tabzilla.js

The problem is that there's currently a bug that makes that go to en-US instead. I'll file a bug shortly and attach it to this bug for fixing it.

I also don't know if there's anything special we have to do to "activate" a locale once it's finished, but pascal would know.
Depends on: 823908
Marking as resolved since the other bug was fixed, we'll open separate bugs for the other issues.
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.