911012 - Sort the apps in the marketplace by languages

Status: RESOLVED WONTFIX

(Marketplace Graveyard :: General, enhancement, P5)

Description

[Andrew Truong [:feer56] [:andrewtruong] [:atruong]]

Not sure if there is a bug on this already but the Marketplace is full over apps that are with different languages. The user should be able to sort what language of app they would like to see. 
*ALL
*Spanish
*Chinese
*English
*German 
*ETC.

Comment 1

[Wil Clouser [:clouserw]]

Can you give us the URL you're seeing with all the different languages?

Comment 2

[David Bialer [:dbialer]]

UX team and I have discussed the 'language' issue - and whether we should 'sort' or have a user set a preference.  Currently users in Colombia are seeing mostly apps in English because the developer checked off the Colombia box.  However, while the developer of an English-language-only app may desire to have their app in Colombia, it turns out that many users don't necessarily have a desire to see apps in languages they don't understand.  Furthermore they may not be able to tell if the app itself actually supports the their language.

Here is the proposal with several variations:
1. Allow users to set their language-of-app preference which should probably default to the language setting of their device and/or country.  Then allow them to either
variation a) allow then to select a single language or ALL languages
variation b) or allow them to multi-select languages. Each language is either selected or deselected.
variation c) allow users to select a sort order for selected or selected languages.

The user should be able to do this in their settings rather than in an app listings.

The initial settings would be from the default language of the region.  But a user can change this and have it persist.

Additionally, we may consider displaying, in fine print on the details page, 'languages supported"

Comment 3

[Andrew Truong [:feer56] [:andrewtruong] [:atruong]]

(In reply to Wil Clouser [:clouserw] from comment #1)
> Can you give us the URL you're seeing with all the different languages?

This is on my Keon but also found here: https://marketplace.firefox.com/search?sort=created

Comment 4

[Bram Pitoyo [:bram]]

For better or worse, the concept of language is tied in to both the phone language (modifiable under Settings app) and Marketplace region (modifiable under settings on the web, but perhaps we should rename this to country to avoid confusion).

I may have the wrong assumption here, but what I think we already do today when user first accesses the Marketplace is first take the phone’s language information and try to match this value with an existing region that Marketplace supports.

If we find a match, then we set the Marketplace’s country to the phone’s language. If we don’t, then we would select English as a fallback?

Either way, I think that the central conflict here has to do with differing mental models between sellers and consumers.

Today, we ask sellers to pick countries where their app should be made available. We know that the list of countries depend on payment operators, payment methods and price tiers. The thing is, while a seller might have an app that’s written in English, when he selects Colombia as a country, he expects that app to be shown to /every/ user who had selected “Colombia” as a country in Marketplace. Not just the Spanish or English speakers.

Contrast this with the customer’s mental model, which is “I want to only see apps that are relevant to me”.

For a subset of customers, “relevant” means “in my mother language”. For another subset, “relevant” means “in my mother language and English” or “in my mother and secondary language only”.

Yet another subset of customers prefers to access the interface in English at all times. This is the case in Indonesia, where English is perceived as being more accurate at explaining technical terms. Or in fact, many technical words are simply transliterated from English. Hence, many Indonesians prefer to access sites like Facebook, Twitter or their mobile phone UI in English, even though an interface in Bahasa Indonesia is already available.

My conclusion: the mental model mismatch happens because we don’t offer a tool for sellers to target by language. When we allow sellers to sell their app to a specific language in a specific country, then we can offer the same control to the users. Otherwise, a lot of app makers who wants to sell internationally might wonder why their apps don’t appear when they select a certain country, even though they have checked that country in the list.

Another alternative might be to implement a logic that would forbid making an English app available in Spanish-speaking country, unless it’s been translated to the es (Español) locale.

Although I can’t help but wonder if very exacting control and stricter policy would prevent a lot of developers from wanting to develop for our Marketplace, because of the perceived limited distribution opportunity.

tl;dr – It’s not an easy problem to wrangle, unless we give sellers the same targeting controls that consumers will have for filtering apps

Comment 5

[Matt Basta [:basta]]

see also https://bugzilla.mozilla.org/show_bug.cgi?id=897579

Comment 6

[Bram Pitoyo [:bram]]

Running the risk of overthinking this problem at too deep of a level, here are two blog posts from MSDN that may be good food for thought. They both talk about l10n, i18n, and the idea of language vs. country vs. locale.

I struggled with this problem early on, too, when I started working on Marketplace. Back then, it included country vs. language vs. currency. I had since put it on the backburner because of other issues that need attention, but perhaps it’s worth it to bring up again.

http://blogs.msdn.com/b/shawnste/archive/2011/11/09/user-locale-system-locale-ui-language-language-profile-amp-all-that.aspx

http://blogs.msdn.com/b/michkap/archive/2012/07/13/10329490.aspx

Comment 7

[Tony Santos [:tsmuse]]

The idea I pitched to David around this problem was a progressive-fall-back system (for lack of a better term.)

Example: If I am a Spanish speaking consumer and I have set my default language to Spanish (i.e. the Marketplace UI is in Spanish) then my results should be sorted so Spanish language apps are always displayed first, followed by other languages that I may or may not speak. 

This allows us to avoid the problem of a user checking a box or selecting a drop-down that gets them a bunch of "There are no results that match that query" style pages. Language preference is also something we shouldn't make the user tell us again, (at least on FFOS, I'm not sure how the language thing works on Android or on the desktop) if the Marketplace app knows what language to present itself to a consumer in, it should also be prioritizing apps that are translated into that language. This provides both a better, and more customized, consumer experience and an incentive for App makers to translate their apps.

Comment 8

[David Bialer [:dbialer]]

I think we should prioritize language by default language of the Region (country) setting.  Presumably if a user has the region set, even if the language of the device is set differently, I would interpret that setting to mean that they are interested in apps for the country as well as the language of the region.  

Secondarily, if different, it would be current language of the device.  And third, if not in the above, would be English.

Not quite sure how to prioritize after that or if we need to.

Does that order make sense?  1)region setting language, 2) device language, 3) English (as the language right now with the most apps).

Comment 9

[Tony Santos [:tsmuse]]

The main problem I see with setting language filters by region is that a consumer may visit a region where she doesn't speak the local language, which would mean apps in the local language would be totally worthless to her. For example: I don't speak Japanese. If I traveled to Japan I would be interested in seeing content about Japan (this is an unrelated thing we're discussing in the feed design stuff, BTW, local apps based on where I currently am in the physical world) but I would still want all my apps in English, because it's the language I speak.

Comment 10

[Rob Hudson [:robhudson]]

I was thinking how we might implement this and I think we're missing some fundamental data.

While we do store what we call "supported_locales", which is the list of locales the manifest contains, that is no guarantee that the app itself is localized in these locales. For one app it may be true that if the manifest has translations for the name and description in Portuguese (supported_locales includes "pt") AND the app itself has strings translations for Portuguese, another app may only have translations for the manifest and not the app itself. As far as Marketplace can see currently they support the locale the same.

There may be some app submission rules that if you list a locale in your manifest your app must also support that locale, but I'm not aware of one. I imagine it would be very impractical for the reviewers to check every locale during review even if there were a rule.

(In reply to David Bialer [:dbialer] from comment #2)
> 
> Here is the proposal with several variations:
> 1. Allow users to set their language-of-app preference which should probably
> default to the language setting of their device and/or country.  Then allow
> them to either
> variation a) allow then to select a single language or ALL languages
> variation b) or allow them to multi-select languages. Each language is
> either selected or deselected.
> variation c) allow users to select a sort order for selected or selected
> languages.

Isn't this essentially what the Accept-Language header's job is? Which is built into all browsers and presumably FirefoxOS as well based on the device settings.

> Additionally, we may consider displaying, in fine print on the details page,
> 'languages supported"

As mentioned above, we have "supported_locales" based on the manifest, but that is no guarantee that the app itself is localized. I think it would be a bad idea to display this if we have no guarantee that it applies to anything more than the manifest content.

(In reply to Tony Santos [:tsmuse] from comment #7)
> The idea I pitched to David around this problem was a progressive-fall-back
> system (for lack of a better term.)
> 
> Example: If I am a Spanish speaking consumer and I have set my default
> language to Spanish (i.e. the Marketplace UI is in Spanish) then my results
> should be sorted so Spanish language apps are always displayed first,
> followed by other languages that I may or may not speak. 

Our category listing pages currently have tabs for "Popular" and "New". If we added one for language preference and put those where the user's language preference is found in our "supported_locales" list at the top, this could work. But again, the app itself may not support that locale and by implementing this it seems like we are suggesting that it does, which may lead to more complaints than not having this option?

Comment 11

[Matt Basta [:basta]]

We had the manifest spec amended so that any locale in the "locales" field indicates that the app is translated into that locale. The review guidelines should have been updated by now to reflect that; any app that includes a translation in the manifest but not in the app itself should be rejected, IIRC.

> (In reply to David Bialer [:dbialer] from comment #2)
> > 
> > Here is the proposal with several variations:
> > 1. Allow users to set their language-of-app preference which should probably
> > default to the language setting of their device and/or country.  Then allow
> > them to either
> > variation a) allow then to select a single language or ALL languages
> > variation b) or allow them to multi-select languages. Each language is
> > either selected or deselected.
> > variation c) allow users to select a sort order for selected or selected
> > languages.
> 
> Isn't this essentially what the Accept-Language header's job is? Which is
> built into all browsers and presumably FirefoxOS as well based on the device
> settings.

We use navigator.language in the Marketplace and that's been completely sufficient.

The most reasonable solution here is to say 1) only apps in your language 2) all apps. Allowing the user to choose individual languages is overkill IMO, and it complicates things technically.

> (In reply to Tony Santos [:tsmuse] from comment #7)
> > The idea I pitched to David around this problem was a progressive-fall-back
> > system (for lack of a better term.)
> > 
> > Example: If I am a Spanish speaking consumer and I have set my default
> > language to Spanish (i.e. the Marketplace UI is in Spanish) then my results
> > should be sorted so Spanish language apps are always displayed first,
> > followed by other languages that I may or may not speak. 
> 
> Our category listing pages currently have tabs for "Popular" and "New". If
> we added one for language preference and put those where the user's language
> preference is found in our "supported_locales" list at the top, this could
> work.

"New" really can't be sorted by "New" if we're sorting by something else. When do we stop showing "new" Spanish apps and start showing "new" non-Spanish apps? Same with popular: at what point do we stop showing "popular" Spanish apps and start showing "popular" non-Spanish apps?

If there are fifty Spanish apps that have 10 installs, do we still show them as "popular" before the non-Spanish apps that have 10K installs? At what point do we say, "No, this localized app shouldn't be shown ahead of unlocalized apps."? What about apps with five installs? One install? Is a localized app with one install more relevant to a user than an unlocalized app with literally five orders of magnitude more installations?

I fear that pre-sorting the lists isn't a feasible concept.

Comment 12

[Rob Hudson [:robhudson]]

(In reply to Matt Basta [:basta] from comment #11)
> We had the manifest spec amended so that any locale in the "locales" field
> indicates that the app is translated into that locale. The review guidelines
> should have been updated by now to reflect that; any app that includes a
> translation in the manifest but not in the app itself should be rejected,
> IIRC.

That's a good step. But verifying each locale and rejecting is a lot of work for the reviewers. Are we doing this currently as part of the review process? I'm not sure we are.

> "New" really can't be sorted by "New" if we're sorting by something else.
> When do we stop showing "new" Spanish apps and start showing "new"
> non-Spanish apps? Same with popular: at what point do we stop showing
> "popular" Spanish apps and start showing "popular" non-Spanish apps?
> 
> If there are fifty Spanish apps that have 10 installs, do we still show them
> as "popular" before the non-Spanish apps that have 10K installs? At what
> point do we say, "No, this localized app shouldn't be shown ahead of
> unlocalized apps."? What about apps with five installs? One install? Is a
> localized app with one install more relevant to a user than an unlocalized
> app with literally five orders of magnitude more installations?
> 
> I fear that pre-sorting the lists isn't a feasible concept.

I agree with the above.

For searches it's possible to add a little boosting if the requesting user's locale matches one in the "supported_locales" so that if there are 2 equivalently scored apps the one with the matching locale would appear higher. This wouldn't trump other relevance based on the search terms per se by may help a little?

I'm not sure what we'd do for the "Popular" or "New" tabs.

Also, we have regional popularity information and the code to support sorting by popularity in a specific region. It's not activated yet because no region has enough apps yet to be considered "mature". But when it is activated, I'd wager that the "Popular" tab will show more apps specific to the user's region which should be ones with localizations in that region or content local to that region.

Comment 13

[David Bialer [:dbialer]]

If I understand:
1. Have a user setting where a user can set ALL or 1 language.  Defaults to the region language (or possibly ALL?)  This simplifies things and prevents having to sort by language.
2. Popular (future "Trending" or "Hotness") If a language set, only have apps in that language.  Otherwise, if ALL is selected, the list order will take care of itself through a "natural selection" process by the region - where presumably or eventually Spanish language apps will show up as the most popular for a Spanish-speaking region.  It naturally will show other language apps if they are popular in that region.
3. New - If a language is selected, only show new apps which have a supported_local and is new.  If all then show all.
4. Search - boost by locale.  Also, I am working on Search and am going to suggest we use Keywords (higher boost) over descriptions to prevent keyword overloading in descriptions.  We may have keywords for each language.
5. User Reviews - not sure how we do language today.  User reviews are by region right?  So perhaps not a big problem if that is the case.

The reviewers will not be reviewing for language but, as the reviewers are multinational, will expect the app to work in the language of their review.  It *can* be rejected if the manifest is incorrect or disabled if discovered not to support a language it claims to until the problem is corrected.

Comment 14

[Rob Hudson [:robhudson]]

(In reply to David Bialer [:dbialer] from comment #13)
> 2. Popular (future "Trending" or "Hotness") If a language set, only have
> apps in that language.  Otherwise, if ALL is selected, the list order will
> take care of itself through a "natural selection" process by the region -
> where presumably or eventually Spanish language apps will show up as the
> most popular for a Spanish-speaking region.  It naturally will show other
> language apps if they are popular in that region.

Popular is distinct from Trending (aka "hotness") at the moment. But both will support per-region once that region is "mature".

If what's in comment #13 is what we all agree on, it's a great break down and would be nice to be split them off into separate implementation bugs as written.

Comment 15

[Tony Santos [:tsmuse]]

(In reply to David Bialer [:dbialer] from comment #13)
> If I understand:
> 1. Have a user setting where a user can set ALL or 1 language.  Defaults to
> the region language (or possibly ALL?)  This simplifies things and prevents
> having to sort by language.

Again I would caution against relying on region data to pick a default language, as people can easily move between regions without speaking the native language in that region. I think if we add a language preference to the account settings, and give apps in that language preference that would be rad though. The main thing we don't want to do is ask every time what the language is, esp if the Marketplace UI is already displaying in their preferred language. 

> Is a localized app with one install more relevant to a user than an unlocalized app with literally five orders of magnitude more installations?

I think the answer for someone who doesn't speak the language of the app with more installs, the answer is yes. There are obviously exceptions to this, some non-story heavy games for example, but for the vast majority of apps, if I can't read what it's showing me, the fact that it has N thousands of installs doesn't matter, I still can't read the UI to be able to use it.

Comment 16

[David Bialer [:dbialer]]

(In reply to Tony Santos [:tsmuse] from comment #15)
> (In reply to David Bialer [:dbialer] from comment #13)
> > If I understand:
> > 1. Have a user setting where a user can set ALL or 1 language.  Defaults to
> > the region language (or possibly ALL?)  This simplifies things and prevents
> > having to sort by language.
> 
> Again I would caution against relying on region data to pick a default
> language, as people can easily move between regions without speaking the
> native language in that region. I think if we add a language preference to
> the account settings, and give apps in that language preference that would
> be rad though. The main thing we don't want to do is ask every time what the
> language is, esp if the Marketplace UI is already displaying in their
> preferred language. 

Yes.  I was thinking we use the region setting as a default on first run - same as the UI language setting which it picks up from the phone. This seems like a reasonable default option.  But the user can change the setting to allow them to move between. One of the language settings is ANY LANGUAGE (all).
> 
> > Is a localized app with one install more relevant to a user than an unlocalized app with literally five orders of magnitude more installations?
> 
> I think the answer for someone who doesn't speak the language of the app
> with more installs, the answer is yes. There are obviously exceptions to
> this, some non-story heavy games for example, but for the vast majority of
> apps, if I can't read what it's showing me, the fact that it has N thousands
> of installs doesn't matter, I still can't read the UI to be able to use it.
If we have a user setting for ANY LANGUAGE then the user can change should they be open to popular apps in other languages.

Comment 17

[Matt Basta [:basta]]

The Marketplace's default locale should be whatever the phone's global locale is set to. There's absolutely no reason the Marketplace should behave any differently by default than any other app that comes bundled with the device.

It should be noted that the Play store also uses the phone's global language as the default language.

From a technical side, we don't have the ability right now to change the UI language on the fly (you need to hard-close the Marketplace and reopen it, if we had the option). So any language selection would only affect apps and not the Marketplace itself.

Offering to allow the user to choose an arbitrary language or set of arbitrary languages seems excessive and confusing. If I change the language setting to Portuguese, I'd expect everything to be in PT, but only the apps will be. If I have the option to select multiple languages and PT and ES, what happens to the Marketplace will confuse at least some subset of users no matter what.

I think the most reasonable solution here is to simply add an option to say "Don't filter my results by langauge, show me everything." Apps are sorted/filtered by language by default and checking that option in the Settings page turns the sorting/filtering off.

Is there really a need for anything more complicated?

Comment 18

[Christopher Van Wiemeersch [:cvan]]

I agree with Basta's comment 17. The feature requested here is actually what the browser's "q" values in the "Accept-Language" header are meant for.

http://f.cl.ly/items/1R2m0J1901353i3x2a2B/Screen%20Shot%202013-09-11%20at%2010.41.50%20AM.png

If your browser allows you to specify multiple lanuages, Firefox will include the "q" values when passing that info to the client. If we want support for language fallbacks, this is something for the browser/Firefox OS to handle.