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 <[email protected]> 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 <[email protected]>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<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 <[email protected]> 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/<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().**getAsset**s().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 [email protected] >>>>> To unsubscribe from this group, send email to >>>>> android-developers+**[email protected] >>>>> For more options, visit this group at >>>>> http://groups.google.com/**group/android-developers?hl=en<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+**[email protected]. >>>>> For more options, visit >>>>> https://groups.google.com/**groups/opt_out<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 [email protected] >> To unsubscribe from this group, send email to >> [email protected] >> 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 [email protected]. >> 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 [email protected] To unsubscribe from this group, send email to [email protected] 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
