Re: [android-developers] Re: how to get a list of locales supported by device we're running on
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 <l4t1m3r1us@gmail.com> 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 <kmansoft@gmail.com> wrote:
Settings app:Uses this: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 <gpi...@gmail.com> 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: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 triedLocale.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-d...@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscribe@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+unsubscribe@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+unsubscribe@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+unsubscribe@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+unsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
posted by twitter @ 1:50 PM
0 Comments
0 Comments:
Post a Comment
Subscribe to Post Comments [Atom]
<< Home