Assurer la compatibilité avec différentes langues et cultures

Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Les applications contiennent des ressources qui peuvent être propres à une culture. Une application donnée peut, par exemple, inclure des chaînes spécifiques à une culture qui sont traduites dans la langue définie dans les paramètres régionaux actuels. Il est recommandé de séparer les ressources propres à une culture du reste de votre application. Android résout les ressources propres à une langue ou à une culture en fonction des paramètres régionaux du système. Vous pouvez assurer la compatibilité de différents paramètres régionaux à l'aide du répertoire de ressources de votre projet Android.

Vous pouvez spécifier des ressources adaptées à la culture des personnes qui utilisent votre application. Vous pouvez fournir n'importe quel type de ressource adapté à la langue et à la culture de vos utilisateurs. Par exemple, la capture d'écran suivante illustre une application qui affiche des ressources drawables et de chaîne dans les paramètres régionaux par défaut de l'appareil (en_US) et en espagnol (es_ES).

L'application affiche un texte et une icône différents en fonction des paramètres régionaux actuels.

Figure 1. Application utilisant des ressources différentes en fonction des paramètres régionaux actuels

Si vous avez créé votre projet à l'aide de SDK Tools pour Android (voir Créer un projet Android), un répertoire res/ est créé au premier niveau du projet. Ce répertoire res/ contient des sous-répertoires pour différents types de ressource. Il existe également quelques fichiers par défaut tels que res/values/strings.xml, qui contiennent vos valeurs de chaîne.

La compatibilité avec plusieurs langues ne se limite pas à l'utilisation de ressources propres aux paramètres régionaux. Certains utilisateurs choisissent une langue qui se lit de droite à gauche, comme l'arabe ou l'hébreu, dans les paramètres régionaux de leur UI. Cependant, d'autres affichent ou génèrent du contenu dans une langue qui se lit de droite à gauche, même si celle qu'ils ont définie dans les paramètres régionaux de leur UI se lit de gauche à droite, comme l'anglais. Pour gérer ces deux types d'utilisateurs, votre application doit respecter les conditions suivantes :

  • Utiliser une mise en page d'interface utilisateur de droite à gauche pour les paramètres régionaux de ce type
  • Détecter et déclarer l'orientation des données de texte affichées dans les messages mis en forme En règle générale, vous pouvez simplement appeler une méthode qui détermine l'orientation des données de texte à votre place.

Créer des fichiers de ressources et des répertoires de paramètres régionaux

Pour accepter davantage de paramètres régionaux, créez des répertoires supplémentaires dans res/. Le nom de chaque répertoire doit respecter le format suivant :

<resource type>-b+<language code>[+<country code>]

Par exemple, values-b+es/ contient des ressources de chaîne pour les paramètres régionaux dont le code de langue est es. De même, mipmap-b+es+ES/ contient des icônes pour les paramètres régionaux avec le code de langue es et le code pays ES. Android charge les ressources appropriées en fonction des paramètres régionaux de l'appareil au moment de l'exécution. Pour en savoir plus, consultez Fournir d'autres ressources.

Une fois que vous avez choisi les paramètres régionaux à accepter, créez les fichiers et les sous-répertoires de ressources. Exemple :

MyProject/
    res/
       values/
           strings.xml
       values-b+es/
           strings.xml
       mipmap/
           country_flag.png
       mipmap-b+es+ES/
           country_flag.png

Voici quelques exemples de fichiers de ressources pour différentes langues :

Chaînes en anglais (paramètres régionaux par défaut), /values/strings.xml :

<resources>
    <string name="hello_world">Hello World!</string>
</resources>

Chaînes en espagnol (paramètres régionaux es), /values-es/strings.xml :

<resources>
    <string name="hello_world">¡Hola Mundo!</string>
</resources>

Icône du drapeau des États-Unis (paramètres régionaux par défaut), /mipmap/country_flag.png :

Icône du drapeau des États-Unis

Figure 2. Icône utilisée pour les paramètres régionaux par défaut (en_US)

Icône du drapeau espagnol (paramètres régionaux es_ES), /mipmap-b+es+ES/country_flag.png :

Icône du drapeau espagnol

Figure 3. Icône utilisée pour les paramètres régionaux es_ES

Remarque : Vous pouvez utiliser le qualificatif de paramètres régionaux (ou n'importe quel qualificatif de configuration) sur tout type de ressource ; par exemple, si vous souhaitez fournir des versions localisées de votre drawable bitmap. Pour en savoir plus, consultez Localisation.

Utiliser les ressources de votre application

Vous pouvez référencer les ressources de votre code source et d'autres fichiers XML à l'aide de l'attribut name de chaque ressource.

Dans votre code source, vous pouvez faire référence à une ressource en utilisant la syntaxe R.<resource type>.<resource name>. Plusieurs méthodes acceptent une ressource de cette façon.

Exemple :

Kotlin

// Get a string resource from your app's Resources
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 from your app's Resources
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);

Dans d'autres fichiers XML, vous pouvez faire référence à une ressource avec la syntaxe @<resource type>/<resource name> chaque fois que l'attribut XML accepte une valeur compatible.

Exemple :

<ImageView
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:src="@mipmap/country_flag" />

Important : Pour garantir que la priorité est donnée aux paramètres de langue de l'utilisateur, spécifiez les langues acceptées par votre application à l'aide de la propriété resConfigs. Pour en savoir plus, consultez Spécifier les langues acceptées par votre application.

Mettre en forme le texte dans des messages

La mise en forme du texte est l'une des tâches les plus courantes dans une application. Les messages localisés sont mis en forme en insérant du texte et des données numériques aux emplacements appropriés. Malheureusement, lorsqu'il s'agit d'une UI ou de données se lisant de droite à gauche, une mise en forme simple peut générer une sortie textuelle incorrecte, voire illisible.

Des langues telles que l'arabe, l'hébreu, le persan et l'ourdou s'écrivent généralement de droite à gauche. Cependant, certains de leurs éléments, comme les nombres et le texte de gauche à droite intégré, s'écrivent dans l'autre sens. Les langues qui se lisent de gauche à droite, y compris l'anglais, sont aussi bidirectionnelles, car elles peuvent intégrer des scripts de droite à gauche qui doivent être affichés selon cette orientation.

La plupart du temps, ce sont les applications qui génèrent elles-mêmes de telles instances de texte intégré dans le sens inverse. Elles insèrent des données de texte d'une langue arbitraire, et selon une orientation arbitraire, dans des messages localisés. Bien souvent, rien n'indique clairement où commence et où se termine le texte dans le sens inverse. Ces caractéristiques de texte généré par l'application sont à l'origine de la plupart des problèmes.

En règle générale, la façon dont le système gère par défaut le texte bidirectionnel garantit un rendu correct. Cependant, il arrive que le texte ne s'affiche pas correctement lorsque votre application l'insère dans un message localisé. Voici quelques exemples dans lesquels il est plus que probable que le texte ne s'affichera pas correctement :

  • Texte inséré au tout début du message :

    PERSON_NAME vous appelle

  • Texte commençant par un chiffre, comme dans des adresses ou des numéros de téléphone :

    987 654-3210

  • Texte commençant par un signe de ponctuation, comme dans un numéro de téléphone :

    +19876543210

  • Texte se terminant par un signe de ponctuation :

    Voulez-vous continuer ?

  • Texte contenant déjà les deux orientations :

    Le mot בננה signifie "banane" en hébreu.

Exemple

Supposons qu'une application doive parfois afficher le message "Vous vouliez dire %s ?", avec une adresse insérée à la place de %s au moment de l'exécution. Étant donné que l'application accepte différents paramètres régionaux pour l'UI, le message provient d'une ressource spécifique et se lit de droite à gauche lorsque les paramètres régionaux définissant cette orientation sont utilisés. Pour une UI en hébreu, le message se présentera comme suit :

האם התכוונת ל %s?

La suggestion peut toutefois provenir d'une base de données qui n'inclut pas de texte dans la langue des paramètres régionaux. Par exemple, si l'adresse en question correspond à un lieu en Californie, elle apparaît en anglais dans la base de données. Si vous insérez l'adresse "15 Bay Street, Laurel, CA" dans le message lu de droite à gauche sans fournir d'indication concernant l'orientation du texte, soit le résultat n'est pas conforme aux attentes, soit il est incorrect :

האם התכוונת ל 15 Bay Street, Laurel, CA?

Notez que le numéro de maison apparaît à droite de l'adresse, et non à gauche comme prévu, et ressemble davantage à un code postal étrange. Le même problème peut se produire si vous incluez du texte lu de droite à gauche dans un message lu dans l'autre sens.

Explication et solution

Le problème de l'exemple précédent est dû au fait que l'outil de mise en forme du texte ne précise pas que "15" fait partie de l'adresse. Le système ne peut donc pas déterminer si "15" fait partie du texte lu de droite à gauche qui précède ou du texte lu de gauche à droite qui vient après.

Pour résoudre ce problème, utilisez la méthode unicodeWrap(), qui se trouve dans la classe BidiFormatter, sur chaque élément de texte que vous insérez dans un message localisé. Vous ne devez pas utiliser unicodeWrap() dans les cas suivants :

  • Le texte est inséré dans une chaîne lisible par un ordinateur, comme un URI ou une requête SQL.
  • Vous savez déjà que l'élément de texte est correctement encapsulé.

La méthode unicodeWrap() détecte l'orientation d'une chaîne et l'encapsule dans des caractères de formatage Unicode qui déclarent cette orientation. Comme le "15" se trouve maintenant dans le texte déclaré comme étant lu de gauche à droite, il s'affiche au bon endroit :

האם התכוונת ל 15 Bay Street, Laurel, CA?

L'extrait de code suivant montre comment utiliser 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));

Remarque : Si votre application cible Android 4.3 (niveau d'API 18) ou version ultérieure, utilisez la version de BidiFormatter disponible dans le framework Android. Sinon, utilisez la version de BidiFormatter disponible dans la bibliothèque Support.

Mettre en forme les nombres

Utilisez des chaînes de format, et non des appels de méthode, pour convertir des nombres en chaînes dans la logique de votre application :

Kotlin

var myIntAsString = "$myInt"

Java

String myIntAsString = String.format("%d", myInt);

Les nombres seront ainsi mis en forme conformément à vos paramètres régionaux, ce qui peut impliquer l'utilisation d'un ensemble de chiffres différent.

Lorsque vous utilisez String.format() pour créer une requête SQL sur un appareil dont les paramètres régionaux utilisent leur propre ensemble de chiffres, comme le persan et la plupart des paramètres régionaux arabes, des problèmes se produisent si l'un des paramètres de la requête est un nombre. Cela est dû au fait que le nombre est mis en forme selon les chiffres des paramètres régionaux, lesquels ne sont pas valides en langage SQL.

Pour conserver les nombres au format ASCII et faire en sorte que la requête SQL reste valide, vous devez utiliser à la place la version surchargée de String.format() dont le premier paramètre correspond à des paramètres régionaux. L'argument des paramètres régionaux doit être Locale.US.

Prendre en charge la mise en miroir de la mise en page

Les personnes qui utilisent des langues qui se lisent de droite à gauche préfèrent une interface utilisateur ayant le même sens de lecture, avec du texte et des menus alignés à droite, ainsi que des flèches vers l'avant pointant vers la gauche.

La figure 4 montre la différence entre les versions de gauche à droite et de droite à gauche d'un écran de l'application Paramètres :

La zone de notification est alignée à droite dans l'angle supérieur droit, le bouton de menu dans la barre d'application est situé dans l'angle supérieur gauche, et le contenu dans la partie principale de l'écran est aligné à gauche et se lit de gauche à droite. Le bouton "Retour" se trouve dans l'angle inférieur gauche et pointe vers la gauche. La zone de notification est alignée à gauche dans l'angle supérieur gauche, le bouton de menu dans la barre d'application est situé dans l'angle supérieur droit, et le contenu dans la partie principale de l'écran est aligné à droite et se lit de droite à gauche. Le bouton "Retour" se trouve dans l'angle inférieur droit et pointe vers la droite.
Figure 4. Variantes de gauche à droite et de droite à gauche d'un même écran

Lorsque vous ajoutez la compatibilité avec les langues qui se lisent de droite à gauche dans votre application, il est particulièrement important de garder à l'esprit les points suivants :

  • La mise en miroir du texte lu de droite à gauche n'est possible que dans les applications utilisées sur les appareils équipés d'Android 4.2 (niveau d'API 17) ou version ultérieure. Pour savoir comment accepter la mise en miroir de texte sur des appareils plus anciens, consultez Assurer la compatibilité avec les anciennes applications.
  • Pour déterminer si votre application accepte le texte lu de droite à gauche, testez-la à l'aide des options pour les développeurs et invitez les personnes utilisant ces scripts à exécuter votre application.

Remarque : Pour consulter d'autres consignes de conception liées à la mise en miroir de la mise en page, y compris une liste d'éléments à mettre en miroir ou non, consultez les consignes de Material Design concernant la bidirectionnalité.

Pour mettre en miroir la mise en page de l'interface utilisateur dans votre application afin d'afficher le texte de droite à gauche dans les langues pour lesquelles c'est nécessaire, procédez comme indiqué dans les sections suivantes.

Modifier les fichiers de compilation et les fichiers manifestes

Modifiez le fichier build.gradle de votre module d'application et le fichier manifeste d'application comme suit :

build.gradle (Module: app)

Groovy

android {
    ...
    defaultConfig {
        targetSdkVersion 17 // Or higher
        ...
    }
}

Kotlin

android {
    ...
    defaultConfig {
        targetSdkVersion(17) // Or higher
        ...
    }
}

AndroidManifest.xml

<manifest ... >
    ...
    <application ...
        android:supportsRtl="true">
    </application>
</manifest>

Remarque : Si votre application cible Android 4.1.1 (niveau d'API 16) ou version antérieure, l'attribut android:supportsRtl est ignoré, tout comme les valeurs d'attribut start et end qui apparaissent dans les fichiers de mise en page de votre application. Dans ce cas, la mise en miroir de la mise en page de droite à gauche n'est pas effectuée automatiquement dans votre application.

Mettre à jour les ressources existantes

Convertissez left et right en start et end, respectivement, dans chacun de vos fichiers de ressources de mise en page existants. De cette façon, vous autorisez le framework à aligner les éléments d'interface utilisateur de votre application en fonction des paramètres linguistiques de l'utilisateur.

Remarque : Avant de modifier vos ressources, découvrez comment assurer la prise en charge des anciennes applications ou celles qui ciblent Android 4.1.1 (niveau d'API 16) ou version antérieure.

Pour utiliser les fonctionnalités d'alignement de droite à gauche du framework, modifiez les attributs de vos fichiers de mise en page figurant dans le tableau 1.

Tableau 1. Attributs à utiliser lorsque votre application accepte plusieurs orientations de texte

Attribut acceptant uniquement l'orientation de gauche à droite Attribut acceptant les orientations de gauche à droite et de droite à gauche
android:gravity="left" android:gravity="start"
android:gravity="right" android:gravity="end"
android:layout_gravity="left" android:layout_gravity="start"
android:layout_gravity="right" android:layout_gravity="end"
android:paddingLeft android:paddingStart
android:paddingRight android:paddingEnd
android:drawableLeft android:drawableStart
android:drawableRight android:drawableEnd
android:layout_alignLeft android:layout_alignStart
android:layout_alignRight android:layout_alignEnd
android:layout_marginLeft android:layout_marginStart
android:layout_marginRight android:layout_marginEnd
android:layout_alignParentLeft android:layout_alignParentStart
android:layout_alignParentRight android:layout_alignParentEnd
android:layout_toLeftOf android:layout_toStartOf
android:layout_toRightOf android:layout_toEndOf

Le tableau 2 montre comment le système gère les attributs d'alignement de l'interface utilisateur en fonction de la version du SDK cible, si les attributs left et right sont définis, et si les attributs start et end sont définis.

Tableau 2. Comportement d'alignement des éléments d'interface utilisateur en fonction de la version du SDK cible et des attributs définis

Ciblage d'Android 4.2
(niveau d'API 17) ou version ultérieure ?
Attributs "left" et "right" définis ? Attributs "start" et "end" définis ? Résultat
Oui Oui Oui start et end résolus, et ignorer left et right
Oui Oui Non Seuls left et right sont utilisés
Oui Non Oui Seuls start et end sont utilisés
Non Oui Oui left et right sont utilisés (start et end sont ignorés)
Non Oui Non Seuls left et right sont utilisés
Non Non Oui start et end résolus sur left et right

Ajouter des ressources spécifiques à la langue et à l'orientation

Cette étape consiste à ajouter des versions spécifiques de votre mise en page, de vos drawables et de vos fichiers de ressources contenant des valeurs personnalisées pour différentes langues et orientations de texte.

Dans Android 4.2 (niveau d'API 17) ou version ultérieure, vous pouvez utiliser les qualificateurs de ressources -ldrtl (layout-direction-right-to-left) et -ldltr (layout-direction-left-to-right). Pour garantir la rétrocompatibilité avec le chargement des ressources existantes, les anciennes versions d'Android utilisent les qualificatifs de langue d'une ressource pour déduire l'orientation correcte du texte.

Supposons que vous souhaitiez ajouter un fichier de mise en page spécifique pour accepter les langues qui se lisent de droite à gauche, comme l'hébreu, l'arabe et le persan. Pour ce faire, ajoutez un répertoire layout-ldrtl/ sous res/, comme dans l'exemple suivant :

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.

Si vous souhaitez ajouter une version spécifique de la mise en page conçue uniquement pour le texte en arabe, votre structure de répertoire se présente comme suit :

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.

Remarque : Les ressources spécifiques à une langue sont prioritaires sur les ressources spécifiques à l'orientation du texte qui, à leur tour, prévalent sur les ressources par défaut.

Utiliser des widgets compatibles

À partir d'Android 4.2 (niveau d'API 17), la plupart des éléments d'interface utilisateur du framework sont automatiquement compatibles avec le texte de droite à gauche. Plusieurs éléments du framework, comme ViewPager, ne le sont toutefois pas.

Les widgets d'écran d'accueil acceptent le texte de droite à gauche, à condition que les fichiers manifestes correspondants incluent l'affectation d'attribut android:supportsRtl="true".

Assurer la prise en charge des anciennes applications

Si votre application cible Android 4.1.1 (niveau d'API 16) ou version antérieure, incluez également les attributs left et right, en plus de start et end.

Pour vérifier si votre mise en page doit utiliser l'orientation de droite à gauche, utilisez la logique suivante :

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;
    }
}

Remarque : Pour éviter les problèmes de compatibilité, utilisez la version 23.0.1 ou ultérieure du SDK Android Build Tools.

Utiliser les options pour les développeurs pour effectuer des tests

Sur les appareils équipés d'Android 4.4 (niveau d'API 19) ou version ultérieure, vous pouvez activer l'option Forcer écriture droite à gauche dans les options pour les développeurs sur l'appareil. Ce paramètre vous permet d'afficher du texte utilisant des scripts de gauche à droite, comme du texte en anglais, dans le mode d'affichage de droite à gauche.

Mettre à jour la logique d'application

Cette section décrit les éléments de la logique de votre application que vous devez mettre à jour lorsque vous l'adaptez en vue de gérer plusieurs orientations de texte.

Modifications des propriétés

Pour gérer un changement dans une propriété associée à une langue qui se lit de droite à gauche, comme l'orientation de la mise en page, les paramètres de mise en page, la marge intérieure, l'orientation du texte, l'alignement du texte ou le positionnement des drawables, vous pouvez utiliser le rappel onRtlPropertiesChanged(). Ce rappel vous permet d'obtenir l'orientation actuelle de la mise en page et de mettre à jour les objets View d'une activité en conséquence.

Vues

Si vous créez un widget d'interface utilisateur qui ne fait pas directement partie de la hiérarchie des vues d'une activité, comme une boîte de dialogue ou un élément d'interface semblable à un toast, définissez l'orientation de mise en page appropriée en fonction du contexte. L'extrait de code suivant vous montre comment effectuer cette opération :

Kotlin

val config: Configuration = context.resources.configuration
view.layoutDirection = config.layoutDirection

Java

final Configuration config =
    getContext().getResources().getConfiguration();
view.setLayoutDirection(config.getLayoutDirection());

Plusieurs méthodes de la classe View exigent une attention particulière :

onMeasure()
Les mesures de vue peuvent varier en fonction de l'orientation du texte.
onLayout()
Si vous créez votre propre implémentation de mise en page, vous devez appeler super() dans votre version de onLayout() et adapter votre logique personnalisée pour qu'elle accepte les scripts de droite à gauche.
onDraw()
Si vous implémentez une vue personnalisée ou ajoutez des fonctionnalités avancées à un dessin, vous devez mettre à jour votre code pour qu'il accepte les scripts de droite à gauche. Utilisez le code suivant pour déterminer si votre widget est en mode d'affichage de droite à gauche :

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);
}

Drawables

Si vous devez mettre en miroir un drawable pour une mise en page de droite à gauche, effectuez l'une des opérations suivantes en fonction de la version d'Android exécutée sur l'appareil :

  • Sur les appareils équipés d'Android 4.3 (niveau d'API 18) ou version antérieure, vous devez ajouter et définir les fichiers de ressources -ldrtl.
  • Sur Android 4.4 (niveau d'API 19) ou version ultérieure, vous pouvez utiliser android:autoMirrored="true" lors de la définition de votre drawable, ce qui permet au système de gérer automatiquement la mise en miroir de la mise en page de droite à gauche.

    Remarque : L'attribut android:autoMirrored ne fonctionne que pour les drawables simples dont la mise en miroir bidirectionnelle est simplement une mise en miroir graphique de l'intégralité du drawable. Si votre drawable contient plusieurs éléments ou si sa réflexion en modifie l'interprétation, vous devez effectuer la mise en miroir vous-même. Dans la mesure du possible, demandez à un expert en bidirectionnalité de déterminer si vos drawables en miroir ont du sens pour les utilisateurs.

Gravity

Si le code de votre application utilise Gravity.LEFT ou Gravity.RIGHT, vous devez remplacer ces valeurs par Gravity.START et Gravity.END, respectivement.

Par exemple, si vous utilisez le code suivant :

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;
}

vous devez le remplacer par le code suivant :

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;
}

Cela signifie que vous pouvez conserver votre code existant qui gère les valeurs alignées à gauche et à droite, même si vous utilisez start et end comme valeurs Gravity.

Remarque : Lorsque vous appliquez vos paramètres Gravity, utilisez une version surchargée de Gravity.apply() qui inclut un argument layoutDirection.

Marge et marge intérieure

Pour que votre application accepte les scripts de droite à gauche, suivez les bonnes pratiques ci-dessous concernant les valeurs de marge et de marge intérieure :

  • Utilisez getMarginStart() et getMarginEnd() au lieu des équivalents d'attribut spécifiques à l'orientation, leftMargin et rightMargin.
  • Lorsque vous utilisez setMargins(), permutez les valeurs des arguments left et right si votre application détecte des scripts de droite à gauche.
  • Si votre application inclut une logique de marge intérieure personnalisée, ignorez setPadding() et setPaddingRelative().

Prendre en charge les préférences linguistiques par appli

Dans bien des cas, les utilisateurs multilingues choisissent une langue (telle que l'anglais) pour leur système, mais veulent être en mesure d'en sélectionner d'autres (telles que le néerlandais, le chinois ou encore l'hindi) pour des applications spécifiques. Afin d'améliorer l'expérience de ces utilisateurs, Android 13 propose maintenant les fonctionnalités suivantes pour les applications acceptant plusieurs langues :

  • Paramètres système : emplacement centralisé où les utilisateurs peuvent sélectionner une langue préférée pour chaque application.

    L'attribut android:localeConfig doit être déclaré dans le fichier manifeste de votre application pour indiquer au système qu'elle accepte plusieurs langues. Pour en savoir plus, consultez les instructions pour créer un fichier de ressources et le déclarer dans le fichier manifeste de votre application.

  • API supplémentaires : ces API publiques telles que les méthodes setApplicationLocales() et getApplicationLocales() dans LocaleManager permettent aux utilisateurs d'une application de définir une langue différente de celle du système au moment de l'exécution.

    Les applications qui utilisent un outil de sélection de langue personnalisé et intégré doivent utiliser ces API pour garantir une expérience cohérente aux utilisateurs, quel que soit l'endroit où ils sélectionnent leurs préférences linguistiques. Les API publiques vous aident également à réduire la quantité de code récurrent, sont compatibles avec les APK divisés et acceptent la sauvegarde automatique des applications pour stocker les paramètres linguistiques de l'utilisateur au niveau de l'application.

    Pour assurer la rétrocompatibilité avec les versions précédentes d'Android, des API équivalentes sont également disponibles dans AndroidX. Nous vous recommandons d'utiliser Appcompat 1.6.0-beta01 ou version ultérieure.

    Pour en savoir plus, consultez les instructions d'implémentation des nouvelles API.

Voir aussi

Ressources supplémentaires

Pour en savoir plus sur la compatibilité avec les anciens appareils, consultez les ressources suivantes :

Articles de blog