Le app includono risorse che possono essere specifiche di una determinata cultura. Ad esempio, un'app può includere stringhe specifiche delle culture che vengono tradotte nella lingua delle impostazioni internazionali correnti.
È buona norma mantenere le risorse specifiche per cultura separate dal resto dell'app. Android risolve le risorse specifiche per lingua e cultura in base alle impostazioni internazionali del sistema. Puoi fornire supporto per diverse impostazioni internazionali utilizzando la directory delle risorse nel tuo progetto Android.
Puoi specificare risorse personalizzate in base alle culture delle persone che utilizzano la tua app. Puoi fornire qualsiasi tipo di risorsa appropriato per la lingua e la cultura degli utenti. Ad esempio, i seguenti screenshot mostrano un'app che mostra stringhe e risorse disegnabili nell'impostazione internazionale en_US
predefinita del dispositivo e in quella es_ES
spagnola.
![L'app mostra un testo e un'icona diversi a seconda delle impostazioni internazionali](https://developer.android.com/static/images/training/languages_01.png?authuser=6&hl=it)
Figura 1. L'app utilizza risorse diverse a seconda delle impostazioni internazionali attuali.
Quando crei un progetto utilizzando Android SDK Tools, gli strumenti generano una directory res/
nel livello superiore del progetto. All'interno di questa directory res/
sono presenti sottodirectory per vari tipi di risorse. Esistono anche alcuni file predefiniti, come il file res/values/strings.xml
, che contiene i valori stringa.
Il supporto di diverse lingue va oltre l'utilizzo di risorse specifiche per le diverse impostazioni internazionali. Alcuni utenti scelgono una lingua che utilizza script da destra a sinistra (RTL), ad esempio arabo o ebraico, per le impostazioni internazionali dell'interfaccia utente. Gli altri utenti che impostano le impostazioni internazionali dell'interfaccia utente su una lingua che utilizza script LTR, ad esempio l'inglese, potrebbero visualizzare o generare contenuti in una lingua che utilizza gli script RTL. Per supportare entrambi i tipi di utenti, la tua app deve:
- Utilizza un layout UI RTL per le impostazioni internazionali RTL.
- Rileva e dichiara la direzione dei dati di testo visualizzati all'interno dei messaggi formattati. In genere, puoi chiamare un metodo, come descritto in questa guida, che determina la direzione dei dati di testo per te.
Crea directory internazionali e file di risorse
Per aggiungere il supporto per più impostazioni internazionali, crea directory aggiuntive all'interno di res/
. Il nome di ogni directory deve avere il seguente formato:
<resource type>-b+<language code>[+<country code>]
Ad esempio, values-b+es/
contiene risorse stringa per le impostazioni internazionali con il codice lingua es
. Allo stesso modo, mipmap-b+es+ES/
contiene icone per le impostazioni internazionali con il codice lingua es
e il codice paese ES
.
Android carica le risorse appropriate in base alle impostazioni internazionali del dispositivo in fase di runtime. Per ulteriori informazioni, consulta Fornire risorse alternative.
Dopo aver deciso quali impostazioni internazionali supportare, crea le sottodirectory e i file delle risorse. Ecco alcuni esempi:
MyProject/ res/ values/ strings.xml values-b+es/ strings.xml mipmap/ country_flag.png mipmap-b+es+ES/ country_flag.png
Completa i file delle risorse con le risorse localizzate. Di seguito sono riportati alcuni esempi di file di risorse di immagini e stringhe localizzate:
Stringhe in inglese (impostazioni internazionali predefinite) in /values/strings.xml
:
<resources> <string name="hello_world">Hello World!</string> </resources>
Stringhe in spagnolo (es
impostazioni internazionali) in /values-b+es/strings.xml
:
<resources> <string name="hello_world">¡Hola Mundo!</string> </resources>
Icona della bandiera degli Stati Uniti (impostazione internazionale predefinita) in /mipmap/country_flag.png
:
![L'icona della bandiera
degli Stati Uniti](https://developer.android.com/static/images/training/languages_us_flag.png?authuser=6&hl=it)
Figura 2. Icona utilizzata per le impostazioni internazionali predefinite (en_US).
Icona con la bandiera spagnola (es_ES
impostazioni internazionali) in
/mipmap-b+es+ES/country_flag.png
:
![L'icona della bandiera
della Spagna](https://developer.android.com/static/images/training/languages_es_flag.png?authuser=6&hl=it)
Figura 3. Icona utilizzata per le impostazioni internazionali es_ES
.
Nota: puoi utilizzare i qualificatori di configurazione, ad esempio il qualificatore delle impostazioni internazionali, su qualsiasi tipo di risorsa. Ad esempio, potresti voler fornire versioni localizzate dei disegnabili bitmap. Per saperne di più, consulta Localizzare l'app.
Usa le risorse nella tua app
Fai riferimento alle risorse nel tuo codice sorgente e in altri file XML utilizzando
l'attributo name
di ogni risorsa:
R.<resource type>.<resource name>
. Esistono vari metodi che accettano una risorsa in questo modo, come mostrato nei seguenti esempi:
Kotlin
// Get a string resource val hello = resources.getString(R.string.hello_world) // Or supply a string resource to a method that requires a string TextView(this).apply { setText(R.string.hello_world) }
Java
// Get a string resource String hello = getResources().getString(R.string.hello_world); // Or supply a string resource to a method that requires a string TextView textView = new TextView(this); textView.setText(R.string.hello_world);
Nei file XML, puoi fare riferimento a una risorsa con la sintassi @<resource type>/<resource name>
ogni volta che l'attributo XML accetta un valore compatibile, come mostrato nell'esempio seguente:
<ImageView android:layout_width="wrap_content" android:layout_height="wrap_content" android:src="@mipmap/country_flag" />
Nota: per assicurarti che la priorità delle impostazioni della lingua dell'utente sia corretta, specifica le lingue supportate dalla tua app utilizzando la proprietà resConfigs
. Per ulteriori informazioni, consulta la sezione Specificare le lingue supportate dall'app.
Formattare il testo dei messaggi
Una delle attività più comuni in un'app è la formattazione del testo. I messaggi localizzati vengono formattati inserendo testo e dati numerici nelle posizioni appropriate. Purtroppo, quando si gestiscono dati RTL o UI RTL, la formattazione semplice può mostrare un output di testo errato o persino illeggibile.
Lingue come l'arabo, l'ebraico, il persiano e l'urdu sono scritte in formato RTL. Tuttavia, alcuni elementi, come numeri e testo LTR incorporato, sono scritti in LTR all'interno del testo RTL. Anche le lingue che utilizzano gli script LTR, tra cui l'inglese, sono bidirezionali perché possono contenere script RTL incorporati che devono essere visualizzati in formato RTL.
Le app spesso generano istanze di questo tipo di testo incorporato di direzione opposta, ad esempio inserendo dati di testo di una lingua arbitraria e di una direzione del testo arbitraria nei messaggi localizzati. Questa combinazione di indicazioni spesso non include un'indicazione chiara di dove inizia e finisce il testo in direzione opposta, pertanto il testo generato dall'app può causare un'esperienza utente scadente.
Anche se la gestione predefinita del testo bidirezionale da parte del sistema di solito esegue il rendering del testo come previsto, il testo potrebbe non essere visualizzato correttamente quando l'app lo inserisce in un messaggio localizzato. Di seguito sono riportati alcuni esempi di situazioni in cui è probabile che il testo venga visualizzato in modo errato:
-
Testo inserito all'inizio di un messaggio:
PERSON_NAME ti sta chiamando
-
Testo che inizia con un numero, ad esempio un indirizzo o un numero di telefono:
987 654 3210
-
Testo che inizia con la punteggiatura, ad esempio un numero di telefono:
+19876543210
-
Testo che termina con la punteggiatura:
Confermi?
-
Testo che contiene già entrambe le direzioni:
La parola בHOUR comparire è l'ebraico che significa banana.
Esempio
Supponi che a volte un'app debba visualizzare il messaggio "Forse cercavi %s?", con un indirizzo inserito al posto di %s in fase di runtime. L'app supporta diverse impostazioni internazionali dell'interfaccia utente, quindi il messaggio proviene da una risorsa specifica delle impostazioni internazionali e utilizza la direzione RTL quando il dispositivo è impostato su un'impostazione internazionale RTL. Ad esempio, per una UI in ebraico, il messaggio è il seguente:
L'account è stato rimosso da %s?
Tuttavia, l'indirizzo suggerito potrebbe provenire da un database che non include testo nella lingua dell'impostazione internazionale. Ad esempio, se l'indirizzo è di un luogo in California, viene visualizzato nel database con testo in inglese. Se inserisci l'indirizzo"15 Bay Street, Laurel, CA" nel messaggio RTL senza fornire suggerimenti sulla direzione del testo, il risultato non è previsto o corretto:
乭乭乏乍卩取め 15 Bay Street, Laurel, California?
Il numero civico si trova a destra dell'indirizzo, non a sinistra come previsto. In questo modo il numero civico assomiglia di più a uno strano codice postale. Lo stesso problema può verificarsi se includi testo RTL in un messaggio che utilizza la direzione del testo LTR.
Spiegazione e soluzione
Il problema in questo esempio si verifica perché il formattatore di testo non specifica che "15 " fa parte dell'indirizzo, quindi il sistema non è in grado di determinare se "15" fa parte del testo RTL che lo precede o del testo LTR successivo.
Per risolvere questo problema, utilizza il metodo unicodeWrap()
dalla classe BidiFormatter
. Questo metodo rileva la direzione di una stringa e la inserisce nei caratteri di formattazione Unicode che la dichiarano.
Il seguente snippet di codice mostra come utilizzare unicodeWrap()
:
Kotlin
val mySuggestion = "15 Bay Street, Laurel, CA" val myBidiFormatter: BidiFormatter = BidiFormatter.getInstance() // The "did_you_mean" localized string resource includes // a "%s" placeholder for the suggestion. String.format(getString(R.string.did_you_mean), myBidiFormatter.unicodeWrap(mySuggestion))
Java
String mySuggestion = "15 Bay Street, Laurel, CA"; BidiFormatter myBidiFormatter = BidiFormatter.getInstance(); // The "did_you_mean" localized string resource includes // a "%s" placeholder for the suggestion. String.format(getString(R.string.did_you_mean), myBidiFormatter.unicodeWrap(mySuggestion));
Poiché il "15" ora compare all'interno del testo dichiarato come LTR, viene visualizzato nella posizione corretta:
乭乏乏乏叩rtoreo, 15 Bay Street, Laurel, CA?
Utilizza il metodo unicodeWrap()
su ogni parte di testo inserita in un messaggio localizzato, tranne nei casi seguenti:
- Il testo viene inserito in una stringa leggibile dalla macchina, come un URI o una query SQL.
- Il testo è già a capo.
Nota: se la tua app ha come target Android 4.3 (livello API 18) o versioni successive, utilizza la versione di BidiFormatter
presente nel framework Android. In caso contrario, utilizza la versione di BidiFormatter
che si trova nella libreria di supporto.
Formattare i numeri
Utilizza le stringhe di formato, non le chiamate di metodo, per convertire i numeri in stringhe nella logica dell'app:
Kotlin
var myIntAsString = "$myInt"
Java
String myIntAsString = String.format("%d", myInt);
In questo modo i numeri vengono formattati in base alle tue impostazioni internazionali e possono includere l'uso di un insieme di cifre diverso.
Quando utilizzi String.format()
per creare una query SQL su un dispositivo impostato su un'impostazione internazionale che utilizza il proprio insieme di cifre, ad esempio il persiano e la maggior parte delle lingue arabe, si verificano problemi se uno dei parametri della query sono numeri. Il motivo è che il numero è formattato con le cifre delle impostazioni internazionali, che non sono valide in SQL.
Per preservare i numeri in formato ASCII e mantenere valida la query SQL, devi utilizzare
la versione sovraccaricata di
String.format()
che
include un'impostazione internazionale come primo parametro. Utilizza l'argomento delle impostazioni internazionali Locale.US
.
Supporta il mirroring del layout
Le persone che utilizzano gli script RTL preferiscono un'interfaccia utente RTL, che include menu allineati a destra, testo allineato a destra e frecce in avanti che puntano a sinistra.
La Figura 4 mostra il contrasto tra la versione LTR di una schermata dell'app Impostazioni e la relativa controparte RTL:
![L'area di notifica è allineata a destra vicino all'angolo in alto a destra, il pulsante del menu nella barra delle app si trova vicino all'angolo in alto a sinistra, i contenuti nella parte principale dello schermo sono allineati a sinistra e appaiono in LTR, mentre il pulsante indietro si trova vicino all'angolo in basso a sinistra e punta a sinistra.](https://developer.android.com/static/images/training/basics/ltr-display.png?authuser=6&hl=it)
![L'area di notifica è allineata a sinistra vicino all'angolo in alto a sinistra, il pulsante del menu nella barra delle app si trova vicino all'angolo in alto a destra, i contenuti nella parte principale dello schermo sono allineati a destra e appaiono in formato RTL, mentre il pulsante Indietro si trova vicino all'angolo in basso a destra e punta a destra.](https://developer.android.com/static/images/training/basics/rtl-display.png?authuser=6&hl=it)
Quando aggiungi il supporto RTL alla tua app, tieni presente quanto segue:
- Il mirroring del testo RTL è supportato nelle app solo se utilizzato su dispositivi con Android 4.2 (livello API 17) o versioni successive. Per informazioni su come supportare il mirroring del testo su dispositivi meno recenti, vedi Fornire supporto per app legacy in questa guida.
- Per verificare se la tua app supporta una direzione del testo RTL, esegui il test utilizzando le opzioni sviluppatore come descritto in questa guida e invita le persone che utilizzano gli script RTL a utilizzare la tua app.
Nota: per visualizzare ulteriori linee guida sulla progettazione relative al mirroring del layout, incluso un elenco degli elementi che sono e non sono appropriati per il mirroring, consulta le linee guida per la progettazione del materiale sulla bidirezionale.
Per eseguire il mirroring del layout della UI nella tua app in modo che appaia RTL in impostazioni internazionali RTL, completa i passaggi nelle sezioni seguenti.
Modifica i file di build e manifest
Modifica il file build.gradle
e il file manifest dell'app del modulo dell'app come segue:
build.gradle (Module: app)
Trendy
android { ... defaultConfig { targetSdkVersion 17 // Or higher ... } }
Kotlin
android { ... defaultConfig { targetSdkVersion(17) // Or higher ... } }
AndroidManifest.xml
<manifest ... > ... <application ... android:supportsRtl="true"> </application> </manifest>
Nota: se la tua app ha come target Android 4.1.1 (livello API 16) o versioni precedenti, l'attributo android:supportsRtl
viene ignorato, insieme a tutti i valori degli attributi start
e end
visualizzati nei file di layout dell'app. In questo caso, il mirroring del layout RTL non avviene automaticamente nella tua app.
Aggiorna risorse esistenti
Converti left
e right
in start
e
end
, rispettivamente, nei file delle risorse di layout esistenti.
In questo modo il framework allinea gli elementi UI dell'app in base alle impostazioni della lingua dell'utente.
Nota: prima di aggiornare le risorse, scopri come fornire assistenza per le app legacy o per le app destinate ad Android 4.1.1 (livello API 16) e versioni precedenti.
Per utilizzare le funzionalità di allineamento RTL del framework, modifica gli attributi nei file di layout che vengono visualizzati nella Tabella 1.
Tabella 1. Attributi da utilizzare quando l'app supporta più direzioni testuali
La tabella 2 mostra in che modo il sistema gestisce gli attributi di allineamento dell'interfaccia utente in base alla versione dell'SDK target, se sono stati definiti gli attributi left
e right
e se sono stati definiti gli attributi start
e end
.
Tabella 2. Il comportamento di allineamento degli elementi UI basato sulla versione target dell'SDK e sugli attributi definiti
|
Sinistra e destra definite? | Inizio e fine definiti? | Risultato |
---|---|---|---|
Sì | Sì | Sì |
Vengono utilizzati start e end , sostituendo
left e right
|
Sì | Sì | No | left e right sono in uso |
Sì | No | Sì | start e end sono in uso |
No | Sì | Sì |
Vengono utilizzati left e right (start e end vengono ignorati)
|
No | Sì | No | left e right sono in uso |
No | No | Sì |
start e end restituiscono left e
right
|
Aggiungi risorse specifiche per le indicazioni e le lingue
Questo passaggio prevede l'aggiunta di versioni specifiche dei file di risorse di layout, disegnabili e valori che contengono valori personalizzati per diverse lingue e direzioni di testo.
In Android 4.2 (livello API 17) e versioni successive, puoi utilizzare i qualificatori delle risorse -ldrtl
(layout-direction-right-to-left) e -ldltr
(layout-direction-left-to-right). Per mantenere la compatibilità con le versioni precedenti delle risorse, le versioni precedenti di Android utilizzano i qualificatori del linguaggio di una risorsa per dedurre la direzione del testo corretta.
Supponiamo che tu voglia aggiungere un file di layout specifico per supportare gli script RTL, ad esempio ebraico, arabo e persiano. A questo scopo, aggiungi una directory layout-ldrtl/
nella directory res/
, come mostrato nell'esempio seguente:
res/ layout/ main.xml This layout file is loaded by default. layout-ldrtl/ main.xml This layout file is loaded for languages using an RTL text direction, including Arabic, Persian, and Hebrew.
Se vuoi aggiungere una versione specifica del layout progettata solo per il testo in arabo, la struttura della directory sarà la seguente:
res/ layout/ main.xml This layout file is loaded by default. layout-ar/ main.xml This layout file is loaded for Arabic text. layout-ldrtl/ main.xml This layout file is loaded only for non-Arabic languages that use an RTL text direction.
Nota: le risorse specifiche per lingua hanno la precedenza sulle risorse specifiche per layout-direction, che hanno la precedenza sulle risorse predefinite.
Utilizzare i widget supportati
A partire da Android 4.2 (livello API 17), la maggior parte degli elementi UI del framework supporta automaticamente la direzione del testo RTL. Tuttavia, diversi elementi del framework, come ViewPager
, non supportano la direzione relativa al testo RTL.
I widget della schermata Home supportano la direzione del testo RTL purché i file manifest corrispondenti includano l'assegnazione dell'attributo android:supportsRtl="true"
.
Fornire assistenza per le app legacy
Se la tua app ha come target Android 4.1.1 (livello API 16) o versioni precedenti, includi gli attributi left
e right
oltre a start
e end
.
Per verificare se il layout deve utilizzare la direzione del testo RTL, utilizza la seguente logica:
Kotlin
private fun shouldUseLayoutRtl(): Boolean { return if (android.os.Build.VERSION.SDK_INT >= android.os.Build.VERSION_CODES.JELLY_BEAN_MR1) { View.LAYOUT_DIRECTION_RTL == layoutDirection } else { false } }
Java
private boolean shouldUseLayoutRtl() { if (android.os.Build.VERSION.SDK_INT >= android.os.Build.VERSION_CODES.JELLY_BEAN_MR1) { return View.LAYOUT_DIRECTION_RTL == getLayoutDirection(); } else { return false; } }
Nota: per evitare problemi di compatibilità, utilizza la versione 23.0.1 o successive degli Strumenti di creazione dell'SDK Android.
Esegui un test utilizzando Opzioni sviluppatore
Sui dispositivi con Android 4.4 (livello API 19) o versioni successive, puoi attivare l'opzione Forza la direzione del layout RTL nelle opzioni per sviluppatori on-device. Questa impostazione consente di visualizzare il testo che utilizza gli script LTR, ad esempio il testo inglese, in modalità RTL.
Aggiorna logica dell'app
Questa sezione descrive aspetti specifici della logica dell'app da aggiornare quando la adatti alla gestione di più direzioni di testo.
Modifiche alla proprietà
Per gestire una modifica in qualsiasi proprietà relativa a RTL, ad esempio direzione di layout, parametri di layout, spaziatura interna, direzione del testo, allineamento del testo o posizionamento disegnabile, utilizza il callback onRtlPropertiesChanged()
. Questo callback consente di ottenere la direzione del layout corrente e
aggiornare di conseguenza gli oggetti View
di un'attività.
Visualizzazioni
Se crei un widget dell'interfaccia utente che non fa direttamente parte della gerarchia delle visualizzazioni di un'attività, ad esempio una finestra di dialogo o un elemento UI in stile toast, imposta la direzione di layout corretta in base al contesto. Il seguente snippet di codice mostra come completare questa procedura:
Kotlin
val config: Configuration = context.resources.configuration view.layoutDirection = config.layoutDirection
Java
final Configuration config = getContext().getResources().getConfiguration(); view.setLayoutDirection(config.getLayoutDirection());
Diversi metodi della classe View
richiedono un'ulteriore
considerazione:
onMeasure()
- Le misurazioni della visualizzazione potrebbero variare a seconda della direzione del testo.
onLayout()
- Se crei la tua implementazione del layout, devi chiamare
super()
nella tua versione dionLayout()
e adattare la logica personalizzata per supportare gli script RTL. onDraw()
- Se stai implementando una vista personalizzata o stai aggiungendo funzionalità avanzate a un disegno, devi aggiornare il codice per supportare gli script RTL. Utilizza il
codice seguente per determinare se il widget è in modalità RTL:
Kotlin
// On devices running Android 4.1.1 (API level 16) and lower, // you can call the isLayoutRtl() system method directly. fun isLayoutRtl(): Boolean = layoutDirection == LAYOUT_DIRECTION_RTL
Java
// On devices running Android 4.1.1 (API level 16) and lower, // you can call the isLayoutRtl() system method directly. public boolean isLayoutRtl() { return (getLayoutDirection() == LAYOUT_DIRECTION_RTL); }
Disegnabili
Se hai un elemento disegnabile che deve essere sottoposto a mirroring per un layout RTL, completa uno di questi passaggi in base alla versione di Android in esecuzione sul dispositivo:
-
Sui dispositivi con Android 4.3 (livello API 18) e versioni precedenti, aggiungi e definisci i file delle risorse
-ldrtl
. -
Su Android 4.4 (livello API 19) e versioni successive, utilizza
android:autoMirrored="true"
per definire il disegno a mano libera, che consente al sistema di gestire il mirroring del layout RTL per te.Nota: l'attributo
android:autoMirrored
funziona solo per i disegnabili semplici il cui mirroring bidirezionale è semplicemente un mirroring grafico dell'intero disegno a disegno. Se l'elemento disegnabile contiene più elementi o se riflette la sua interpretazione, puoi eseguire il mirroring autonomamente. Quando possibile, consulta un esperto bidirezionale per determinare se i disegnabili con mirroring hanno senso per gli utenti.
Gravity
Se il codice di layout della tua app utilizza Gravity.LEFT
o Gravity.RIGHT
, modifica questi valori rispettivamente in Gravity.START
e Gravity.END
.
Se hai un codice Kotlin o Java che dipende dalle
proprietà Gravity.LEFT
o Gravity.RIGHT
,
puoi adattarlo affinché funzioni con questa modifica impostando absoluteGravity
in modo che corrisponda a
layoutDirection
.
Ad esempio, se utilizzi il seguente codice:
Kotlin
when (gravity and Gravity.HORIZONTAL_GRAVITY_MASK) { Gravity.LEFT -> { // Handle objects that are left-aligned. } Gravity.RIGHT -> { // Handle objects that are right-aligned. } }
Java
switch (gravity & Gravity.HORIZONTAL_GRAVITY_MASK) { case Gravity.LEFT: // Handle objects that are left-aligned. break; case Gravity.RIGHT: // Handle objects that are right-aligned. break; }
Modificalo nel seguente modo:
Kotlin
val absoluteGravity: Int = Gravity.getAbsoluteGravity(gravity, layoutDirection) when (absoluteGravity and Gravity.HORIZONTAL_GRAVITY_MASK) { Gravity.LEFT -> { // Handle objects that are left-aligned. } Gravity.RIGHT -> { // Handle objects that are right-aligned. } }
Java
final int layoutDirection = getLayoutDirection(); final int absoluteGravity = Gravity.getAbsoluteGravity(gravity, layoutDirection); switch (absoluteGravity & Gravity.HORIZONTAL_GRAVITY_MASK) { case Gravity.LEFT: // Handle objects that are left-aligned. break; case Gravity.RIGHT: // Handle objects that are right-aligned. break; }
Ciò significa che puoi mantenere il codice esistente che gestisce i valori allineati a sinistra e a destra, anche se utilizzi start
e end
per i valori di gravità.
Nota: quando applichi le impostazioni di gravità, usa una versione sovraccaricata di Gravity.apply()
che include un argomento layoutDirection
.
Margini e spaziatura interna
Per supportare gli script RTL nella tua app, segui queste best practice relative ai valori di margine e spaziatura interna:
-
Utilizza
getMarginStart()
egetMarginEnd()
anziché gli equivalenti degli attributi specifici delle indicazioni stradalileftMargin
erightMargin
. -
Quando utilizzi
setMargins()
, scambia i valori degli argomentileft
eright
se la tua app rileva script RTL. -
Se la tua app include una logica di spaziatura interna personalizzata, esegui l'override di
setPadding()
esetPaddingRelative()
.
Supporto delle preferenze di lingua delle app
In molti casi, gli utenti multilingue impostano la lingua di sistema su una lingua, ad esempio l'inglese, ma desiderano selezionare altre lingue per app specifiche, ad esempio olandese, cinese o hindi. Per aiutare le app a offrire un'esperienza migliore a questi utenti, Android 13 introduce le seguenti funzionalità per le app che supportano più lingue:
-
Impostazioni di sistema: una posizione centralizzata in cui gli utenti possono selezionare una lingua preferita per ogni app.
L'app deve dichiarare l'attributo
android:localeConfig
nel file manifest per indicare al sistema che supporta più lingue. Per scoprire di più, consulta le istruzioni per creare un file di risorse e dichiararlo nel file manifest dell'app. -
API aggiuntive: queste API pubbliche, come i metodi l10n-placeholder1">
setApplicationLocales()
e l10n-placeholder2">getApplicationLocales()
inLocaleManager
, consentono alle app di impostare una lingua diversa da quella di sistema al runtime.Le app che usano selettori della lingua in-app personalizzati possono usare queste API per offrire agli utenti un'esperienza utente coerente, indipendentemente da dove selezionino le preferenze linguistiche. Inoltre, le API pubbliche ti aiutano a ridurre la quantità di codice boilerplate e supportano APK divisi. Supportano inoltre Backup automatico per le app per archiviare le impostazioni della lingua dell'utente a livello di app.
Per garantire la compatibilità con le versioni precedenti di Android, in AndroidX sono disponibili anche API equivalenti. Ti consigliamo di utilizzare Appcompat 1.6.0-beta01 o versioni successive.
Per saperne di più, consulta le istruzioni per implementare le nuove API.
Vedi anche
Risorse aggiuntive
Per ulteriori informazioni sul supporto dei dispositivi meno recenti, consulta le seguenti risorse:
Post del blog
- Per rendere le app accessibili, rendile compatibili con dispositivi diversi
- Scrivere per un pubblico globale