Re: Assuming app locale support from the manifest

Hi,
I agree with you on three points:
- a new "content locales" field would probably end up being a copy of 
the current locales field, so it's not useful
- I don't see any use cases for metadata being localised but not the content
- localising the metadata and not the content would be detrimental to 
the app's ratings, having good localisation into the advertised 
languages will be rewarded by the market

Having these in mind, do you still feel we should put all localisation 
into the manifest? I'm not saying this would be a bad solution, I just 
don't see its benefits when compared to for example Widget's solution 
(http://www.w3.org/TR/widgets/#internationalization-and-localization)


/Janusz

On 2013-04-23 17:08, Wil Clouser wrote:
> We couldn't be *sure* but that's not as critical as it sounds.  As long
> as the developer is aware of the assumption (having the locale key means
> supporting the locale), they ignore it to the detriment of their own
> ratings and reviews.  If a person buys an app with Spanish metadata and
> the entire app is in German their next steps are refund (if possible)
> and then to give it a poor review.
>
> We won't have a perfect solution here just because there are degrees of
> localization.  As you mentioned, someone could localize only part of the
> strings, or even all of the strings but none of the number formats or
> currencies.  The idea would be, if they advertise the app in that
> language (here, advertise means they localized the name/description)
> then they are calling the localization "reasonable" - a word with some
> wiggle room anyway.
>
> A new field in the manifest list would be another way of accomplishing
> this and one that didn't overload an existing key, however, I'm not sure
> what it would accomplish other than making developers add another field
> with the same keys in it.  Are there use cases for metadata to be
> localized but not the app itself?
>
> The change in manifest causing an app update is unfortunate but a
> reality of the app framework.  New languages are an update.  If the
> developer is concerned about update fatigue they should push the
> language updates out with feature updates - a common paradigm among
> other desktop and mobile software already.
>
> Wil
>
> On 04/23/2013 01:06 AM, Janusz Majnert wrote:
>> Hi,
>> I think that the localisation scheme that you're proposing will not meet
>> your requirements.
>> First of all, you can never be sure that the application was localised
>> properly, regardless of the scheme you use. In your solution, you can
>> only suspect that if the developer included strings for some locale,
>> that locale is supported. This will not prevent the developer from
>> localising only part of their content. Ultimately, the user experience
>> of using an app is entirely on the developer.
>> However, you are right that we currently don't give the developer any
>> means of expressing which locales are supported by their application. I
>> think it would be useful to add a new field to the manifest that lists
>> the available locales of the app's content.
>>
>> There is a problem with putting this info in the manifest though - if a
>> locale is added, the manifest will have to be updated, which will most
>> probably trigger application update for users that already have it
>> installed. An update like that would be of no value for users that
>> already use the locale that they prefer.
>>
>> /Janusz
>>
>> On 2013-04-22 07:49, Wil Clouser wrote:
>>> Hi,
>>>
>>> The Firefox Marketplace team has been improving its language support on
>>> the site and have come across a question regarding app locale support.
>>> There are two areas to consider:
>>>
>>>      1) Localization of the app metadata (the name, description, etc.)
>>> and
>>>      2) localization of the application itself (the UI in the app, the
>>> data it shows, etc.).
>>>
>>> App manifests currently support an optional 'locales' field[1] allowing
>>> developers to address #1 easily.  However, I haven't seen any
>>> consideration for #2, telling end users about L10n inside the app
>>> itself.
>>>
>>> In an effort to minimize the work for developers, we'd like to suggest a
>>> change to the meaning of the 'locales' field in the manifest from it's
>>> current implication of "Here is a translation of metadata for my
>>> application in a locale." to "Here is a translation of metadata for my
>>> application *and* my application itself is localized for this locale."
>>> Revealing this information in the manifest provides much needed
>>> information for a consumer.  It's a poor user experience to see an app
>>> localized in a marketplace, buy the app, and after installing see that
>>> the app merely provided a translated description but no other content.
>>>
>>> Proactively enforcing this policy won't scale (if for no other reason
>>> than defining what it means for an app to be localized) but strongly
>>> recommending it in the spec will guide the majority of developers and
>>> allow marketplaces to make decisions based on that.  For example, adding
>>> filters to a search to show only localized apps for a language.
>>>
>>> A suggestion for text to add to the locales section in the manifest
>>> spec:
>>>
>>>  > By adding a locale key to the locales field you are declaring that
>>>  > your app is localized for that locale and will perform in a
>>> reasonable
>>>  > fashion for clients using that locale.
>>>
>>> Thoughts?
>>>
>>> Wil
>>>
>>> [1] https://developer.mozilla.org/en-US/docs/Apps/Manifest#locales
>>>
>>>
>>>
>>
>>
>
>

Received on Tuesday, 23 April 2013 15:37:57 UTC