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 <[email protected]> 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 <[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.
