285850 - show available extension locales

Status: RESOLVED WONTFIX

(addons.mozilla.org Graveyard :: Public Pages, enhancement, P4)

Description

[Nicolas Mandil (:NicolasWeb)]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.7.6) Gecko/20050226 Firefox/1.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.7.6) Gecko/20050226 Firefox/1.0.1

The site should be more powerful with the possibility of showing the languages
available for the extensions:  should show the extensions in English and in user
language for those which were translated.
With this there will be only one way to find all extensions, this will help
unexperimented user to user the power of FF/TB extension system.

Reproducible: Always

Comment 1

[Nickolay_Ponomarev]

Listings if for requests to add some existing extension to the website. ->Website

Couldn't find dupes, confirming.

Probably would be nice to do some/all of the following:
- display the list of locales available for each extension
- indicate whether given extension is available for preselected locale (perhaps
stick it in parameters in URL, like OS, guess from UA).
- search (when implemented) for extensions that have given languages.

--
Related thoughts, but should be in a separate bug: It's also worth noting that a
locale might exist, but not included in the submitted XPI. I'm not sure if this
is possible (should be), but authors should be able to submit locales separately
and it should look the same to users, i.e. they click Install Now and *two* XPIs
are installed, the extension itself and the selected locale. Too lazy to file a
bug about this.

Comment 2

[Nickolay_Ponomarev]

adding dependency, and intl keyword, tweaking summary (was "Show extension
language")

Comment 3

[Alex Sirota (iosart)]

A related bug I opened a while back: bug 280385

Comment 4

[Michael Morgan [:morgamic]]

Mass change - bugs to be read / (re)confirmed.

Comment 5

[Cameron]

AMO bugspam. Correcting QA contacts on OLD bugs ([e-mail])

-> Correct QA contact ([e-mail])

Filtermeplzkthx

Comment 7

[Nicolas Mandil (:NicolasWeb)]

As we warn the user if the add-on version is vrong with Fx version, we should warn him if the add-on doesn't exist in it language.

Comment 8

[Dave Townsend [:mossop]]

Looks to be a website only issue and an ancient one at that, I don't see any reason we'd block 3.1 on this.

Comment 11

[Justin Scott [:fligtar]]

Attachment: mockup, v1

Locales are included in the metadata of this mockup. Note that if there are more locales than this, we would have a link to "show all" that would expose the rest.

Comment 12

[Dave Garrett]

Re: mockup v1. I'm worried that there is not enough space available for the list of locales. I have 38... it ain't going to fit pretty. Might need to list the current locale + English + a few other highly used locales and then a "more" link to expand down the box and show the rest. An "n total" bit of text might also be good.

Another note, the locales in the mockup are named in English. I've been listing my supported locales in the dev comments and I use native names. They don't all show correctly on very old Windows with missing fonts they should've installed, but you could probably include a downloadable font to make sure they always show if you were worried about that. The way I see it, if someone is going to recognize their locale in the list then it should probably be always written how they'd recognize it best. (regardless of the current locale of the site)

Also, it's "localized" not "localised".

Comment 13

[Wil Clouser [:clouserw]]

I agree that locales aren't going to fit well there.  Also, we can give users a stronger message if they are browsing in a locale (not en-US) and the add-on supports it.  Say, off to the right of the install button we have a green checkmark with something like "This add-on is localized in $locale."

Since this bug encompasses more than just design; regarding technical implementation:  If authors use a standard locale directory with locale codes as directory names we can fill this list automatically.  Additionally, if they use a locale code that Mozilla has details on, we can fill in the native name automatically, otherwise we're stuck with just the code.

We can give

Comment 14

[Dave Garrett]

(In reply to comment #13)
> Also, we can give users a
> stronger message if they are browsing in a locale (not en-US) and the add-on
> supports it.  Say, off to the right of the install button we have a green
> checkmark with something like "This add-on is localized in $locale."

I wouldn't exclude English there. I think there may be addons that don't support English.

When the locale isn't supported, that same space could have the opposite message with an X icon. There's also the third case, where the user is say es-AR and the extension doesn't have it but does have es-ES, in which case it should probably have the success message listing the partial match with a warning icon.

> Since this bug encompasses more than just design; regarding technical
> implementation:  If authors use a standard locale directory with locale codes
> as directory names we can fill this list automatically.

Why bother with directory names? Just use the "locale" lines in chrome.manifest. Besides, if there is a dir but no line in the manifest, it won't actually work.

> Additionally, if they use a locale code that Mozilla has details on, we can
> fill in the native name automatically, otherwise we're stuck with just the code.

Shouldn't be too hard to build up a full list of them.

> We can give

missing part of your post...

Comment 15

[Justin Scott [:fligtar]]

Attachment: mockup, v2

We'll list the locale the user is browsing in first and bold if it's available for the add-on.

Comment 16

[Wil Clouser [:clouserw]]

(In reply to comment #15)
> Created an attachment (id=427017) [details]
> mockup, v2
> 
> We'll list the locale the user is browsing in first and bold if it's available
> for the add-on.

Are the rest alphabetical?  Does the "View all" link just expand that row vertically and hide itself?

Comment 17

[Justin Scott [:fligtar]]

Yes to both

Comment 18

[Axel Hecht [:Pike]]

A bit on locale codes, we're very likely going to get richer locale codes soon, in particular, script codes. See http://tools.ietf.org/html/bcp47 and bug 525494.

For an actual patch, it'd be cool if we had something to extract the localizations from our Mozilla localizations.

Not sure how sorting works in non-latin scripts, in which we localize AMO.

I have been pondering if we should use language names in the UI language or have each language name be in its own language, but I think in this case, UI language is the right choice.

Comment 19

[Wil Clouser [:clouserw]]

Chowse, where can we fit this in the new design?

Comment 20

[Chris Howse [:chowse]]

It could fit in a sidebar beside the add-on description, provided it's collapsible. Here's an example:

Collapsed:
http://cl.ly/3g262H1Y332O3h2o3Z1q/Image_2011.07.11_6_40_09_PM.png

Expanded:
http://cl.ly/0c3M0I0Y0R0R3I2G1g1c/Image_2011.07.11_6_41_54_PM.png

I think 5's a reasonable default to make the list expandable. The language of the visitor should always be the first (as discussed above-- possibly emphasized). For the remainder, they could be sorted alphabetically or by popularity (if we have any such metric), whichever is most convenient.

Comment 21

[Dave Garrett]

I think it would be best if the language names were shown in their native form rather than the site's currently used locale. If someone ends up at an addons page via a link with en-US in the URL, which is common, they should be able to glance at the list and read their own language's name. I think this list should be geared towards showing the same in all AMO locales with only the "supported locales" header being localized.

(In reply to comment #20)
> by popularity (if we have any such metric)

We do have locale stats for each addon.

Sorting by usage is better than alphabetically (and if native names are used this isn't even possible), but I personally prefer sorting by rough geography/type. For example, here is how I currently list my supported locales for Flagfox:

Supported locales: English, Français, Italiano, Español, Español (Argentina), Português, Português (Brasil), Deutsch, Nederlands, Dansk, Čeština, polski, Latviešu, Magyar, română, Íslenska, Svenska, suomi, Українська, Русский, Български, Српски, Ελληνικά, Türkçe, Հայերեն, עברית ,العربية, Tiếng Việt, 中文 (简体), 正體中文 (繁體), 한국어, 日本語

Sorting roughly in a way as to group related locales together makes longer lists much easier to read. For example, simplified and traditional (aka China and Taiwan) Chinese make sense to be next to each other in the list, as does grouping the Romance, Middle-Eastern, and Cyrillic languages. If they were sorted by usage, for example, someone could read that an addon supports Brazilian Portuguese up top and think the dialect for Portugal isn't supported simply because they didn't notice it mixed further down in the list.

Also, rather than move the detected user's locale up top, I think just highlighting it in bold in the list is simple and effective enough.

> It could fit in a sidebar beside the add-on description, provided it's collapsible.

If we use the fairly small font that's already used on the right side then there's no reason not to simply show them all at once. In your mockup you showed 10 in only 3.5 lines. Collapsing that doesn't have much of a practical effect. I have 32 shipping locales in Flagfox which would still only take up around 11 lines or so, and most addons have far fewer. (what is the average locale count, anyway?) I think we have the space here to not need to compact things, especially due to the small font.

Comment 22

[Wil Clouser [:clouserw]]

I agree with native form - sorting doesn't need to be so complex I think.  Right now we have them "alphabetically" sorted in the locale drop down list (it's by locale code I think).  We can just bold their current language or, if fligtar thinks it's better, move it to the start of the list and then bold it.

I think this is fine to launch and we can gather feedback about improvements to sorting.

Comment 23

[Chris Howse [:chowse]]

Designs updated:

Prototype:
http://chowse.github.com/amo-redux/detail.html

Changeset:
https://github.com/chowse/amo-redux/commit/425ff3ec8630448190c96f284ca0208de826712f

Locales have been changed to their native form and sorted alphabetically (with the user's locale at the front of the list, if supported). I've kept the collapsing text, since I don't want the language block becoming too large of a visual presence (at least initially). We can tweak the number of add-ons to show by default once we test it with real data.


---

As an aside: I'm also considering an alternative design, which by default is entirely focused on whether your current locale is supported or not (other locales are hidden by default):

http://f.cl.ly/items/1z3i373g472M3e3F0O1j/Image%202011.07.12%202:05:16%20PM.png

This hides more information about supported domains initially, but it makes it easy to answer a second important question: does this add-on NOT support my locale? The other design can answer the affirmative, but not the negative w/o looking through the entire list of locales. This is, of course, assuming that they are browsing AMO in their native locale.

Comment 24

[Dave Garrett]

Language nit: In whatever design that ends up getting used, please use terminology along the lines of "your locale is (not) supported" not "your locale is (not) available". I've had more than a few people ask me where a version of Flagfox can be downloaded in their language because most people don't seem to understand that all supported languages are contained in the single installer. It would be best to not reinforce this misconception where possible.

(In reply to comment #23)
> This is, of course, assuming that they are browsing AMO in their native locale.

This seems to not always be a good assumption, sadly. Links to AMO pages almost always contain a locale code in the URL because AMO adds it automatically and the locale switcher is buried down at the bottom where few seem to find it. I think people only view AMO in their own locale if they browse to addons.mozilla.org to start and not when going to a specific link to an addon, which is fairly common.

Doing a "smart" version where it tells you explicitly whether or not your locale is supported would work a lot better if AMO ditched the locale code in the URL by default and always autodetected. (possibly with some other format to explicitly link to a specific locale if needed)

Comment 25

[Wil Clouser [:clouserw]]

We could key this off accept-locale on the front end without messing with any of the "are they browsing in the right language" questions.  That would also let us support languages that AMO isn't translated into.  It raises more questions though:

1) What if they have "xx" in their accept lang and the add-on supports "xx" but AMO doesn't know what "xx" is - it won't have the full name for that locale to show.  On the dictionary download page we just show the locale.

2) What if their accept-lang is xx,yy,zz and AMO supports a combination of the above (do we bold two languages?, etc.)

3) What if their accept-lang is xx-AA and the add-on supports xx-BB?  How about if the add-on supports xx?  What about the reverse scenario where the accept-lang is more generic than the add-on?

These aren't blocker questions and getting something out is better than nothing, but it doesn't hurt to consider.
3)

Comment 26

[Dave Garrett]

WRT locale codes, there's also the issue where an addon supports locale xx but uses the locale code xx-AA unnecessarily. (e.g. fr-FR instead of just fr) In the past Babelzilla listed almost every locale with a dialect code but not too long ago we migrated to only using dialect codes for those locales that expect it always or have multiple common dialects. (e.g. just fr, but pt-PT & pt-BR) Since the old convention of always using a dialect code was in effect for so long, there are many addons who have not yet migrated to the newer system (and may never). As a result, you'll probably want to keep a list of codes with commonly used redundant/unneeded/deprecated dialect codes so that, for example, fr is recognized as equivalent to fr-FR and vice versa. Ones of the form xy-XY are the most common (and easiest to catch), but others such as fa-IR now go by just fa (Farsi/Persian) and el-GR goes by just el (Hellenic/Greek).

(In reply to comment #25)
> We could key this off accept-locale on the front end without messing with
> any of the "are they browsing in the right language" questions.  That would
> also let us support languages that AMO isn't translated into.

Good solution.

> 1) What if they have "xx" in their accept lang and the add-on supports "xx"
> but AMO doesn't know what "xx" is - it won't have the full name for that
> locale to show.  On the dictionary download page we just show the locale.

There's no reason we couldn't make up a complete list. Wikipedia looks like it has a thoroughly exhaustive list for the language codes: http://en.wikipedia.org/wiki/List_of_ISO_639-1_codes

For the dialect code showing the region in the parenthetical would require a bit more effort as you'd have to get a list of native names for all the countries. Wikipedia has a full list of all codes, and each country's page has its native name, but I don't know of a full list off-hand. http://en.wikipedia.org/wiki/ISO_3166-2

> 2) What if their accept-lang is xx,yy,zz and AMO supports a combination of
> the above (do we bold two languages?, etc.)

I think recent CSS allows for variable font weight. Maybe have the primary in bold text and additional ones in less bold text?

> 3) What if their accept-lang is xx-AA and the add-on supports xx-BB?

Assuming it's not one of the type I mentioned where we should consider certain xx equivalent to xx-AA, then that this case would simply be a lack of support. Someone might be able to muddle through if the dialects are similar enough, but some languages have dialects so different as to be a problem. Rather than try and figure out anything here, I'd say just list it as not supported and let people look at the full list to make their own determination.

> How about if the add-on supports xx?  What about the reverse scenario where the
> accept-lang is more generic than the add-on?

Frequently an accept-lang will have both xx and xx-AA (e.g. en & en-US). I'm not sure what the convention is when it doesn't, but whatever is done for webpage locale picking should probably be done with this too.

Comment 27

[Axel Hecht [:Pike]]

There's a ton of answers around this in the bcp47 project, https://wiki.mozilla.org/User:GPHemsley/BCP_47. That's for gecko code, but the data files would be the same, at least in semantics. Also, the locale code matching logic should be bcp47, and deal with all the details (like script codes etc).

Comment 28

[Wil Clouser [:clouserw]]

Thanks for filing this.  As you can see, it hasn't received much traction as 100% of the AMO team has been focused on other projects for a couple years now.

In an effort to not drown in existing reports we're aggressively closing old enhancements and bugs to get the buglist to a reasonable level so we can scope and process bug sprints in an effective manner.

Patches for this bug are still welcome.