What's the qualifier for variant language field?

[Joan Montané]

Hi all,

Please, point me to the correct place if this list is not the correct one for asking about Android locale features, thanks.

I'm interested in Android resources management system and locale issues. Primary in path qualifiers described here [1].

Is there some way to provide different resources for locales with or without variant [2] language field? For instance, to provide different translation menus for en-US and en-US-POSIX locales.

If this feautre is not available, is it planned in the roadmap?

Thanks in advance.

Yours,

Joan Montané

[1] http://developer.android.com/guide/topics/resources/providing-resources.html

[2] http://developer.android.com/reference/java/util/Locale.html

[Dianne Hackborn]

Sorry I don't understand what you are looking for.  What does "en-US-POSIX" mean?

--
Dianne Hackborn
Android framework engineer
hac...@android.com

Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails.  All such questions should be posted on public forums, where I and others can see and answer them.

[Joan Montané]

2011/4/1 Dianne Hackborn <hac...@android.com>:

> Sorry I don't understand what you are looking for.  What does "en-US-POSIX"
> mean?

Hi,

sorry if my previous mail was short, my English can be much better.

Usually locale codes are tagged with one or two fields. First field is
for ISO language code (en, es, fr, de, ....) and second field is used
for country ISO code (US, FR, CA, MX, ...). So, locales codes like
en-US means English from USA, es-MX means Spanish from Mexico and
fr-CA means French from Canada.

There is also a 3rd optional field, variant tag. According to [1], we
can create and use a locale language code with or without variant tag.
For instance: en-US-POSIX (Computer English at USA), en-UK-SCOTLAND
(Scottish English at United Kingdom) or ca-ES-VALENCIA (Valencian
Catalan at Spain). Android localization system supports variant tag.

According to [2] and [3], we can use several resource qualifiers to
provide different translation for different locales codes. For
instance en, en-US or en-UK
values-en/ (for default English)
values-en-rUS/ (for English at USA)
values-en-rUK/ (for English at UK)
values-fr-rFR/ (for French at France)
values-fr-rCA/ (for French at Canaa)

My question is about provide different translation for locales with
variant tag. Is it possible to provide such translation? Does Android
Resources management system support variant language tag? Is it in the
roadmap?

If I have a locale defined with variant tag, such en-US-POSIX, witch
it can be done. Then, how can we provide different resources from
en-US?

values-en-rUS/ (for English from USA)
values-en-rUS-?????????/ (for Computer English at USA)

I hope my question was clear now.

Note: I used - char as fields separator, may be it's better to use _
char in Android environment.

Regards,

Joan Montané

[1] http://developer.android.com/reference/java/util/Locale.html
[2] http://developer.android.com/guide/topics/resources/localization.html
[3] http://developer.android.com/guide/topics/resources/providing-resources.html

[Dianne Hackborn]

Sorry no we do not support variants.

[Joan Montané]

2011/4/1 Dianne Hackborn <hac...@android.com>:

> Sorry no we do not support variants.
>

Ok, I expected this answer, :-(

Is there any chance to implement it in future Android relases?

I'm interested in translating apps for a language variant, so I need
variant tag suport. Another aproach can be to create an alias from
xx-YY-zzzzz to xx-HH, where xx means a language code, YY and HH mean
country code and zzzzz means a variant tag.

Can you point me to source files needed to add any of following two features?
First feature, and better, adding variant suport for Android l10n system
Second feature, a workarround, creating an alias from xx-YY-zzzz to xx-HH

Where I can find a good description about Android resource qualifier
sourcecode?

Thanks,

Joan Montané

[Joan Montané]

2011/4/1 Dianne Hackborn <hac...@android.com>:
> Sorry no plans at this point; it would be very low on the priority list, and
> to be  honest if when you are talking about variants as a somewhat arbitrary
> thing then I just think this is not something that is a good fit for the
> resource system.
> The core resource matching is in ResourceTypes.h and ResourceTypes.cpp.
>

Thanks for your quick answers.

Regards,

Joan Montané

[Dianne Hackborn]

Sorry no plans at this point; it would be very low on the priority list, and to be  honest if when you are talking about variants as a somewhat arbitrary thing then I just think this is not something that is a good fit for the resource system.

The core resource matching is in ResourceTypes.h and ResourceTypes.cpp.

[enh]

On Fri, Apr 1, 2011 at 13:05, Dianne Hackborn <hac...@android.com> wrote:
> Sorry no plans at this point; it would be very low on the priority list, and
> to be  honest if when you are talking about variants as a somewhat arbitrary
> thing then I just think this is not something that is a good fit for the
> resource system.
> The core resource matching is in ResourceTypes.h and ResourceTypes.cpp.

his examples weren't very convincing, but there are convincing
examples of why we should support the full extent of BCP-47 language
tags (introduction here:
http://www.w3.org/International/articles/bcp47/). i'm hoping that when
we fix the resource format to support three-letter language codes
(which is already preventing us [Google] from shipping localization
work we've already done), we'll go the whole hog. that is, rather than
expand the fixed-width field, we should switch to a variable-length
string.

there's at least one internal bug for this, but i don't think anyone's
actively working on it. (java.util.Locale needs work too, for full
BCP-47 support, and i haven't started on that yet either.)

as for the "xx-HH" hack of abusing currently-unused language and
country codes, that's a terrible idea. we're already paying for that
mistake with Hebrew, for example, and the last thing anyone needs is
more of that pain.

--
Elliott Hughes - http://who/enh - http://jessies.org/~enh/

[Dianne Hackborn]

This isn't a matter of payment, it is a matter of prioritizing amongst a *huge* number of other things that are desired.

Also as I said the current resource system does not lend itself to this, since it has a fundamental assumption that resource configurations can be expressed as fixed-length values.

On Sat, Apr 2, 2011 at 12:07 AM, Pau Iranzo <paul...@gmail.com> wrote:

Hi,

The ISO-639 [1] defines the locale codes for all the languages defined
by languagecodi_COUNTRYCODE.

The BCP47 [2] is an standard that is already working in most of the
Free Software Projects [3] and let us implement Valencian variant
translations of the Catalan language using the locale code
ca_ES-valencia/ca-valencia. Meego already let us translating the OS
into this variant [4].

I know that the priority of implementing this standard for language
subtags is very low, but it's a shame that Android ignores it. Here is
a question for you (developers): if we were to pay, how much would it
cost to implement language subtags?

Thanks,

Pau

[1] http://www.sil.org/ISO639-3/codes.asp

[2] http://www.iana.org/assignments/language-subtag-registry

[3] http://l10n.gnome.org/languages/ca%40valencia/
http://i18n.kde.org/stats/gui/trunk-kde4/team/ca@valencia/
https://translations.launchpad.net/ubuntu/natty/+lang/ca@valencia

[4] http://meego.transifex.net/projects/p/meego/team/ca@valencia/



2011/4/1 enh <e...@google.com>:

[Pau Iranzo]

Hi,

The ISO-639 [1] defines the locale codes for all the languages defined
by languagecodi_COUNTRYCODE.

The BCP47 [2] is an standard that is already working in most of the
Free Software Projects [3] and let us implement Valencian variant
translations of the Catalan language using the locale code
ca_ES-valencia/ca-valencia. Meego already let us translating the OS
into this variant [4].

I know that the priority of implementing this standard for language
subtags is very low, but it's a shame that Android ignores it. Here is
a question for you (developers): if we were to pay, how much would it
cost to implement language subtags?

Thanks,

Pau

[1] http://www.sil.org/ISO639-3/codes.asp

[2] http://www.iana.org/assignments/language-subtag-registry

[3] http://l10n.gnome.org/languages/ca%40valencia/
http://i18n.kde.org/stats/gui/trunk-kde4/team/ca@valencia/
https://translations.launchpad.net/ubuntu/natty/+lang/ca@valencia

[4] http://meego.transifex.net/projects/p/meego/team/ca@valencia/

2011/4/1 enh <e...@google.com>:

[Vicent]

Hello.

I would like to point out the fact that, to the best of my knowledge,
currently there are ONLY 54 (fifty-four!!!) language "variants" that
are officially recognised by the IANA Subtag Registry —see here:
http://people.w3.org/rishida/utils/subtags/index.php?list=8&submit=List

And, honestly, I don't think many people is going to ask for Android
in "1606nict" variant of French (Late Middle French (to 1606)), but
there may be many people that would like Android to speak to them in
their own language (variant, I mean).

"Only 54" may seem a reason for not suporting "variants", but I think
it really means only support for "Valencian" and some other "popular"
variants ("Scottish English", for instance) would be actually needed.
Maybe an ad-hoc "hack" for them would be a possible solution, don't
you think so???

--
vicent

> > > On Fri, Apr 1, 2011 at 13:05, Dianne Hackborn <hack...@android.com>

> > wrote:
> > >> Sorry no plans at this point; it would be very low on the priority list,
> > and
> > >> to be  honest if when you are talking about variants as a somewhat
> > arbitrary
> > >> thing then I just think this is not something that is a good fit for the
> > >> resource system.
> > >> The core resource matching is in ResourceTypes.h and ResourceTypes.cpp.
>
> > > his examples weren't very convincing, but there are convincing
> > > examples of why we should support the full extent of BCP-47 language
> > > tags (introduction here:
> > >http://www.w3.org/International/articles/bcp47/). i'm hoping that when
> > > we fix the resource format to support three-letter language codes
> > > (which is already preventing us [Google] from shipping localization
> > > work we've already done), we'll go the whole hog. that is, rather than
> > > expand the fixed-width field, we should switch to a variable-length
> > > string.
>
> > > there's at least one internal bug for this, but i don't think anyone's
> > > actively working on it. (java.util.Locale needs work too, for full
> > > BCP-47 support, and i haven't started on that yet either.)
>
> > > as for the "xx-HH" hack of abusing currently-unused language and
> > > country codes, that's a terrible idea. we're already paying for that
> > > mistake with Hebrew, for example, and the last thing anyone needs is
> > > more of that pain.
>

> > >> On Fri, Apr 1, 2011 at 12:23 PM, Joan Montané <j...@montane.cat> wrote:
>
> > >>> 2011/4/1 Dianne Hackborn <hack...@android.com>:

> > >>> > Sorry no we do not support variants.
>
> > >>> Ok, I expected this answer, :-(
>
> > >>> Is there any chance to implement it in future Android relases?
>
> > >>> I'm interested in translating apps for a language variant, so I need
> > >>> variant tag suport. Another aproach can be to create an alias from
> > >>> xx-YY-zzzzz to xx-HH, where xx means a language code, YY and HH mean
> > >>> country code and zzzzz means a variant tag.
>
> > >>> Can you point me to source files needed to add any of following two
> > >>> features?
> > >>> First feature, and better, adding variant suport for Android l10n
> > system
> > >>> Second feature, a workarround, creating an alias from xx-YY-zzzz to
> > xx-HH
>
> > >>> Where I can find a good description about Android resource qualifier
> > >>> sourcecode?
>
> > >>> Thanks,
>
> > >>> Joan Montané
>
> > >> --
> > >> Dianne Hackborn
> > >> Android framework engineer

> > >> hack...@android.com

>
> > >> Note: please don't send private questions to me, as I don't have time to
> > >> provide private support, and so won't reply to such e-mails.  All such
> > >> questions should be posted on public forums, where I and others can see
> > and
> > >> answer them.
>
> > > --

> > > Elliott Hughes -http://who/enh-http://jessies.org/~enh/

>
> --
> Dianne Hackborn
> Android framework engineer

> hack...@android.com