Re: [android-developers] Re: how to get a list of locales supported by device we're running on

[Latimerius]

On Tue, Aug 13, 2013 at 11:45 PM, Kostya Vasilyev wrote:

> So you have an HTC... I've got two on my desk, and the language / locale
> list on both of them is region-specific:
>
> Russian (Russia, Ukraine, Georgia, other former Soviet republics)
> English (same list of countries)
>
> Other deivices I have (a couple of Samsungs purchased in Russia, another
> Samsung from a German mail-order, a Galaxy Nexus from the UK) have a much
> more complete list of languages, and they're listed without countries.
>
> So yeah, device manufacturer mods...
>

So, the conclusion seems to be that getLocales() can return locales that
are not actually supported, and vice versa, it might not return locales
that are supported.  For my purpose, which is to support the widest
possible range of languages by exploiting what's on device already (as
opposed to distributing own fonts), the API looks useless, and I'm not
aware of any other call that would give the correct answer.


> What if I knew Korean and wanted to use it as the default language on my
> device? :)
>

My bet is it would work on Samsungs and LGs, regardless of what L&I or
getLocales() say. ;-)

-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [android-developers] Re: how to get a list of locales supported by device we're running on

[Latimerius]

Apologies for replying to myself, just wanted add to my previous message
that I checked with my Optimus One.  On that device, the L&I menu seems to
match getLocales() output (some filtering similar to what LocalePicker does
notwithstanding), however as it turns out, when I switched our app to "zh"
which is *not* on the list, it worked anyway!


On Tue, Aug 13, 2013 at 10:50 PM, Latimerius  wrote:

> Admittedly it took a bit ;-) but I finally got around to taking a closer
> look.
>
> My HTC Desire show the following languages in its Languages&Input menu:
>
> English (United Kingdom)
> English (Ireland)
> French
> Italian
> Spanish
>
> Not a lot.  However, when I call
>
> Resources.getSystem().getAssets().getLocales();
>
> on the device, I get the following list:
>
> da
> ja
> nb
> de
> th
> fi
> el
> nl
> pl
> ko
> fr
> tr
> cs
> es
> it
> pt
> ru
> sv
> en_CA
> uk_UA
> en_ZA
> en_GB
> id_ID
> en_IE
> bg_BG
> ar_EG
> en_SG
> th_TH
> fi_FI
> sl_SI
> zh_HK
> sk_SK
> zh_CN
> hi_IN
> en_IN
> vi_VN
> ro_RO
> hr_HR
> ca_ES
> sr_RS
> en_US
> es_US
> lt_LT
> pt_PT
> en_AU
> hu_HU
> lv_LV
> zh_TW
> en_NZ
> fr_CA
> nl_BE
> fr_BE
> de_DE
> sv_SE
> de_CH
> fr_CH
> it_CH
> tl_PH
> de_LI
> da_DK
> he_IL
> ar_IL
> nl_NL
> pl_PL
> nb_NO
> ja_JP
> pt_BR
> fr_FR
> el_GR
> ko_KR
> tr_TR
> es_ES
> de_AT
> it_IT
> ru_RU
> cs_CZ
> en
> ar
> hu
> iw
>
> (Interestingly enough, calling Activity.getAssets().getLocales() returns
> almost the same list, just with "hi" appended.)
>
> When I switch my app to some of the languages which are *not* offered by
> the L&I menu but *do* appear on the getLocales() list, it turns out that
> some work (like Portuguese, German, Japanese, Chinese) and some don't
> (Hindi, Arabic). "Works" mean that legible text is displayed, "doesn't
> work" means that all glyphs are replaced with rectangles in the rendered
> text.
>
> I believe the LocalePicker code you linked to doesn't run on that device
> (or additional, much stricter filtering is applied elsewhere), and I'm
> still not sure how to filter the getLocales() list to remove languages that
> the device is actually not able to display.
>
>
> On Thu, Jun 13, 2013 at 6:22 PM, Latimerius  wrote:
>
>> Thanks, that's good info.  The reason I didn't check the source in this
>> case is, first, with min sdk of 7 that's a lot of source to check ;-) , and
>> second that this whole issue is fairly peripheral to our app.
>>
>> I'm wondering if I can be reasonably sure that this code (or an
>> equivalent) runs in a majority of devices.  Off-hand, it doesn't seem to
>> explain what e.g. Optimus One shows in its L&I menu (I'll do a detailed
>> check tonight or tomorrow).
>>
>>
>> On Wed, Jun 12, 2013 at 4:39 PM, Kostya Vasilyev wrote:
>>
>>> Settings app:
>>>
>>>
>>> https://android.googlesource.com/platform/packages/apps/Settings/+/refs/heads/master/src/com/android/settings/LocalePicker.java
>>>
>>> Uses this:
>>>
>>>
>>> https://android.googlesource.com/platform/frameworks/base/+/refs/heads/master/core/java/com/android/internal/app/LocalePicker.java
>>>
>>> It's basically Resources.getSystem().**getAsset**s().getLocales() which
>>> you'd already mentioned, but the code here does some filtering, to make the
>>> list look prettier -- which explains the different results.
>>>
>>> When in doubt, use the source :)
>>>
>>> -- K
>>>
>>> On Wednesday, June 12, 2013 5:55:35 PM UTC+4, Piren wrote:

 Your reasoning is sound, but you're barking at the wrong tree... What
 shows in Language & Input can be summed up to "This is what the company
 that made the specific ROM you're using wanted the users to see when they
 use the device", which has little affect on your app. Any language that
 shows there, will mean that you can support it as well, but that list is
 very short, much shorter than the actual list of supported locales and
 fonts. That list is usually just the default provided by google plus some
 of the leading languages used in the region the device is aimed for.

 By localization i meant - Modifications to the text so that a group of
 people would be able to understand it using their native language.
 If a device was localized to support Germany, it would obviously
 support the German language and have all of its interface display in
 German. However, it does not mean it supports all the Locales available in
 Germany (which might be different due to different dialects and customs).
 Basically what you're are aiming to do is add multiple localizations to
 your app and then intersect that list with the localizations the device can
 actually display (which is defined by its available fonts).

 Basically the list of support goes like:  Font > Locale >>
 Localizations   (where the Font supports more "options" than Locale and
 Locale support much more "options" than Localizations).

 Regarding the limitation that RTL languages offer and limitations like
 that - That is

Re: [android-developers] Re: how to get a list of locales supported by device we're running on

[Kostya Vasilyev]

So you have an HTC... I've got two on my desk, and the language / locale
list on both of them is region-specific:

Russian (Russia, Ukraine, Georgia, other former Soviet republics)
English (same list of countries)

Other deivices I have (a couple of Samsungs purchased in Russia, another
Samsung from a German mail-order, a Galaxy Nexus from the UK) have a much
more complete list of languages, and they're listed without countries.

So yeah, device manufacturer mods... What if I knew Korean and wanted to
use it as the default language on my device? :)

-- K


2013/8/14 Latimerius 

> Admittedly it took a bit ;-) but I finally got around to taking a closer
> look.
>
> My HTC Desire show the following languages in its Languages&Input menu:
>
> English (United Kingdom)
> English (Ireland)
> French
> Italian
> Spanish
>
> Not a lot.  However, when I call
>
> Resources.getSystem().getAssets().getLocales();
>
> on the device, I get the following list:
>
> da
> ja
> nb
> de
> th
> fi
> el
> nl
> pl
> ko
> fr
> tr
> cs
> es
> it
> pt
> ru
> sv
> en_CA
> uk_UA
> en_ZA
> en_GB
> id_ID
> en_IE
> bg_BG
> ar_EG
> en_SG
> th_TH
> fi_FI
> sl_SI
> zh_HK
> sk_SK
> zh_CN
> hi_IN
> en_IN
> vi_VN
> ro_RO
> hr_HR
> ca_ES
> sr_RS
> en_US
> es_US
> lt_LT
> pt_PT
> en_AU
> hu_HU
> lv_LV
> zh_TW
> en_NZ
> fr_CA
> nl_BE
> fr_BE
> de_DE
> sv_SE
> de_CH
> fr_CH
> it_CH
> tl_PH
> de_LI
> da_DK
> he_IL
> ar_IL
> nl_NL
> pl_PL
> nb_NO
> ja_JP
> pt_BR
> fr_FR
> el_GR
> ko_KR
> tr_TR
> es_ES
> de_AT
> it_IT
> ru_RU
> cs_CZ
> en
> ar
> hu
> iw
>
> (Interestingly enough, calling Activity.getAssets().getLocales() returns
> almost the same list, just with "hi" appended.)
>
> When I switch my app to some of the languages which are *not* offered by
> the L&I menu but *do* appear on the getLocales() list, it turns out that
> some work (like Portuguese, German, Japanese, Chinese) and some don't
> (Hindi, Arabic). "Works" mean that legible text is displayed, "doesn't
> work" means that all glyphs are replaced with rectangles in the rendered
> text.
>
> I believe the LocalePicker code you linked to doesn't run on that device
> (or additional, much stricter filtering is applied elsewhere), and I'm
> still not sure how to filter the getLocales() list to remove languages that
> the device is actually not able to display.
>
>
> On Thu, Jun 13, 2013 at 6:22 PM, Latimerius  wrote:
>
>> Thanks, that's good info.  The reason I didn't check the source in this
>> case is, first, with min sdk of 7 that's a lot of source to check ;-) , and
>> second that this whole issue is fairly peripheral to our app.
>>
>> I'm wondering if I can be reasonably sure that this code (or an
>> equivalent) runs in a majority of devices.  Off-hand, it doesn't seem to
>> explain what e.g. Optimus One shows in its L&I menu (I'll do a detailed
>> check tonight or tomorrow).
>>
>>
>> On Wed, Jun 12, 2013 at 4:39 PM, Kostya Vasilyev wrote:
>>
>>> Settings app:
>>>
>>>
>>> https://android.googlesource.com/platform/packages/apps/Settings/+/refs/heads/master/src/com/android/settings/LocalePicker.java
>>>
>>> Uses this:
>>>
>>>
>>> https://android.googlesource.com/platform/frameworks/base/+/refs/heads/master/core/java/com/android/internal/app/LocalePicker.java
>>>
>>> It's basically Resources.getSystem().**getAsset**s().getLocales() which
>>> you'd already mentioned, but the code here does some filtering, to make the
>>> list look prettier -- which explains the different results.
>>>
>>> When in doubt, use the source :)
>>>
>>> -- K
>>>
>>> On Wednesday, June 12, 2013 5:55:35 PM UTC+4, Piren wrote:

 Your reasoning is sound, but you're barking at the wrong tree... What
 shows in Language & Input can be summed up to "This is what the company
 that made the specific ROM you're using wanted the users to see when they
 use the device", which has little affect on your app. Any language that
 shows there, will mean that you can support it as well, but that list is
 very short, much shorter than the actual list of supported locales and
 fonts. That list is usually just the default provided by google plus some
 of the leading languages used in the region the device is aimed for.

 By localization i meant - Modifications to the text so that a group of
 people would be able to understand it using their native language.
 If a device was localized to support Germany, it would obviously
 support the German language and have all of its interface display in
 German. However, it does not mean it supports all the Locales available in
 Germany (which might be different due to different dialects and customs).
 Basically what you're are aiming to do is add multiple localizations to
 your app and then intersect that list with the localizations the device can
 actually display (which is defined by its available fonts).

 Basically the list of support goes like:  Font > Locale >>
 Localizations   (where the Font supports more "o

Re: [android-developers] Re: how to get a list of locales supported by device we're running on

[Latimerius]

Admittedly it took a bit ;-) but I finally got around to taking a closer
look.

My HTC Desire show the following languages in its Languages&Input menu:

English (United Kingdom)
English (Ireland)
French
Italian
Spanish

Not a lot.  However, when I call

Resources.getSystem().getAssets().getLocales();

on the device, I get the following list:

da
ja
nb
de
th
fi
el
nl
pl
ko
fr
tr
cs
es
it
pt
ru
sv
en_CA
uk_UA
en_ZA
en_GB
id_ID
en_IE
bg_BG
ar_EG
en_SG
th_TH
fi_FI
sl_SI
zh_HK
sk_SK
zh_CN
hi_IN
en_IN
vi_VN
ro_RO
hr_HR
ca_ES
sr_RS
en_US
es_US
lt_LT
pt_PT
en_AU
hu_HU
lv_LV
zh_TW
en_NZ
fr_CA
nl_BE
fr_BE
de_DE
sv_SE
de_CH
fr_CH
it_CH
tl_PH
de_LI
da_DK
he_IL
ar_IL
nl_NL
pl_PL
nb_NO
ja_JP
pt_BR
fr_FR
el_GR
ko_KR
tr_TR
es_ES
de_AT
it_IT
ru_RU
cs_CZ
en
ar
hu
iw

(Interestingly enough, calling Activity.getAssets().getLocales() returns
almost the same list, just with "hi" appended.)

When I switch my app to some of the languages which are *not* offered by
the L&I menu but *do* appear on the getLocales() list, it turns out that
some work (like Portuguese, German, Japanese, Chinese) and some don't
(Hindi, Arabic). "Works" mean that legible text is displayed, "doesn't
work" means that all glyphs are replaced with rectangles in the rendered
text.

I believe the LocalePicker code you linked to doesn't run on that device
(or additional, much stricter filtering is applied elsewhere), and I'm
still not sure how to filter the getLocales() list to remove languages that
the device is actually not able to display.


On Thu, Jun 13, 2013 at 6:22 PM, Latimerius  wrote:

> Thanks, that's good info.  The reason I didn't check the source in this
> case is, first, with min sdk of 7 that's a lot of source to check ;-) , and
> second that this whole issue is fairly peripheral to our app.
>
> I'm wondering if I can be reasonably sure that this code (or an
> equivalent) runs in a majority of devices.  Off-hand, it doesn't seem to
> explain what e.g. Optimus One shows in its L&I menu (I'll do a detailed
> check tonight or tomorrow).
>
>
> On Wed, Jun 12, 2013 at 4:39 PM, Kostya Vasilyev wrote:
>
>> Settings app:
>>
>>
>> https://android.googlesource.com/platform/packages/apps/Settings/+/refs/heads/master/src/com/android/settings/LocalePicker.java
>>
>> Uses this:
>>
>>
>> https://android.googlesource.com/platform/frameworks/base/+/refs/heads/master/core/java/com/android/internal/app/LocalePicker.java
>>
>> It's basically Resources.getSystem().**getAsset**s().getLocales() which
>> you'd already mentioned, but the code here does some filtering, to make the
>> list look prettier -- which explains the different results.
>>
>> When in doubt, use the source :)
>>
>> -- K
>>
>> On Wednesday, June 12, 2013 5:55:35 PM UTC+4, Piren wrote:
>>>
>>> Your reasoning is sound, but you're barking at the wrong tree... What
>>> shows in Language & Input can be summed up to "This is what the company
>>> that made the specific ROM you're using wanted the users to see when they
>>> use the device", which has little affect on your app. Any language that
>>> shows there, will mean that you can support it as well, but that list is
>>> very short, much shorter than the actual list of supported locales and
>>> fonts. That list is usually just the default provided by google plus some
>>> of the leading languages used in the region the device is aimed for.
>>>
>>> By localization i meant - Modifications to the text so that a group of
>>> people would be able to understand it using their native language.
>>> If a device was localized to support Germany, it would obviously support
>>> the German language and have all of its interface display in German.
>>> However, it does not mean it supports all the Locales available in Germany
>>> (which might be different due to different dialects and customs). Basically
>>> what you're are aiming to do is add multiple localizations to your app and
>>> then intersect that list with the localizations the device can actually
>>> display (which is defined by its available fonts).
>>>
>>> Basically the list of support goes like:  Font > Locale >> Localizations
>>>   (where the Font supports more "options" than Locale and Locale support
>>> much more "options" than Localizations).
>>>
>>> Regarding the limitation that RTL languages offer and limitations like
>>> that - That is up to you to verify when you create your localization...
>>> having a Locale to match that localization would just make it easier to
>>> localize, but not mandatory. e.g - If you want to display a number you can
>>> use String.format + Locale to display it according to the current locale,
>>> or go the extra mile and offer locales that aren't supported by doing the
>>> formatting yourself. which will be possible as long as the font to display
>>> it, will be available.
>>>
>>> P.S - RTL support in android sucks balls :) (at least up to JB) If
>>> you're not a native RTL speaker, don't dwell on it too much... just make
>>> sure it's readable.
>>>
>>>
>>>
>>> On Wednesda

Re: [android-developers] Re: how to get a list of locales supported by device we're running on

[Lew]

latimerius wrote:

> True, if you are able/willing to supply a text renderer with your app 
> surely there's nothing in devices that would prevent it from rendering any 
> language independent of what the platform supports.  And if I was working 
> on something that relied on text rendering as its core feature (say an 
> old-style adventure game or indeed Google Translate) it would make sense 
> for me to either write such a renderer or get a third-party one.
>

My comments were not limited to text rendering and fonts. IMEs figure in 
there as well.
 

>
> However, what I'm afraid I just implied but failed to point out is that 
> I'd like to avoid any of that.  I don't want to write or shop for a text 
> rendering module, I don't even want to bother to supply fonts with the app. 
>  I'd just like to use what the platform already has, otherwise forget it. 
>  This whole effort is only meant to support users who have their device in 
> one locale but want our app to use another one.
>

Again, we're not talking about mere text rendering.

The point is that "Languages & inputs" is not a final authority on what is 
available on the device.

For example, I have "fr_FR" on an Android phone here, showing all prompts 
in French at the system and 
app level (for apps with that locale programmed), yet the only languages 
showing in the "Langue" prompt are 
"English" and "Español".
 
So your idea won't work.

-- 
Lew

On Wed, Jun 12, 2013 at 9:36 PM, Lew >wrote:
>
>> latimerius wrote:
>>
>>> Thanks for the reply.  To explain a bit further: the reason I'm trying 
>>> to get something similar to what the user sees in "Language & input" is, I 
>>> just consider it unlikely that a device would offer a language that's it's 
>>> not capable to handle, or that it would *not* offer a language it *can* 
>>> handle. 
>>>
>>
>> What the device *offers* is a combination of what came with it from the 
>> OEM and 
>> what the user added, subject to any device-specific limitations.
>>
>> What the device *accepts* is a superset of what has already been 
>> installed.
>>
>> It is not only likely, but common that a device will have apps and device 
>> configurations 
>> supporting locales beyond what originally came with the device.
>>
>> I've got Google Translate on my phone. It supports many locales not on my 
>> L&I screen. 
>>
>> I've also loaded programs that take over the IMEs and display for 
>> whatever language 
>> and thrown the whole phone into Arabic, Chinese, Korean or whatever.
>>
>> Piren laid out a taxonomy of locale support. Basically an app will 
>> support any 
>> locale it's properly configured to support.
>>
>> -- 
>> Lew
>>
>>  -- 
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Android Developers" group.
>> To post to this group, send email to 
>> android-d...@googlegroups.com
>> To unsubscribe from this group, send email to
>> android-developers+unsubscr...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/android-developers?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Android Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to android-developers+unsubscr...@googlegroups.com .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>  
>>  
>>
>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [android-developers] Re: how to get a list of locales supported by device we're running on

[Latimerius]

True, if you are able/willing to supply a text renderer with your app
surely there's nothing in devices that would prevent it from rendering any
language independent of what the platform supports.  And if I was working
on something that relied on text rendering as its core feature (say an
old-style adventure game or indeed Google Translate) it would make sense
for me to either write such a renderer or get a third-party one.

However, what I'm afraid I just implied but failed to point out is that I'd
like to avoid any of that.  I don't want to write or shop for a text
rendering module, I don't even want to bother to supply fonts with the app.
 I'd just like to use what the platform already has, otherwise forget it.
 This whole effort is only meant to support users who have their device in
one locale but want our app to use another one.


On Wed, Jun 12, 2013 at 9:36 PM, Lew  wrote:

> latimerius wrote:
>
>> Thanks for the reply.  To explain a bit further: the reason I'm trying to
>> get something similar to what the user sees in "Language & input" is, I
>> just consider it unlikely that a device would offer a language that's it's
>> not capable to handle, or that it would *not* offer a language it *can*
>> handle.
>>
>
> What the device *offers* is a combination of what came with it from the
> OEM and
> what the user added, subject to any device-specific limitations.
>
> What the device *accepts* is a superset of what has already been installed.
>
> It is not only likely, but common that a device will have apps and device
> configurations
> supporting locales beyond what originally came with the device.
>
> I've got Google Translate on my phone. It supports many locales not on my
> L&I screen.
>
> I've also loaded programs that take over the IMEs and display for whatever
> language
> and thrown the whole phone into Arabic, Chinese, Korean or whatever.
>
> Piren laid out a taxonomy of locale support. Basically an app will support
> any
> locale it's properly configured to support.
>
> --
> Lew
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Android Developers" group.
> To post to this group, send email to android-developers@googlegroups.com
> To unsubscribe from this group, send email to
> android-developers+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/android-developers?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Android Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to android-developers+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [android-developers] Re: how to get a list of locales supported by device we're running on

[Latimerius]

Thanks, that's good info.  The reason I didn't check the source in this
case is, first, with min sdk of 7 that's a lot of source to check ;-) , and
second that this whole issue is fairly peripheral to our app.

I'm wondering if I can be reasonably sure that this code (or an equivalent)
runs in a majority of devices.  Off-hand, it doesn't seem to explain what
e.g. Optimus One shows in its L&I menu (I'll do a detailed check tonight or
tomorrow).


On Wed, Jun 12, 2013 at 4:39 PM, Kostya Vasilyev  wrote:

> Settings app:
>
>
> https://android.googlesource.com/platform/packages/apps/Settings/+/refs/heads/master/src/com/android/settings/LocalePicker.java
>
> Uses this:
>
>
> https://android.googlesource.com/platform/frameworks/base/+/refs/heads/master/core/java/com/android/internal/app/LocalePicker.java
>
> It's basically Resources.getSystem().**getAsset**s().getLocales() which
> you'd already mentioned, but the code here does some filtering, to make the
> list look prettier -- which explains the different results.
>
> When in doubt, use the source :)
>
> -- K
>
> On Wednesday, June 12, 2013 5:55:35 PM UTC+4, Piren wrote:
>>
>> Your reasoning is sound, but you're barking at the wrong tree... What
>> shows in Language & Input can be summed up to "This is what the company
>> that made the specific ROM you're using wanted the users to see when they
>> use the device", which has little affect on your app. Any language that
>> shows there, will mean that you can support it as well, but that list is
>> very short, much shorter than the actual list of supported locales and
>> fonts. That list is usually just the default provided by google plus some
>> of the leading languages used in the region the device is aimed for.
>>
>> By localization i meant - Modifications to the text so that a group of
>> people would be able to understand it using their native language.
>> If a device was localized to support Germany, it would obviously support
>> the German language and have all of its interface display in German.
>> However, it does not mean it supports all the Locales available in Germany
>> (which might be different due to different dialects and customs). Basically
>> what you're are aiming to do is add multiple localizations to your app and
>> then intersect that list with the localizations the device can actually
>> display (which is defined by its available fonts).
>>
>> Basically the list of support goes like:  Font > Locale >> Localizations
>>   (where the Font supports more "options" than Locale and Locale support
>> much more "options" than Localizations).
>>
>> Regarding the limitation that RTL languages offer and limitations like
>> that - That is up to you to verify when you create your localization...
>> having a Locale to match that localization would just make it easier to
>> localize, but not mandatory. e.g - If you want to display a number you can
>> use String.format + Locale to display it according to the current locale,
>> or go the extra mile and offer locales that aren't supported by doing the
>> formatting yourself. which will be possible as long as the font to display
>> it, will be available.
>>
>> P.S - RTL support in android sucks balls :) (at least up to JB) If you're
>> not a native RTL speaker, don't dwell on it too much... just make sure it's
>> readable.
>>
>>
>>
>> On Wednesday, June 12, 2013 3:56:39 PM UTC+3, latimerius wrote:
>>>
>>> Thanks for the reply.  To explain a bit further: the reason I'm trying
>>> to get something similar to what the user sees in "Language & input" is, I
>>> just consider it unlikely that a device would offer a language that's it's
>>> not capable to handle, or that it would *not* offer a language it *can*
>>> handle.
>>>
>>> It's just a heuristic to decide whether what I'm getting looks
>>> plausible.  If, for instance, a devices offers two variants of English,
>>> French, Italian and Spanish (a single variant each) in its settings but
>>> getAvailableLocales() returns just a heap of English variants (like 15 or
>>> 20) and two Spanish variants, it doesn't match what I see in settings and
>>> thus looks suspicious.  That's it - I don't mean to insist that an API must
>>> get me a list identical to "Language & input".
>>>
>>> I'm not sure what the difference between "locale" and "localization" is
>>> - I believe I'm using the word "locale" in the sense explained for instance
>>> here: 
>>> http://en.wikipedia.org/**wiki/Locale. 
>>>  However, you're right in that I don't actually need full support for a
>>> specific locale - being able to render text is good enough (I mean I don't
>>> care about currency formatting, collating etc.).  On the other hand, I'm
>>> not sure if just checking fonts is enough to ensure that.  Consider for
>>> instance right-to-left languages - fonts might well be available but
>>> without specific support in the font/text renderer the result won't be good.
>>>
>>> Come to think of it, I'm probably lo

Re: [android-developers] Re: how to get a list of locales supported by device we're running on

[Latimerius]

Thanks Piren.  Alright, it's true that "Languages & input" might not show
everything the device is capable of.  I'm fine with that though.  My
highest priority concern is to avoid that a user sets the language to
something that the device can *not* handle.  To ensure that, I'll gladly
skip exposing a  language option to the user if the system does not expose
it either.

I'm still a bit doubtful though whether having an appropriate font is
enough to decide the device can handle a particular language...


On Wed, Jun 12, 2013 at 3:55 PM, Piren  wrote:

> Your reasoning is sound, but you're barking at the wrong tree... What
> shows in Language & Input can be summed up to "This is what the company
> that made the specific ROM you're using wanted the users to see when they
> use the device", which has little affect on your app. Any language that
> shows there, will mean that you can support it as well, but that list is
> very short, much shorter than the actual list of supported locales and
> fonts. That list is usually just the default provided by google plus some
> of the leading languages used in the region the device is aimed for.
>
> By localization i meant - Modifications to the text so that a group of
> people would be able to understand it using their native language.
> If a device was localized to support Germany, it would obviously support
> the German language and have all of its interface display in German.
> However, it does not mean it supports all the Locales available in Germany
> (which might be different due to different dialects and customs). Basically
> what you're are aiming to do is add multiple localizations to your app and
> then intersect that list with the localizations the device can actually
> display (which is defined by its available fonts).
>
> Basically the list of support goes like:  Font > Locale >> Localizations
> (where the Font supports more "options" than Locale and Locale support much
> more "options" than Localizations).
>
> Regarding the limitation that RTL languages offer and limitations like
> that - That is up to you to verify when you create your localization...
> having a Locale to match that localization would just make it easier to
> localize, but not mandatory. e.g - If you want to display a number you can
> use String.format + Locale to display it according to the current locale,
> or go the extra mile and offer locales that aren't supported by doing the
> formatting yourself. which will be possible as long as the font to display
> it, will be available.
>
> P.S - RTL support in android sucks balls :) (at least up to JB) If you're
> not a native RTL speaker, don't dwell on it too much... just make sure it's
> readable.
>
>
>
> On Wednesday, June 12, 2013 3:56:39 PM UTC+3, latimerius wrote:
>
>> Thanks for the reply.  To explain a bit further: the reason I'm trying to
>> get something similar to what the user sees in "Language & input" is, I
>> just consider it unlikely that a device would offer a language that's it's
>> not capable to handle, or that it would *not* offer a language it *can*
>> handle.
>>
>> It's just a heuristic to decide whether what I'm getting looks plausible.
>>  If, for instance, a devices offers two variants of English, French,
>> Italian and Spanish (a single variant each) in its settings but
>> getAvailableLocales() returns just a heap of English variants (like 15 or
>> 20) and two Spanish variants, it doesn't match what I see in settings and
>> thus looks suspicious.  That's it - I don't mean to insist that an API must
>> get me a list identical to "Language & input".
>>
>> I'm not sure what the difference between "locale" and "localization" is -
>> I believe I'm using the word "locale" in the sense explained for instance
>> here: 
>> http://en.wikipedia.org/**wiki/Locale.  
>> However, you're right in that I don't actually need full support for a
>> specific locale - being able to render text is good enough (I mean I don't
>> care about currency formatting, collating etc.).  On the other hand, I'm
>> not sure if just checking fonts is enough to ensure that.  Consider for
>> instance right-to-left languages - fonts might well be available but
>> without specific support in the font/text renderer the result won't be good.
>>
>> Come to think of it, I'm probably looking for a
>> TextView.getAvailableLocales()**...
>>
>>
>> On Wed, Jun 12, 2013 at 10:20 AM, Piren  wrote:
>>
>>> I think you're confusing several different things the "Language and
>>> Input" list that you're trying to fit isn't the same as the supported
>>> locales ... This is just a list of languages the specific OS interface has
>>> special versions for (i.e, the entire device UI will change). This is
>>> localization, not locale support.
>>>
>>> The list of available locales will be more accurate to what you're
>>> trying to achieve, but it is still not there - some devices can render
>>> fonts that are outside of those available lo

Re: [android-developers] Re: how to get a list of locales supported by device we're running on

[Lew]

latimerius wrote:

> Thanks for the reply.  To explain a bit further: the reason I'm trying to 
> get something similar to what the user sees in "Language & input" is, I 
> just consider it unlikely that a device would offer a language that's it's 
> not capable to handle, or that it would *not* offer a language it *can* 
> handle. 
>

What the device *offers* is a combination of what came with it from the OEM 
and 
what the user added, subject to any device-specific limitations.

What the device *accepts* is a superset of what has already been installed.

It is not only likely, but common that a device will have apps and device 
configurations 
supporting locales beyond what originally came with the device.

I've got Google Translate on my phone. It supports many locales not on my 
L&I screen. 

I've also loaded programs that take over the IMEs and display for whatever 
language 
and thrown the whole phone into Arabic, Chinese, Korean or whatever.

Piren laid out a taxonomy of locale support. Basically an app will support 
any 
locale it's properly configured to support.

-- 
Lew

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [android-developers] Re: how to get a list of locales supported by device we're running on

[Kostya Vasilyev]

Settings app:

https://android.googlesource.com/platform/packages/apps/Settings/+/refs/heads/master/src/com/android/settings/LocalePicker.java

Uses this:

https://android.googlesource.com/platform/frameworks/base/+/refs/heads/master/core/java/com/android/internal/app/LocalePicker.java

It's basically Resources.getSystem().**getAssets().getLocales() which you'd 
already mentioned, but the code here does some filtering, to make the list 
look prettier -- which explains the different results.

When in doubt, use the source :)

-- K

On Wednesday, June 12, 2013 5:55:35 PM UTC+4, Piren wrote:
>
> Your reasoning is sound, but you're barking at the wrong tree... What 
> shows in Language & Input can be summed up to "This is what the company 
> that made the specific ROM you're using wanted the users to see when they 
> use the device", which has little affect on your app. Any language that 
> shows there, will mean that you can support it as well, but that list is 
> very short, much shorter than the actual list of supported locales and 
> fonts. That list is usually just the default provided by google plus some 
> of the leading languages used in the region the device is aimed for.
>
> By localization i meant - Modifications to the text so that a group of 
> people would be able to understand it using their native language. 
> If a device was localized to support Germany, it would obviously support 
> the German language and have all of its interface display in German. 
> However, it does not mean it supports all the Locales available in Germany 
> (which might be different due to different dialects and customs). Basically 
> what you're are aiming to do is add multiple localizations to your app and 
> then intersect that list with the localizations the device can actually 
> display (which is defined by its available fonts).
>
> Basically the list of support goes like:  Font > Locale >> Localizations   
> (where the Font supports more "options" than Locale and Locale support much 
> more "options" than Localizations).
>
> Regarding the limitation that RTL languages offer and limitations like 
> that - That is up to you to verify when you create your localization... 
> having a Locale to match that localization would just make it easier to 
> localize, but not mandatory. e.g - If you want to display a number you can 
> use String.format + Locale to display it according to the current locale, 
> or go the extra mile and offer locales that aren't supported by doing the 
> formatting yourself. which will be possible as long as the font to display 
> it, will be available.
>
> P.S - RTL support in android sucks balls :) (at least up to JB) If you're 
> not a native RTL speaker, don't dwell on it too much... just make sure it's 
> readable. 
>
>
>
> On Wednesday, June 12, 2013 3:56:39 PM UTC+3, latimerius wrote:
>>
>> Thanks for the reply.  To explain a bit further: the reason I'm trying to 
>> get something similar to what the user sees in "Language & input" is, I 
>> just consider it unlikely that a device would offer a language that's it's 
>> not capable to handle, or that it would *not* offer a language it *can* 
>> handle. 
>>
>> It's just a heuristic to decide whether what I'm getting looks plausible. 
>>  If, for instance, a devices offers two variants of English, French, 
>> Italian and Spanish (a single variant each) in its settings but 
>> getAvailableLocales() returns just a heap of English variants (like 15 or 
>> 20) and two Spanish variants, it doesn't match what I see in settings and 
>> thus looks suspicious.  That's it - I don't mean to insist that an API must 
>> get me a list identical to "Language & input".
>>
>> I'm not sure what the difference between "locale" and "localization" is - 
>> I believe I'm using the word "locale" in the sense explained for instance 
>> here: http://en.wikipedia.org/wiki/Locale .  However, you're right in 
>> that I don't actually need full support for a specific locale - being able 
>> to render text is good enough (I mean I don't care about currency 
>> formatting, collating etc.).  On the other hand, I'm not sure if just 
>> checking fonts is enough to ensure that.  Consider for instance 
>> right-to-left languages - fonts might well be available but without 
>> specific support in the font/text renderer the result won't be good.
>>
>> Come to think of it, I'm probably looking for a 
>> TextView.getAvailableLocales()...
>>
>>
>> On Wed, Jun 12, 2013 at 10:20 AM, Piren  wrote:
>>
>>> I think you're confusing several different things the "Language and 
>>> Input" list that you're trying to fit isn't the same as the supported 
>>> locales ... This is just a list of languages the specific OS interface has 
>>> special versions for (i.e, the entire device UI will change). This is 
>>> localization, not locale support. 
>>>
>>> The list of available locales will be more accurate to what you're 
>>> trying to achieve, but it is still not there - some devices can ren

Re: [android-developers] Re: how to get a list of locales supported by device we're running on

[Piren]

Your reasoning is sound, but you're barking at the wrong tree... What shows 
in Language & Input can be summed up to "This is what the company that made 
the specific ROM you're using wanted the users to see when they use the 
device", which has little affect on your app. Any language that shows 
there, will mean that you can support it as well, but that list is very 
short, much shorter than the actual list of supported locales and fonts. 
That list is usually just the default provided by google plus some of the 
leading languages used in the region the device is aimed for.

By localization i meant - Modifications to the text so that a group of 
people would be able to understand it using their native language. 
If a device was localized to support Germany, it would obviously support 
the German language and have all of its interface display in German. 
However, it does not mean it supports all the Locales available in Germany 
(which might be different due to different dialects and customs). Basically 
what you're are aiming to do is add multiple localizations to your app and 
then intersect that list with the localizations the device can actually 
display (which is defined by its available fonts).

Basically the list of support goes like:  Font > Locale >> Localizations   
(where the Font supports more "options" than Locale and Locale support much 
more "options" than Localizations).

Regarding the limitation that RTL languages offer and limitations like that 
- That is up to you to verify when you create your localization... having a 
Locale to match that localization would just make it easier to localize, 
but not mandatory. e.g - If you want to display a number you can use 
String.format + Locale to display it according to the current locale, or go 
the extra mile and offer locales that aren't supported by doing the 
formatting yourself. which will be possible as long as the font to display 
it, will be available.

P.S - RTL support in android sucks balls :) (at least up to JB) If you're 
not a native RTL speaker, don't dwell on it too much... just make sure it's 
readable. 



On Wednesday, June 12, 2013 3:56:39 PM UTC+3, latimerius wrote:
>
> Thanks for the reply.  To explain a bit further: the reason I'm trying to 
> get something similar to what the user sees in "Language & input" is, I 
> just consider it unlikely that a device would offer a language that's it's 
> not capable to handle, or that it would *not* offer a language it *can* 
> handle. 
>
> It's just a heuristic to decide whether what I'm getting looks plausible. 
>  If, for instance, a devices offers two variants of English, French, 
> Italian and Spanish (a single variant each) in its settings but 
> getAvailableLocales() returns just a heap of English variants (like 15 or 
> 20) and two Spanish variants, it doesn't match what I see in settings and 
> thus looks suspicious.  That's it - I don't mean to insist that an API must 
> get me a list identical to "Language & input".
>
> I'm not sure what the difference between "locale" and "localization" is - 
> I believe I'm using the word "locale" in the sense explained for instance 
> here: http://en.wikipedia.org/wiki/Locale .  However, you're right in 
> that I don't actually need full support for a specific locale - being able 
> to render text is good enough (I mean I don't care about currency 
> formatting, collating etc.).  On the other hand, I'm not sure if just 
> checking fonts is enough to ensure that.  Consider for instance 
> right-to-left languages - fonts might well be available but without 
> specific support in the font/text renderer the result won't be good.
>
> Come to think of it, I'm probably looking for a 
> TextView.getAvailableLocales()...
>
>
> On Wed, Jun 12, 2013 at 10:20 AM, Piren >wrote:
>
>> I think you're confusing several different things the "Language and 
>> Input" list that you're trying to fit isn't the same as the supported 
>> locales ... This is just a list of languages the specific OS interface has 
>> special versions for (i.e, the entire device UI will change). This is 
>> localization, not locale support. 
>>
>> The list of available locales will be more accurate to what you're trying 
>> to achieve, but it is still not there - some devices can render fonts that 
>> are outside of those available locales.
>> this is because what really matters in the end is if you have the proper 
>> fonts to render that text.
>>
>> I actually dealt with something regarding that a few days ago and i'm 
>> even more confused... the source code for TextView/Paint don't actually 
>> tell us any information on how android gets the available fonts or how it 
>> decides which one to use (it's all in native code apparently) 
>>
>> But i did find this:
>>
>> http://www.ulduzsoft.com/2012/01/enumerating-the-fonts-on-android-platform/
>>
>> It might give you what you're looking for if you combine the available 
>> font list with the available locales. 
>>
>>
>> On Tues

Re: [android-developers] Re: how to get a list of locales supported by device we're running on

[Latimerius]

Thanks for the reply.  To explain a bit further: the reason I'm trying to
get something similar to what the user sees in "Language & input" is, I
just consider it unlikely that a device would offer a language that's it's
not capable to handle, or that it would *not* offer a language it *can*
handle.

It's just a heuristic to decide whether what I'm getting looks plausible.
 If, for instance, a devices offers two variants of English, French,
Italian and Spanish (a single variant each) in its settings but
getAvailableLocales() returns just a heap of English variants (like 15 or
20) and two Spanish variants, it doesn't match what I see in settings and
thus looks suspicious.  That's it - I don't mean to insist that an API must
get me a list identical to "Language & input".

I'm not sure what the difference between "locale" and "localization" is - I
believe I'm using the word "locale" in the sense explained for instance
here: http://en.wikipedia.org/wiki/Locale .  However, you're right in that
I don't actually need full support for a specific locale - being able to
render text is good enough (I mean I don't care about currency formatting,
collating etc.).  On the other hand, I'm not sure if just checking fonts is
enough to ensure that.  Consider for instance right-to-left languages -
fonts might well be available but without specific support in the font/text
renderer the result won't be good.

Come to think of it, I'm probably looking for a
TextView.getAvailableLocales()...


On Wed, Jun 12, 2013 at 10:20 AM, Piren  wrote:

> I think you're confusing several different things the "Language and
> Input" list that you're trying to fit isn't the same as the supported
> locales ... This is just a list of languages the specific OS interface has
> special versions for (i.e, the entire device UI will change). This is
> localization, not locale support.
>
> The list of available locales will be more accurate to what you're trying
> to achieve, but it is still not there - some devices can render fonts that
> are outside of those available locales.
> this is because what really matters in the end is if you have the proper
> fonts to render that text.
>
> I actually dealt with something regarding that a few days ago and i'm even
> more confused... the source code for TextView/Paint don't actually tell us
> any information on how android gets the available fonts or how it decides
> which one to use (it's all in native code apparently)
>
> But i did find this:
> http://www.ulduzsoft.com/2012/01/enumerating-the-fonts-on-android-platform/
>
> It might give you what you're looking for if you combine the available
> font list with the available locales.
>
>
> On Tuesday, June 11, 2013 7:31:53 PM UTC+3, latimerius wrote:
>>
>> I understand this is a FAQ but after googling for hours and finding
>> nothing but forum questions with no answers and a heap of bad
>> (non-functional) advice, I figured I'd ask.
>>
>> I'd like to allow our users to set a locale independent of the
>> system-wide one.  To construct the menu of available languages, I figured
>> I'd take a list of languages supported by the app and remove the ones not
>> supported by the particular device.  I wouldn't want to offer a language to
>> the user if the device cannot render texts in that language (say due to a
>> missing font or code support).
>>
>> Getting a list of languages device can render turned out surprisingly
>> hard though.  Following hints from docs and advice from the net, I tried
>>
>> Locale.getAvailableLocales()
>> Resources.getSystem().**getAssets().getLocales() (or
>> just getAssets().getLocales() with same result)
>>
>> none of which gets the expected result (which is something resembling the
>> language list in system "Language & Input" settings).  Also, there is a
>> mention in the docs that subsystems affected by locale settings usually
>> offer their own means of getting a list of supported locales which we
>> should use in preference to Locale.getAvailableLocales(**).  Fair enough
>> but I can see no such functions in TextView or Paint which are the
>> subsystems I use to draw text.
>>
>> We can do without app-specific locale settings although they'd be nice to
>> have.  However, if just out of curiosity, I'm still wondering if it's
>> really not possible on Android to get this seemingly fundamental piece of
>> information?
>>
>>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Android Developers" group.
> To post to this group, send email to android-developers@googlegroups.com
> To unsubscribe from this group, send email to
> android-developers+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/android-developers?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Android Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to android-developers+unsubscr...@goog

[android-developers] Re: how to get a list of locales supported by device we're running on

[Piren]

I think you're confusing several different things the "Language and 
Input" list that you're trying to fit isn't the same as the supported 
locales ... This is just a list of languages the specific OS interface has 
special versions for (i.e, the entire device UI will change). This is 
localization, not locale support. 

The list of available locales will be more accurate to what you're trying 
to achieve, but it is still not there - some devices can render fonts that 
are outside of those available locales.
this is because what really matters in the end is if you have the proper 
fonts to render that text.

I actually dealt with something regarding that a few days ago and i'm even 
more confused... the source code for TextView/Paint don't actually tell us 
any information on how android gets the available fonts or how it decides 
which one to use (it's all in native code apparently) 

But i did find this:
http://www.ulduzsoft.com/2012/01/enumerating-the-fonts-on-android-platform/

It might give you what you're looking for if you combine the available font 
list with the available locales. 

On Tuesday, June 11, 2013 7:31:53 PM UTC+3, latimerius wrote:
>
> I understand this is a FAQ but after googling for hours and finding 
> nothing but forum questions with no answers and a heap of bad 
> (non-functional) advice, I figured I'd ask.
>
> I'd like to allow our users to set a locale independent of the system-wide 
> one.  To construct the menu of available languages, I figured I'd take a 
> list of languages supported by the app and remove the ones not supported by 
> the particular device.  I wouldn't want to offer a language to the user if 
> the device cannot render texts in that language (say due to a missing font 
> or code support).
>
> Getting a list of languages device can render turned out surprisingly hard 
> though.  Following hints from docs and advice from the net, I tried
>
> Locale.getAvailableLocales()
> Resources.getSystem().getAssets().getLocales() (or 
> just getAssets().getLocales() with same result)
>
> none of which gets the expected result (which is something resembling the 
> language list in system "Language & Input" settings).  Also, there is a 
> mention in the docs that subsystems affected by locale settings usually 
> offer their own means of getting a list of supported locales which we 
> should use in preference to Locale.getAvailableLocales().  Fair enough but 
> I can see no such functions in TextView or Paint which are the subsystems I 
> use to draw text.
>
> We can do without app-specific locale settings although they'd be nice to 
> have.  However, if just out of curiosity, I'm still wondering if it's 
> really not possible on Android to get this seemingly fundamental piece of 
> information?
>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.