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 <[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/ >>> >>> 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 [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.
