android-developers
[Arriba] [Todas las Listas]

Re: [android-developers] Re: Cómo para conseguir una lista de locales a

To: android-developers@xxxxxxxxxxxxxxxx
Subject: Re: [android-developers] Re: Cómo para conseguir una lista de locales apoyado por dispositivo estamos corriendo encima
From: Latimerius <l4t1m3r1us@xxxxxxxxx>
Date: Tue, 13 Aug 2013 23:49:21 +0200
Delivery-date: Tue, 13 Aug 2013 17:50:26 -0400
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20120806; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :sender:list-subscribe:list-unsubscribe:content-type; bh=7vd9TwM2vedpwFftiYzl0hBlvXrKXjy4m6bsSilV8ME=; b=YEQChErpqmKLFfTPvWADxrg+AC1eDuy/Hy/0piqcqxL2qxXBlD+t/fJwdJ1TboDoMc zgt7qX1IbFYVQNw0AigqGAJaPDCQZZoOTs1R1yRFew/TTedESFn2Dyaci1f/BjsZZi9Z T7lPBNxjrmKYo0ZwqwiMRgpBW4ytCKjwguCU0KjicVr08imOb4V9z2QPtnuguYBD65gT zDp+FaR35/sa9BEPIU9apbP6fyUUuVcfDJS7eV6eA0tIFrpzCif29dXw6T0lP6DVBDhF YdsDWbFqM2/mva8mwzfmaeSZNRpwizLUiliiEDLo7EMCSDreT8rR53sKVbUztnHPw0Bj Tykg==
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :sender:list-subscribe:list-unsubscribe:content-type; bh=7vd9TwM2vedpwFftiYzl0hBlvXrKXjy4m6bsSilV8ME=; b=0IQ/YDMqzM2qqaQP/4gHYY1DJwU1sd3oPm8WvX40ThSfLDyapqrwZ+vUt+uDoIRYRM K1+J0rfTBUuv1sWWV9Fi34uQFmLOClvt2MADH5W2oKuJ9ybVhe52G1XHTnEZJz2OXufG 6A9T1znmgJHGmi1Dx5KjcK+k25N36P1JvS6g5yqTQbaVcDEcluCjCgcT38CKyeUGGUKp cyZQwM/GeO6XPrtz0R/C6OZw/gOI/1d078h98na3jmR7nIwVjFYCDAP6nrC24BC0Q+RG b/DquMY/6EnFCPS3Wzu65fBuJPv+UlYittThNFATyTmY7yfE6JJyBJZanwmTvCu4jX/H y3tQ==
Envelope-to: traductor@xxxxxxxxxxx
In-reply-to: <CAEzrvz4F7=oC1T4fW=48sA_=pXb0oKf17odGeXPKVPZYH-MCKw@mail.gmail.com>
List-archive: <http://groups.google.com/group/android-developers>
List-help: <http://groups.google.com/support/>, <mailto:android-developers+help@googlegroups.com>
List-id: <android-developers.googlegroups.com>
List-post: <http://groups.google.com/group/android-developers/post>, <mailto:android-developers@googlegroups.com>
List-subscribe: <http://groups.google.com/group/android-developers/subscribe>, <mailto:android-developers+subscribe@googlegroups.com>
List-unsubscribe: <http://groups.google.com/group/android-developers/subscribe>, <mailto:googlegroups-manage+364598216046+unsubscribe@googlegroups.com>
Mailing-list: list android-developers@xxxxxxxxxxxxxxxx; contact android-developers+owners@xxxxxxxxxxxxxxxx
References: <CAEzrvz667FcSaD03_6JZG084t95y=zRudEtxovGdzp0ojp5Hjw@mail.gmail.com> <6571dbb4-94ae-48c7-aa47-da614346a74b@googlegroups.com> <CAEzrvz7p70ORO=WiG1ihh8fHk_zs1E8cijXfSNGXNg3htme5WA@mail.gmail.com> <8c0f479b-c29f-4515-acdc-36c9ef3a2ae3@googlegroups.com> <97f7f2e5-a5f2-49a9-bd1e-33fdf97956dc@googlegroups.com> <CAEzrvz63DxVTHZ1-_xd0uUJwYJSC2P66RDz54URbsOVuJjSeCA@mail.gmail.com> <CAEzrvz4F7=oC1T4fW=48sA_=pXb0oKf17odGeXPKVPZYH-MCKw@mail.gmail.com>
Reply-to: android-developers@xxxxxxxxxxxxxxxx
Sender: android-developers@xxxxxxxxxxxxxxxx
*Apologies Para responder a yo, justo querido añadir a mi mensaje anterior
que comprobé con mi *Optimus Un.  En aquel dispositivo, el *L&yo la carta parece para
emparejar *getLocales() producción (algunos filtrando similar a qué *LocalePicker 
*notwithstanding), aun así cuando resulta, cuándo cambié nuestro *app a *zh ""
cuál no *es* en la lista, trabajó en todo caso!


En *Tue, *Aug 13, 2013 en 10:50 PM, *Latimerius <*l4*t1*m3*r1us@xxxxxxxxx> escribió:

> *Admittedly tomó un poco ;-) pero yo finalmente conseguido alrededor a tomar una mirada
> más cercana.
>
> Mi Deseo de HTC muestra el siguiendo lenguas en su carta&de Entrada de las Lenguas:
>
> inglés (Reino Unido)
> inglés (Irlanda)
> francés
> italiano
> español
>
> No mucho.  Aun así, cuándo llamo
>
> Recursos.*getSystem().*getAssets().*getLocales();
>
> En el dispositivo, consigo el siguiendo lista:
>
> *da
> *ja
> *nb
> *de
> 
> *th *fi
> *el
> *nl
> *pl
> *ko
> *fr
> *tr
> *cs
> *es
> él
> *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_EN
> *en_EN
> *vi_*VN
> *ro_RO
> *hr_HR
> *ca_ES
> *sr_RS
> *en_EE.UU.
> *es_EE.UU.
> *lt_LT
> *pt_PT
> *en_AU
> *hu_HU
> *lv_LV
> *zh_TW
> *en_*NZ
> *fr_CA
> *nl_SER
> *fr_SER
> *de_DE
> *sv_SE
> *de_CH
> *fr_CH
> lo_CH
> *tl_PH
> *de_LI
> *da_*DK
> él_IL
> *ar_IL
> *nl_NL
> *pl_PL
> *nb_NINGÚN
> *ja_JP
> *pt_BR
> *fr_FR
> *el_GR
> *ko_*KR
> *tr_TR
> *es_ES
> *de_EN
> él_LO
> *ru_RU
> *cs_*CZ
> *en
> *ar
> *hu
> *iw
>
> (Curiosamente, llamando Actividad.*getAssets().*getLocales() Regresa
> casi la misma lista, justo con *hi "" *appended.)
>
> Cuándo cambio mi *app a algunos de las lenguas que no *son* ofrecido por
> el *L&yo carta pero *aparece en el *getLocales() lista, resulta que
> algún trabajo (como portugués, alemán, japonés, chino) y algunos  no
> (*Hindi, *Arabic). "Los Trabajos" significan que *legible el texto es mostrado, "no trabaja" significa que todo *glyphs es reemplazado con *rectangles en el *rendered
> texto.
>
> Creo el *LocalePicker código enlazaste a  no corrido en aquel dispositivo
> (o adicional, mucho más estricto filtrando es aplicado en otro lugar), y soy
> todavía no seguro cómo para filtrar el *getLocales() lista para sacar lenguas que
> el dispositivo es de hecho no capaz de mostrar.
>
>
> En *Thu, *Jun 13, 2013 en 6:22 PM, *Latimerius <*l4*t1*m3*r1us@xxxxxxxxx> escribió:
>
>> *Thanks, aquello es bueno *info.  La razón no comprobé la fuente en
>> este caso es, primero, con *min *sdk de 7 aquello es mucha fuente para comprobar ;-) , y segundo
>> que este asunto entero es *fairly periférico a nuestro *app.
>>
>> Estoy preguntándome si puedo ser razonablemente seguro que este código (o un
>> equivalente) carreras en una mayoría de dispositivos.  Fuera-mano, no parece para
>> explicar lo que *e.*g. *Optimus #Un espectáculos en su *L&yo carta (haré un control
>> detallado esta noche o mañana).
>>
>>
>> En *Wed, *Jun 12, 2013 en 4:39 PM, *Kostya *Vasilyev <kmansoft@xxxxxxxxx>escribió:
>>
>>> *Settings *app:
>>>
>>>
>>> *https://*android.*googlesource.*com/Paquetes/de plataforma/*apps/*Settings/+/*refs/maestro/de cabezas/*src/*com/*android/*settings/*LocalePicker.*java
>>>
>>> Utiliza esto:
>>>
>>>
>>> *https://*android.*googlesource.*com/Base/de marcos/de la plataforma/+/*refs/encabeza/núcleo/maestro/*java/*com/*android/interno/*app/*LocalePicker.*java
>>>
>>> Es básicamente Recursos.*getSystem().***getAsset***s().*getLocales() Cuál
>>> tú  ya mencionado, pero el código aquí hace algunos filtrando, para hacer la lista
>>> mira más bonita -- cuál explica los resultados diferentes.
>>>
>>> Cuando en duda, utiliza la fuente :)
>>>
>>> -- *K
>>>
>>> En miércoles, junio 12, 2013 5:55:35 PM *UTC+4, *Piren escribió:
>>>>
>>>> Vuestro razonamiento es sonido, pero estás ladrando en el árbol incorrecto... Qué
>>>> espectáculos en Entrada & de Lengua pueden ser *summed hasta "Esto es lo que la empresa
>>>> que hizo el ROM específico estás utilizando querido los usuarios para ver cuándo utilizan el dispositivo", el cual ha poco afectar en vuestro *app. Cualquier lengua que
>>>> muestra allí, significará que lo puedes apoyar también, pero que la lista es
>>>> muy corta, mucho más corto que la lista real de apoyado *locales y *fonts.
>>>> Aquella lista es normalmente justo el *default proporcionado por *google *plus algunos
>>>> de las lenguas principales utilizadas en la región el dispositivo es apuntado puesto que.
>>>>
>>>> Por *localization *i significado - Modificaciones al texto de modo que un grupo de personas
>>>> sería capaz de entenderlo utilizando su lengua nativa.
>>>> Si un dispositivo era *localized para apoyar Alemania, evidentemente apoyaría la lengua alemana y tener todo de su exhibición de interfaz en
>>>> alemán. Aun así, no lo significa apoya todo el *Locales disponible en
>>>> Alemania (cuál podría ser diferente debido a aduana y dialectos diferentes).
>>>> Básicamente lo que eres está apuntando para hacer es añade múltiple *localizations a vuestro
>>>> *app y entonces *intersect que lista con el *localizations el dispositivo puede
>>>> de hecho exhibición (cuál es definido por su disponible *fonts).
>>>>
>>>> Básicamente la lista de apoyo va gusta:  *Font > *Locale >>
>>>> *Localizations   (dónde el *Font apoyos más "opciones" que *Locale y *Locale
>>>> apoyo mucho más "opciones" que *Localizations).
>>>>
>>>> Con respecto a la limitación que oferta de lenguas del RTL y limitaciones como
>>>> aquello - Aquello es hasta ti a *verify cuándo creas vuestro *localization...
>>>> Teniendo un *Locale para emparejar que *localization justo lo haría más fácil a *localize,
>>>> pero no *mandatory. *e.*g - Si quieres mostrar un número puedes utilizar Cadena.Formato + *Locale para mostrarlo según el actual *locale,
>>>> o ir la milla extra y oferta *locales que no es apoyado por hacer el
>>>> *formatting tú. Cuál será posible cuando mucho tiempo cuando el *font para mostrarlo, será disponible.
>>>>
>>>> *P.*S - apoyo de RTL en *android chupa pelotas :) (al menos hasta JB) Si
>>>> no eres un hablante de RTL nativo,  no *dwell en él demasiado... Justo hace
>>>> seguro es *readable.
>>>>
>>>>
>>>>
>>>> En miércoles, junio 12, 2013 3:56:39 PM *UTC+3, *latimerius escribió:
>>>>>
>>>>> *Thanks para la respuesta.  Para explicar un poco más allá: la razón estoy intentando
>>>>> conseguir algo similar a lo que el usuario ve en "entrada & de Lengua" es, justo #considerar improbable que un dispositivo ofrecería una lengua aquello es no
>>>>> es capaz de manejar, o que no *ofrecería una lengua puede
>>>>> manejar.
>>>>>
>>>>> Es justo un *heuristic para decidir si lo que estoy consiguiendo miradas
>>>>> *plausible.  Si, para caso, unos dispositivos ofrece dos *variants de inglés,
>>>>> francés, italiano y español (un solo *variant cada) en su *settings pero
>>>>> *getAvailableLocales() regresa justo un *heap de inglés *variants (como 15 o 20)
>>>>> y dos español *variants, no empareja lo que veo en *settings y así
>>>>> mira sospechoso.  Aquello es él - no significo para insistir que un API me
>>>>> tiene que conseguir una lista idéntica a entrada " & de Lengua".
>>>>>
>>>>> No soy seguro lo que la diferencia entre "*locale" y *localization ""
>>>>> es - creo que estoy utilizando la palabra "*locale" en el sentido explicó para
>>>>> caso aquí: *http://*en.*wikipedia.*org/***wiki/*Locale<*http://*en.*wikipedia.*org/*wiki/*Locale>.  Aun así, eres bien en que no de hecho necesito apoyo lleno para un
>>>>> específico *locale - siendo capaz a *render el texto es bien bastante (significo no me preocupo sobre moneda *formatting, cotejando *etc.).  Por otro lado, no
>>>>> soy seguro si justo comprobando *fonts es bastante para asegurar aquello.  Considera para
>>>>> caso bien-a-lenguas dejadas - *fonts bien podría ser disponible pero
>>>>> sin apoyo específico en el *font/texto *renderer el resultado no será bueno.
>>>>>
>>>>> Venido para pensar de él, probablemente estoy buscando un
>>>>> *TextView.*getAvailableLocales()**...
>>>>>
>>>>>
>>>>> En *Wed, *Jun 12, 2013 en 10:20 AM, *Piren <gpi...@xxxxxxxxx> escribió:
>>>>>
>>>>>> pienso que estás confundiendo varias cosas diferentes.... La Lengua "
>>>>>> y lista" de Entrada que estás intentando caber no es igual cuando el apoyado
>>>>>> *locales ... Esto es justo una lista de lenguas la interfaz de OS específica tiene
>>>>>> versiones especiales puesto que (*i.*e, el dispositivo entero *UI cambiará). Esto es
>>>>>> *localization, no *locale apoyo.
>>>>>>
>>>>>> La lista de disponible *locales será más *accurate a lo que estás
>>>>>> intentando conseguir, pero es todavía no allí - algunos dispositivos pueden *render
>>>>>> *fonts que son exterior de aquellos disponible *locales.
>>>>>> Esto es porque qué realmente los asuntos en el fin es si tienes el
>>>>>> propio *fonts a *render aquel texto.
>>>>>>
>>>>>> Yo de hecho tratado algo con respecto a aquellos unos cuantos días hace y *i'*m
>>>>>> incluso más confundido... El código de fuente para *TextView/la Pintura  no de hecho
>>>>>> #decir cualquier información en cómo *android consigue el disponible *fonts o cómo decide cuál para utilizar (es todo en código nativo aparentemente)
>>>>>>
>>>>>> Pero *i encontró esto:
>>>>>> *http://www.ulduzsoft.com/2012/**01/enumerando-el-*fonts-encima-**
>>>>>> *android-plataforma/<*http://www.ulduzsoft.com/2012/01/enumerando-el-*fonts-encima-*android-plataforma/>
>>>>>>
>>>>>> te podría dar lo que estás buscando si combinas el
>>>>>> disponible *font lista con el disponible *locales.
>>>>>>
>>>>>>
>>>>>> En martes, junio 11, 2013 7:31:53 PM *UTC+3, *latimerius escribió:
>>>>>>>
>>>>>>> entiendo esto es un *FAQ pero después de que *googling para horas y encontrando
>>>>>>> nada pero cuestiones de foro con ninguna respuesta y un *heap de mal
>>>>>>> (no-funcional) consejo, imaginé preguntaría.
>>>>>>>
>>>>>>> Me gustaría para dejar nuestros usuarios para poner un *locale independiente del
>>>>>>> sistema-ancho un.  Para construir la carta de lenguas disponibles, imaginé
>>>>>>> tomaría una lista de las lenguas apoyadas por el *app y sacar los no
>>>>>>> apoyado por el dispositivo particular.  No querría ofrecer una lengua al
>>>>>>> usuario si el dispositivo puede no *render textos en aquella lengua (dice debido a un
>>>>>>> perdiendo *font o apoyo de código).
>>>>>>>
>>>>>>> Consiguiendo una lista de dispositivo de lenguas puede *render resultado
>>>>>>> sorprendentemente duro aun así.  Siguiendo pistas de *docs y consejo de la
>>>>>>> red, probé
>>>>>>>
>>>>>>> *Locale.*getAvailableLocales()
>>>>>>> Recursos.*getSystem().***getAsset***s().*getLocales() (O justo
>>>>>>> *getAssets().*getLocales() Con resultado mismo)
>>>>>>>
>>>>>>> ninguno del cual consigue el resultado esperado (cuál es algo
>>>>>>> *resembling la lista de lengua en Entrada "de Lengua & del sistema" *settings).  También,
>>>>>>> hay un mencionar en el *docs que *subsystems afectado por *locale *settings
>>>>>>> normalmente ofrecer su medio propio de conseguir una lista de apoyado *locales que
>>>>>>> tendríamos que utilizar en preferencia a *Locale.*getAvailableLocales(****).
>>>>>>>  Justo bastante pero puedo ver no tales funciones en *TextView o Pintura que es
>>>>>>> el *subsystems utilizo para dibujar texto.
>>>>>>>
>>>>>>> Podemos hacer sin *app-específico *locale *settings a pesar de que serían
>>>>>>> guapos de tener.  Aun así, si justo fuera de curiosidad, todavía estoy preguntándome si
>>>>>>> es realmente no posible en *Android para conseguir esto aparentemente pieza fundamental
>>>>>>> de información?
>>>>>>>
>>>>>>>  --
>>>>>> --
>>>>>> Recibiste este mensaje porque eres *subscribed al *Google
>>>>>> Grupos "*Android *Developers" grupo.
>>>>>> A correo a este grupo, envía *email a *android-d...@xxxxxxxxxxxxxxxx
>>>>>> A *unsubscribe de este grupo, envía *email a *android-*developers+**unsubscribe@xxxxxxxxxxxxxxxx
>>>>>> 
>>>>>> Puesto que más opciones, visita este grupo en
>>>>>> *http://grupos.*google.*com/**Grupo/*android-*developers?*hl=*en<*http://Grupos.*google.*com/Grupo/*android-*developers?*hl=*en>
>>>>>> ---
>>>>>> Recibiste este mensaje porque eres *subscribed al *Google
>>>>>> Grupos "*Android *Developers" grupo.
>>>>>> A *unsubscribe de este grupo y la parón que recibe *emails de él,
>>>>>> enviar un *email a *android-*developers+**unsubscribe@xxxxxxxxxxxxxxxx.
>>>>>> Puesto que más opciones, visita *https://grupos.*google.*com/**Los Grupos/optan_fuera de *https://grupos.*google.*com/Los<Grupos/optan_fuera>
>>>>>> .
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>  --
>>> --
>>> Recibiste este mensaje porque eres *subscribed al *Google
>>> Grupos "*Android *Developers" grupo.
>>> A correo a este grupo, envía *email a *android-developers@xxxxxxxxxxxxxxxx
>>> A *unsubscribe de este grupo, envía *email a *android-*developers+unsubscribe@xxxxxxxxxxxxxxxx
>>> 
>>> Puesto que más opciones, visita este grupo en
>>> *http://grupos.*google.*com/Grupo/*android-*developers?*hl=*en
>>> ---
>>> Recibiste este mensaje porque eres *subscribed al *Google
>>> Grupos "*Android *Developers" grupo.
>>> A *unsubscribe de este grupo y la parón que recibe *emails de él, enviar
>>> un *email a *android-*developers+unsubscribe@xxxxxxxxxxxxxxxx.
>>> Puesto que más opciones, visita *https://grupos.*google.*com/Los Grupos/optan_fuera.
>>>
>>>
>>>
>>
>>
>

-- 
Recibiste este mensaje porque eres *subscribed al *Google
Grupos "*Android *Developers" grupo.
A correo a este grupo, envía *email a *android-developers@xxxxxxxxxxxxxxxx
A *unsubscribe de este grupo, envía *email a *android-*developers+unsubscribe@xxxxxxxxxxxxxxxx

Puesto que más opciones, visita este grupo en
*http://grupos.*google.*com/Grupo/*android-*developers?*hl=*en
--- 
Recibiste este mensaje porque eres *subscribed al *Google Grupos "*Android *Developers" grupo.
A *unsubscribe de este grupo y la parón que recibe *emails de él, enviar un *email a *android-*developers+unsubscribe@xxxxxxxxxxxxxxxx.
Puesto que más opciones, visita *https://grupos.*google.*com/Los Grupos/optan_fuera.


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 <l4t1m3r1us@xxxxxxxxx> 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 <l4t1m3r1us@xxxxxxxxx> 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@xxxxxxxxx>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 <gpi...@xxxxxxxxx> 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...@xxxxxxxxxxxxxxxx
>>>>>> To unsubscribe from this group, send email to
>>>>>> android-developers+**unsubscribe@xxxxxxxxxxxxxxxx
>>>>>> 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+**unsubscribe@xxxxxxxxxxxxxxxx.
>>>>>> 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 android-developers@xxxxxxxxxxxxxxxx
>>> To unsubscribe from this group, send email to
>>> android-developers+unsubscribe@xxxxxxxxxxxxxxxx
>>> 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@xxxxxxxxxxxxxxxx.
>>> 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@xxxxxxxxxxxxxxxx
To unsubscribe from this group, send email to
android-developers+unsubscribe@xxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxx.
For more options, visit https://groups.google.com/groups/opt_out.


<Anterior por Tema] Tema Actual [Siguiente por Tema>