PKB

Making Mozilla.com Better for International Users: the Sequel

For background on this proposal, see the original blog post.

After reviewing the suggestions posted to http://wiki.mozilla.org/Mozilla.com/Localization on improving international user access to Mozilla.com, the marketing and sysadmin team at Mozilla met today to assess these options, and make a recommendation on how to achieve the objective of this project.

The objective of these changes, in the short-term, is to address a use case where a non-English speaking visitor comes to Mozilla.com. We want to enable these types of visitors to more easily get to a localized Mozilla web site than is currently possible from the following three places:

1. The Mozilla.com homepage at www.mozilla.com

2. The Firefox main product page at www.mozilla.com/firefox

3. The Thunderbird main product page at www.mozilla.com/thunderbird

The solution we are proposing is to add a dropdown menu to the footer area of these 3 web pages, that allows a visitor to select their language, from a list that matches the currently available set of localized Mozilla Web sites.

When the visitor has selected a language, he or she will be sent to the localized Mozilla web site that supports this language choice.

If the visitor has made the language selection on the homepage for Mozilla.com, they will be sent to the homepage for the localized Mozilla web site in their language. Language selections made on the Firefox main page at Mozilla.com/firefox will send the visitor to the localized Firefox main page of their choice. The same logic would follow for the Thunderbird main page.

Here is a screenshot of how the change might look:
http://www.numenity.org/mozilla-home.html

PROS:
-Easiest solution to implement given resources available.

-Preserves user choice over which language version of Mozilla web site they are viewing (vs. redirecting automatically based on accept-language headers).

-Pull down menu rather than full listing of language codes (as done on Mozilla Europe sites) preserves visual presentation and branding of Mozilla.com pages.

-Achieves objective of providing easier access to localized Mozilla web sites and product downloads.

CONS:

-A short term solution.

-Requires user to figure out behavior of the pull-down menu, and it will be difficult to communicate what the menu is for in a way that is understandable by non-English speakers.

-Only applies to 3 main content pages on Mozilla.com. Users may be entering Mozilla.com through some other entry page.

OTHER NOTES
The ideal solution would be to create a language specific set of pages for each locale we currently support. So for example, for the homepage of Mozilla.com, we would have index-en.html, index-de.html, and so on. We would then let Apache decide which language version of the homepage is served to the visitor based on the visitor’s accept-language headers. When we reviewed this option, we quickly realized that given our current international web site structure, this would mean adding more work for the l10n volunteers, who would then have to help translate both the main pages for the international Mozilla Web sites, *and* this additional set of localized home and product pages for Mozilla.com.

We also considered automatically redirecting users who were trying to visit Mozilla.com or GetFirefox.com based on accept-language headers to a localized Mozilla Web site. However we ultimately decided not to go this route either. The main concern is that we did not want to presume we knew the user’s intent in trying to access Mozilla.com. Implementing an automatic redirect might end up frustrating some international users who had actually wanted to visit the US English Mozilla.com Web site.

NEXT STEPS
We welcome your feedback on this proposed solution. We’ll take comments until next Friday, January 13, either here or at the Wiki.

11 Comments so far

  1. Cameron January 6th, 2006 7:24 pm

    What about a button “Change language to %userslanguage” actually in that user’s language, as detected by their accept-language headers, and then have the dropdown box called “Other Langauges.” That provides the same functionality and solves the problem for non english speaking users.

  2. Tsee January 6th, 2006 8:22 pm

    My 2 cents:

    Make the PC monitor bigger and list the most common languages (it’d be work to make that readable) and include a language dropdown menu in there.

  3. Robert Accettura January 6th, 2006 9:06 pm

    I personally prefer an intersticial page like what belkin does:
    http://world.belkin.com/?r=y

    and put a change link on the top and/or bottom.

    Use a cookie that lasts for a long time, so users only need to enter it once.

    Also remember page user was trying to visit, so it only appears once, and effects the entire site.

    IMHO it’s ultimately cleaner and more fluent.

    I hate seeing a non-english page and need to search through what I can’t read for a link that says “english”. I’m pretty sure non-english people feel the same way.

  4. Caleb January 7th, 2006 12:45 am

    You could use GeoIP Country to map IP Address -> Country and change the language accordingly.

    You should still have a drop down box at the bottom with the list of languages though.

  5. Alan Pater January 7th, 2006 2:49 am

    Is the rejection of “automatically redirecting users who were trying to visit Mozilla.com or GetFirefox.com based on accept-language headers to a localized Mozilla Web site” based on personal preferences of the developers, or is it based on usability studies of end users? I assume that the majority of accept-language headers are set to a language readable by the user in the vast majority of cases.

  6. Peter van der Woude January 7th, 2006 5:02 am

    I second Robert Accettura’s suggestion.
    One page, one option, how much easy could you make it ?

  7. funTomas January 7th, 2006 6:45 am

    I’d suggest to place flags matching each leanguage sent in by accept-languge header. Flags are more intuitive, regardless of your English skills and literacy degree ;-)

  8. Aaron January 7th, 2006 7:50 am

    I agree with the above posts that you need it to not just say “Choose language.” If you don’t speak English, then that drop down isn’t going to do you any good.

    There has got to be a way to read the accept-language header either on the server or client side, and set the default value of the drop down to the language you think they speak (I’m sure you’ll list each language in its native form).

  9. Kees Grinwis January 7th, 2006 2:17 pm

    You suggest to put the ‘Choose your language’ dropdown at the bottom of the page. I do not think this is the correct position, because it might not be directly visible when a users opens the Homepage.

    A more appropriate alternative (in my humble opinion) would would be the somewhere in the header of the page. This might be either the dropdown or the button ‘Toon Nederlandse pagina’ (show Dutch page) as suggested in another replay.

    Another option might be to use the Accept-Language of the User Agent but make it clear that only a few pages are available in that language.

  10. Laurens Holst January 8th, 2006 10:46 am

    I think I can say on behalf of the nl-NL localisation team, that we prefer this solution:

    “We would then let Apache decide which language version of the homepage is served to the visitor based on the visitor’s accept-language headers.”

    Although I think I’d prefer to have nl/index.html instead of index-nl.html.

    A dropdown has too low discoverability. We already have or want to have many of the mozilla.com pages translated, and for the pages that aren’t translated an English version can be presented to the user with perhaps a note that their language of choice is not available for that page.

    ~Grauw

  11. Paul Kim January 9th, 2006 5:09 pm

    Hi all –

    Just responding to your comments (with a little help from the mozilla.com sysadmins):

    1. Cameron: we’ll look into whether our web designers can hook this up via Javascript. It’s a good suggestion.

    2. Tsee: Creative idea, but we have plans for the space underneath the monitor and can’t resize the graphic to make what you’re proposing legible/usable.

    3. Robert: Agreed, Belkin’s done a nice job. The other thing that helps is you have only one “thing” you can do on the interstitial page, and that’s to pick your language/country. However, adding a landing page is out of scope for this short term project. We’ll definitely look at this approach for the longer term consolidation of Mozilla web sites.

    4. Caleb: We talked about this, and assuming a user speaks Language X because they are from Country X breaks down in many cases (Switzerland for example, or Canada, or Singapore).

    5. Alan: No usability studies, just our concern that, currently, there is not a 1:1 mapping between the content on Mozilla.com and the content on international Mozilla sites. We wanted to err on the side of honoring a site visitor’s presumed intention to get the content that lives on Mozilla.com, regardless of where they are visiting from.

    6. Peter:
    Thanks for the input. We’ll look at this as an option for the long run. Right now, we don’t have the bandwidth to build, test and roll this out. We can take on a limited set of updates to existing mozilla.com pages, but not an entirely new page like the one Robert points to.

    7. funTomas: Flags are intuitive but you run the risk of signifying “French” with the flag of France, when French is spoken as the official language of numerous countries. Also, flags take up a lot of screen real estate.

    8. Aaron: We’ll look into this further…we agree, “Choose your language” in English for a dropdown isn’t the best solution. It’s just the easiest. ;-)

    9. Kees: We’ll look into this, but it will likely not change, as adding a dropdown menu to the header area is much more complicated than inserting it into the footer area.

    10. Laurens: We’d like this too, I think (having a single mozilla.com site with /nl/, /de/, /jp/ subdirectories). However, we’re going to need to plan this change out with a much bigger group and much farther in advance. Perhaps we can target this for the Firefox 2 timeframe (June 2006)?