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 <[email protected]> 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 android-d...@**googlegroups.com >>> >>> 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.
