Mozilla.com/Localization

< back to Mozilla.com wiki page

This page is a resource for discussing changes and updates to mozilla.com to improve access for non-English speaking users.

Here is a stub of discussion areas to be filled in with input from the international community.

Use Cases

These are the use cases that require internationalization of mozilla.com pages. They are listed in order of expected frequency.

• (primary) International users coming to main mozilla.com URLs to learn about our products and obtain our software.

• (secondary) Users looking for a build in a specific language which may or may not be their primary language (for testing, exploration, etc.)

• (secondary) Users looking for support in their language.

The Team

Who'd like to help us? We'll need:

• translators
• sysadmins
• testers

Request for volunteers posted to: http://groups.google.com/group/netscape.public.mozilla.l10n/

Volunteers:

• Catalan-Valencian [ca]: Toni Hermoso, Projecte Mozilla en català Translators,
• Czech [cs]: CZilla (Czech Mozilla Project) - Pavel Franc. Translators, testers.
• Dutch: marco casteleijn. Translator, Tester.
• Georgian [ka]: GIA team MozillaGe, Gia Shervashidze translators, sysadmins, testers.
• Portuguese [pt-BR]: Jeferson Hultmann. Translator.
• Spanish: Jorge Villalobos. Translator, sysadmin, tester.
• Turkish [tr]: Ahmet Serkan Tıratacı, Mozilla Türkiye. Translator, sysadmin, tester.

Potential Solutions

Add ideas for how we can best design the internationalization experience for our users. No idea is too wacky, simple or complex. For each, please list:

• the idea in a nutshell
• implementation requirements
• any pros/cons you can think of

Use Accept-Language Headers

Use Apache's support for content negotiation to serve the pages in the language requested by the browser's "Accept-Language" header.

Requirements

• user's browser sends the appropriate accept-language header
• mozilla.com's apache can be configured to serve appropriate pages
• fallback for languages we don't support / default language

Pros

• transparent to user and makes best use of available technology

Cons

• requires that user has browser that sends correct header

Feedback from netscape.public.mozilla.l10n
Author: Victory
To use content-negotiation, you should use 'filename'.'lang'.html or 'filename'.html.'lang' form, not 'filename'.html. Note that there's a problem that typical users don't configure their browser correctly so this often doesn't make sense by only content-negotiation so Apache docs use trick in their httpd.conf.

Author: Sebastian.Moser
most users don't configure their browser at all, because they are bundled with the operating system (it's the same with linux). users that are capable of changing their browser's configuration should also bbe able to either configure it correctly or read english text. i like the mozilla-europe.org-approach more (a folder for every language), with making it able for users to switch the language they use. an additional possibility would be to save the language used in a cookie, so that if the accept-language-header-value doesn't fit to the user's selection, this will be saved.

Some practical advice from mozilla-europe.org

The home page uses Accept-Language Headers to redirect to appropriate to the appropriate directory, named after the language code, e.g. /fr/ for FR-fr users. When they are there, no more language sniffing is done, which enables them to switch language if needed, using the list of links in the page footer.

Cons Author: fantasai

• For specific documents people will always be linking the non-negotiated URLs
• Doesn't handle partial translations (some files, not others)

Use Gerv's method

I've written up a method for using Content-Negotiation with a per-page override and sensible bookmarking, that I use on another site. It'll handle partial translation. The only restriction is that all URLs within the site must be relative; whether that's reasonable or not depends on what the site is. Feel free to use it if it works for you.

Timeline

• Dec 17 - collect potential solutions, build out team
• Dec 20 - have plan for solution in place
• Jan 20 - have implemented solution in place

Track implementation

Any bugs created to implement the plan will be listed here for tracking purposes.