Verschiedene Sprachen und Kulturen unterstützen

Apps enthalten Ressourcen, die für eine bestimmte Kultur spezifisch sein können. Beispielsweise kann eine App kulturspezifische Strings enthalten, die in die Sprache der aktuellen Sprache übersetzt werden.

Es empfiehlt sich, kulturspezifische Ressourcen vom Rest Ihrer App getrennt zu halten. Android löst sprach- und kulturspezifische Ressourcen basierend auf der Spracheinstellung des Systems auf. Sie können Unterstützung für verschiedene Sprachen bereitstellen, indem Sie das Ressourcenverzeichnis in Ihrem Android-Projekt verwenden.

Sie können Ressourcen angeben, die auf die Kultur der Nutzer Ihrer App zugeschnitten sind. Dabei können Sie jeden Ressourcentyp angeben, der für die Sprache und Kultur Ihrer Nutzer geeignet ist. Die folgenden Screenshots zeigen beispielsweise eine App, die String- und Drawable-Ressourcen in der Standardsprache en_US des Geräts und der spanischen Spracheinstellung es_ES anzeigt.

Abbildung 1: Die Anwendung verwendet je nach aktueller Sprache unterschiedliche Ressourcen.

Wenn Sie ein Projekt mit den Android SDK-Tools erstellen, generieren die Tools auf der obersten Ebene des Projekts ein res/-Verzeichnis. Das Verzeichnis res/ enthält Unterverzeichnisse für verschiedene Ressourcentypen. Außerdem gibt es einige Standarddateien, z. B. die Datei res/values/strings.xml, die Ihre Stringwerte enthält.

Die Unterstützung verschiedener Sprachen geht über die Verwendung länderspezifischer Ressourcen hinaus. Einige Nutzer wählen für ihre UI-Sprache eine Sprache mit Rechts-nach-links-Skripten wie Arabisch oder Hebräisch aus. Andere Nutzer, die ihre UI-Sprache auf eine Sprache eingestellt haben, in der LTR-Skripte verwendet werden, z. B. Englisch, können Inhalte in einer Sprache mit RTL-Skripten ansehen oder generieren. Damit beide Nutzertypen unterstützt werden, muss Ihre App folgende Voraussetzungen erfüllen:

• Verwenden Sie ein RTL-UI-Layout für RTL-Sprachen.
• Erkennt und deklariert die Richtung von Textdaten, die in formatierten Nachrichten angezeigt werden. Normalerweise können Sie wie in diesem Leitfaden beschrieben eine Methode aufrufen, die die Richtung der Textdaten für Sie bestimmt.

Sprachverzeichnisse und Ressourcendateien erstellen

Erstellen Sie zusätzliche Verzeichnisse innerhalb von res/, um weitere Sprachen zu unterstützen. Alle Verzeichnisnamen müssen dem folgenden Format entsprechen:

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

Beispielsweise enthält values-b+es/ Stringressourcen für Sprachen mit dem Sprachcode es. In ähnlicher Weise enthält mipmap-b+es+ES/ Symbole für Sprachen mit dem Sprachcode es und dem Ländercode ES.

Android lädt zur Laufzeit die entsprechenden Ressourcen entsprechend den Spracheinstellungen des Geräts. Weitere Informationen finden Sie unter Alternative Ressourcen bereitstellen.

Nachdem Sie entschieden haben, welche Sprachen unterstützt werden sollen, erstellen Sie die Ressourcenunterverzeichnisse und -dateien. Beispiele:

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

Befülle die Ressourcendateien mit lokalisierten Ressourcen. Im Folgenden finden Sie Beispiele für lokalisierte String- und Bildressourcendateien:

Englische Strings (Standardsprache) in /values/strings.xml:

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

Spanische Strings (Sprache es) in /values-b+es/strings.xml:

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

Symbol der US-Flagge (Standardsprache) in /mipmap/country_flag.png:

Abbildung 2: Symbol für die Standardsprache (en_US)

Spanische Flagge (es_ES Sprache) in /mipmap-b+es+ES/country_flag.png:

Abbildung 3: Symbol für die Sprache es_ES.

Hinweis: Sie können für jeden Ressourcentyp Konfigurationsqualifizierer wie den Sprachqualifizierer verwenden. Du kannst beispielsweise lokalisierte Versionen deiner Bitmap-Drawables zur Verfügung stellen. Weitere Informationen finden Sie unter App lokalisieren.

Ressourcen in der App verwenden

Verweisen Sie mit dem Attribut name der einzelnen Ressourcen auf die Ressourcen im Quellcode und in anderen XML-Dateien: R.<resource type>.<resource name>. Es gibt eine Vielzahl von Methoden, mit denen eine Ressource auf diese Weise akzeptiert wird, wie in den folgenden Beispielen gezeigt:

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

In XML-Dateien können Sie mit der Syntax @<resource type>/<resource name> immer dann auf eine Ressource verweisen, wenn das XML-Attribut einen kompatiblen Wert akzeptiert, wie im folgenden Beispiel gezeigt:

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

Hinweis: Damit die Spracheinstellungen der Nutzer richtig priorisiert werden, geben Sie die Sprachen an, die Ihre App unterstützt. Verwenden Sie dazu das Attribut resConfigs. Weitere Informationen finden Sie unter Sprachen angeben, die Ihre Anwendung unterstützt.

Text in Nachrichten formatieren

Eine der häufigsten Aufgaben in Anwendungen ist das Formatieren von Text. Lokalisierte Nachrichten werden formatiert, indem Text und numerische Daten an den entsprechenden Positionen eingefügt werden. Wenn es um RTL-UI- oder RTL-Daten geht, kann eine einfache Formatierung leider zu einer falschen oder sogar unlesbaren Textausgabe führen.

Sprachen wie Arabisch, Hebräisch, Persisch und Urdu werden in RTL geschrieben. Einige Elemente, wie z. B. Zahlen und eingebetteter LTR-Text, werden jedoch in LTR-Text in den ansonsten RTL-Text geschrieben. Sprachen mit LTR-Skripten, einschließlich Englisch, sind ebenfalls bidirektional, da sie eingebettete RTL-Skripte enthalten können, die in RTL angezeigt werden müssen.

Apps generieren häufig Instanzen dieser Art eingebetteter Text in entgegengesetzter Richtung, z. B. indem Textdaten einer beliebigen Sprache und einer beliebigen Textrichtung in lokalisierte Nachrichten eingefügt werden. Durch diese Kombination von Richtungen ist oft nicht klar ersichtlich, wo der Text in entgegengesetzter Richtung beginnt und endet. Daher kann von der App generierter Text zu einer schlechten Nutzererfahrung führen.

Obwohl die standardmäßige Verarbeitung von bidirektionalem Text durch das System Text normalerweise wie erwartet gerendert wird, wird Text möglicherweise nicht korrekt gerendert, wenn Ihre App ihn in eine lokalisierte Nachricht einfügt. Im Folgenden finden Sie Beispiele für Situationen, in denen Text wahrscheinlich falsch angezeigt wird:

• Text am Anfang einer Nachricht eingefügt:

  PERSON_NAME ruft dich an

• Text, der mit einer Nummer beginnt, z. B. einer Adresse oder Telefonnummer:

  987 654 3210

• Text, der mit einem Satzzeichen beginnt, z. B. eine Telefonnummer:

  [phone]

• Text, der mit einem Satzzeichen endet:

  Möchten Sie wirklich fortfahren?

• Text, der bereits beide Richtungen enthält:

  Das Wort something /></ heißt Hebräisch für „Banane“.

Beispiel

Angenommen, eine App muss manchmal die Meldung "Meinten Sie %s?" anzeigen, wobei zur Laufzeit eine Adresse anstelle von %s eingefügt wird. Die App unterstützt verschiedene UI-Sprachen, sodass die Nachricht von einer gebietsspezifischen Ressource stammt und die RTL-Richtung verwendet, wenn für das Gerät eine RTL-Sprache eingestellt ist. Für eine hebräische UI wird die Meldung beispielsweise so angezeigt:

니व כテル Handumdrehen mobilen %s?

Die vorgeschlagene Adresse kann jedoch aus einer Datenbank stammen, die keinen Text in der Sprache der Sprache enthält. Gehört die Adresse beispielsweise zu einem Ort in Kalifornien, wird sie in der Datenbank mit englischem Text angezeigt. Wenn Sie die Adresse „15 Bay Street, Laurel, CA“ in die RTL-Nachricht einfügen, ohne Hinweise auf die Textrichtung anzugeben, ist das Ergebnis weder erwartet noch korrekt:

}{/stellst du dir einen Text zur Verfügung. In diesem Fall hast du einen Termin in der Nähe der Straße 15 Bay Street, Laurel, CA, USA.

Die Hausnummer wird rechts neben der Adresse angezeigt, nicht wie beabsichtigt. Dadurch sieht die Hausnummer eher wie eine seltsame Postleitzahl aus. Das gleiche Problem kann auftreten, wenn Sie RTL-Text in eine Nachricht einfügen, die LTR-Textrichtung verwendet.

Erläuterung und Lösung

Das Problem in diesem Beispiel tritt auf, weil der Textformatierer nicht angibt, dass "15" Teil der Adresse ist. Daher kann das System nicht feststellen, ob die "15" Teil des RTL-Textes vor ihr oder dem LTR-Text dahinter ist.

Verwenden Sie zum Lösen dieses Problems die Methode unicodeWrap() aus der Klasse BidiFormatter. Diese Methode erkennt die Richtung eines Strings und bricht ihn in Unicode-Formatierungszeichen ein, die diese Richtung angeben.

Das folgende Code-Snippet zeigt, wie unicodeWrap() verwendet wird:

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

Da die "15" jetzt innerhalb des als LTR deklarierten Textes erscheint, wird sie an der richtigen Position angezeigt:

多

Verwenden Sie die Methode unicodeWrap() für jeden Text, den Sie in eine lokalisierte Nachricht einfügen, es sei denn, eine der folgenden Aussagen trifft zu:

• Der Text wird in einen maschinenlesbaren String eingefügt, z. B. einen URI oder eine SQL-Abfrage.
• Sie wissen, dass der Text bereits richtig umgebrochen ist.

Hinweis : Wenn deine App auf Android 4.3 (API-Level 18) oder höher ausgerichtet ist, verwende die Version von BidiFormatter aus dem Android Framework. Verwenden Sie andernfalls die Version von BidiFormatter aus der Supportbibliothek.

Zahlen formatieren

Verwenden Sie Formatstrings und keine Methodenaufrufe, um Zahlen in der App-Logik in Strings umzuwandeln:

Kotlin

var myIntAsString = "$myInt"

Java

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

Dadurch werden die Zahlen entsprechend Ihrer Sprache formatiert, was auch die Verwendung einer anderen Zifferngruppe beinhalten kann.

Wenn Sie String.format() verwenden, um eine SQL-Abfrage auf einem Gerät zu erstellen, für das eine Sprache mit eigenen Ziffern festgelegt ist (z. B. für Persisch und die meisten arabischen Sprachen), treten Probleme auf, wenn einer der Parameter der Abfrage Zahlen ist. Dies liegt daran, dass die Nummer in den Ziffern der Sprache formatiert ist und diese Ziffern in SQL ungültig sind.

Um Zahlen im ASCII-Format beizubehalten und die SQL-Abfrage gültig zu halten, müssen Sie stattdessen die überlastete Version von String.format() verwenden, die eine Sprache als ersten Parameter enthält. Verwenden Sie das Sprachargument Locale.US.

Layoutspiegelung unterstützen

Nutzer, die RTL-Scripts verwenden, bevorzugen eine RTL-Benutzeroberfläche mit rechtsbündig ausgerichteten Menüs, rechtsbündigem Text und Vorwärtspfeilen, die nach links zeigen.

Abbildung 4 zeigt den Kontrast zwischen der LTR-Version eines Bildschirms in der App „Einstellungen“ und seinem RTL-Gegenstück:

Abbildung 4: LTR- und RTL-Varianten eines Einstellungsbildschirms

Beachten Sie beim Hinzufügen der RTL-Unterstützung zu Ihrer App die folgenden Punkte:

• Die RTL-Textspiegelung wird in Apps nur auf Geräten mit Android 4.2 (API-Level 17) oder höher unterstützt. Informationen zur Unterstützung der Textspiegelung auf älteren Geräten finden Sie unter Unterstützung für Legacy-Apps in diesem Leitfaden.
• Wenn du herausfinden möchtest, ob deine App RTL-Textrichtungen unterstützt, teste mithilfe der Entwickleroptionen, wie in diesem Leitfaden beschrieben, und lade Personen ein, die RTL-Skripte verwenden, um deine App zu verwenden.

Hinweis:Weitere Designrichtlinien in Bezug auf die Layoutspiegelung, einschließlich einer Liste der Elemente, die sich gut spiegeln oder nicht spiegeln, finden Sie in den Designrichtlinien für Bidirektionalität.

Führen Sie die Schritte in den folgenden Abschnitten aus, um das UI-Layout in Ihrer App so zu spiegeln, dass es in einer RTL-Sprache von links nach rechts angezeigt wird.

Build- und Manifestdateien ändern

Ändern Sie die Datei build.gradle und die Manifestdatei Ihres App-Moduls so:

build.gradle (Module: app)

Groovig

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

Kotlin

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

AndroidManifest.xml

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

Hinweis : Wenn deine App auf Android 4.1.1 (API-Level 16) oder niedriger ausgerichtet ist, wird das Attribut android:supportsRtl zusammen mit den Attributwerten start und end ignoriert, die in den Layoutdateien deiner App erscheinen. In diesem Fall erfolgt die RTL-Layoutspiegelung nicht automatisch in Ihrer App.

Vorhandene Ressourcen aktualisieren

Konvertieren Sie in Ihren vorhandenen Layout-Ressourcendateien left und right in start bzw. end. So kann das Framework die UI-Elemente Ihrer App an den Spracheinstellungen des Nutzers ausrichten.

Hinweis : Bevor Sie Ihre Ressourcen aktualisieren, sollten Sie sich damit vertraut machen, wie Sie Unterstützung für Legacy-Apps oder Apps für Android 4.1.1 (API-Level 16) und niedriger bieten.

Wenn Sie die RTL-Ausrichtungsfunktionen des Frameworks verwenden möchten, ändern Sie die Attribute in den Layoutdateien, die in Tabelle 1 angezeigt werden.

Tabelle 1. Attribute, die verwendet werden können, wenn Ihre App mehrere Textrichtungen unterstützt

Attribut, das nur LTR unterstützt	Attribut, das LTR und RTL unterstützt
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

Tabelle 2 zeigt, wie das System UI-Ausrichtungsattribute basierend auf der SDK-Zielversion behandelt, ob die Attribute left und right definiert sind und ob die Attribute start und end definiert sind.

Tabelle 2. Ausrichtungsverhalten der UI-Elemente basierend auf der SDK-Zielversion und den definierten Attributen

Eine Ausrichtung auf Android 4.2 (API-Level 17) oder höher?	Links und rechts definiert?	Start und Ende definiert?	Ergebnis
Ja	Ja	Ja	start und end werden verwendet und überschreiben left und right
Ja	Ja	Nein	left und right werden verwendet
Ja	Nein	Ja	start und end werden verwendet
Nein	Ja	Ja	left und right werden verwendet (start und end werden ignoriert)
Nein	Ja	Nein	left und right werden verwendet
Nein	Nein	Ja	start und end werden in left und right aufgelöst

Richtungs- und sprachspezifische Ressourcen hinzufügen

In diesem Schritt werden bestimmte Versionen der Ressourcendateien für Layout, Drawables und Werte hinzugefügt, die benutzerdefinierte Werte für verschiedene Sprachen und Textrichtungen enthalten.

Ab Android 4.2 (API-Level 17) und höher können Sie die Ressourcenqualifizierer -ldrtl (layout-direction-right-to-left) und -ldltr (layout-direction-left-to-right) verwenden. Um die Abwärtskompatibilität mit vorhandenen Ressourcen aufrechtzuerhalten, verwenden ältere Android-Versionen die Sprachqualifizierer einer Ressource, um die korrekte Textrichtung abzuleiten.

Angenommen, Sie möchten eine bestimmte Layoutdatei zur Unterstützung von RTL-Skripten wie Hebräisch, Arabisch und Persisch hinzufügen. Fügen Sie dazu das Verzeichnis layout-ldrtl/ in das Verzeichnis res/ ein, wie im folgenden Beispiel gezeigt:

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.

Wenn Sie eine bestimmte Version des Layouts hinzufügen möchten, die nur für arabischen Text vorgesehen ist, sieht Ihre Verzeichnisstruktur so aus:

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.

Hinweis : Sprachspezifische Ressourcen haben Vorrang vor layoutrichtungsspezifischen Ressourcen. Diese haben Vorrang vor den Standardressourcen.

Unterstützte Widgets verwenden

Ab Android 4.2 (API-Ebene 17) unterstützen die meisten Framework-UI-Elemente automatisch die RTL-Textrichtung. Einige Framework-Elemente wie ViewPager unterstützen jedoch die RTL-Textrichtung nicht.

Startbildschirm-Widgets unterstützen die RTL-Textrichtung, solange die zugehörigen Manifestdateien die Attributzuweisung android:supportsRtl="true" enthalten.

Unterstützung für ältere Apps bereitstellen

Wenn deine App auf Android 4.1.1 (API-Level 16) oder niedriger ausgerichtet ist, musst du zusätzlich zu start und end die Attribute left und right angeben.

Mit der folgenden Logik können Sie prüfen, ob in Ihrem Layout die RTL-Textrichtung verwendet werden muss:

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

Hinweis : Verwenden Sie mindestens Version 23.0.1 der Android SDK Build Tools, um Kompatibilitätsprobleme zu vermeiden.

Mit Entwickleroptionen testen

Auf Geräten mit Android 4.4 (API-Level 19) oder höher können Sie die Option RTL-Layoutrichtung erzwingen in den Entwickleroptionen auf dem Gerät aktivieren. Mit dieser Einstellung können Sie Text, der LTR-Skripte verwendet, z. B. englischen Text, im RTL-Modus sehen.

Anwendungslogik aktualisieren

In diesem Abschnitt werden bestimmte Aspekte der Anwendungslogik beschrieben, die aktualisiert werden müssen, wenn die Anwendung für die Verarbeitung mehrerer Textanweisungen angepasst wird.

Eigenschaftsänderungen

Verwenden Sie den Callback onRtlPropertiesChanged(), um eine Änderung in Bezug auf RTL-bezogene Eigenschaften wie Layoutrichtung, Layoutparameter, Abstand, Textrichtung, Textausrichtung oder Zeichnungsposition zu verarbeiten. Mit diesem Callback können Sie die aktuelle Layoutrichtung abrufen und die View-Objekte einer Aktivität entsprechend aktualisieren.

Aufrufe

Wenn Sie ein UI-Widget erstellen, das nicht direkt Teil der Ansichtshierarchie einer Aktivität ist, z. B. ein Dialogfeld oder ein toastähnliches UI-Element, legen Sie je nach Kontext die richtige Layoutrichtung fest. Das folgende Code-Snippet zeigt, wie dieser Vorgang durchgeführt wird:

Kotlin

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

Java

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

Mehrere Methoden der View-Klasse erfordern zusätzliche Beachtung:

onMeasure()

Die Ansichtsmaße können je nach Textrichtung variieren.

onLayout()

Wenn Sie eine eigene Layoutimplementierung erstellen, müssen Sie super() in Ihrer Version von onLayout() aufrufen und Ihre benutzerdefinierte Logik so anpassen, dass RTL-Skripts unterstützt werden.

onDraw()

Wenn Sie eine benutzerdefinierte Ansicht implementieren oder einer Zeichnung erweiterte Funktionen hinzufügen, müssen Sie Ihren Code so aktualisieren, dass er RTL-Skripts unterstützt. Mit dem folgenden Code können Sie feststellen, ob sich Ihr Widget im RTL-Modus befindet:

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

Wenn du ein Drawable hast, das für ein RTL-Layout gespiegelt werden muss, führe je nach der auf dem Gerät ausgeführten Android-Version einen der folgenden Schritte aus:

• Füge auf Geräten mit Android 4.3 (API-Level 18) und niedriger die -ldrtl-Ressourcendateien hinzu und definiere sie.

• Unter Android 4.4 (API-Level 19) und höher musst du android:autoMirrored="true" zum Definieren deines Drawables verwenden. So kann das System die RTL-Layoutspiegelung für dich übernehmen.

  Hinweis : Das Attribut android:autoMirrored funktioniert nur für einfache Drawables, deren bidirektionale Spiegelung einfach eine grafische Spiegelung des gesamten Drawables ist. Wenn dein Drawable mehrere Elemente enthält oder wenn sich die Interpretation deines Drawables reflektiert, kannst du die Spiegelung selbst vornehmen. Wende dich nach Möglichkeit immer an einen bidirektionalen Experten, um festzustellen, ob deine gespiegelten Drawables für die Nutzer Sinn ergeben.

Gravity

Wenn im Layoutcode Ihrer App Gravity.LEFT oder Gravity.RIGHT verwendet wird, ändern Sie diese Werte in Gravity.START bzw. Gravity.END.

Wenn du Kotlin- oder Java-Code hast, der von den Attributen Gravity.LEFT oder Gravity.RIGHT abhängt, kannst du ihn an diese Änderung anpassen. Lege dazu absoluteGravity so fest, dass er mit layoutDirection übereinstimmt.

Wenn Sie beispielsweise den folgenden Code verwenden:

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

Ändern Sie es so:

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

Sie können also Ihren vorhandenen Code beibehalten, der links- und rechts ausgerichtete Werte verarbeitet, auch wenn Sie start und end für Ihre Gravitationswerte verwenden.

Hinweis : Verwenden Sie beim Anwenden der Einstellungen für die Gravitation eine überlastete Version von Gravity.apply() mit einem layoutDirection-Argument.

Ränder und Abstände

Damit in Ihrer App RTL-Skripts unterstützt werden, sollten Sie die folgenden Best Practices für Werte für Marge und Abstände befolgen:

• Verwenden Sie getMarginStart() und getMarginEnd() anstelle der richtungsspezifischen Attributäquivalente leftMargin und rightMargin.
• Vertauschen Sie bei Verwendung von setMargins() die Werte der Argumente left und right, wenn Ihre App RTL-Skripts erkennt.
• Wenn Ihre Anwendung eine benutzerdefinierte Logik für das Padding enthält, überschreiben Sie setPadding() und setPaddingRelative().

Spracheinstellungen für einzelne Apps unterstützen

In vielen Fällen legen mehrsprachige Nutzer für ihre Systemsprache eine Sprache fest, z. B. Englisch, möchten aber für bestimmte Apps andere Sprachen auswählen, z. B. Niederländisch, Chinesisch oder Hindi. Damit Apps diesen Nutzern eine bessere Erfahrung bieten können, werden in Android 13 die folgenden Funktionen für Apps eingeführt, die mehrere Sprachen unterstützen:

• Systemeinstellungen: Ein zentraler Ort, an dem Nutzer eine bevorzugte Sprache für jede App auswählen können.

  Deine App muss in ihrem Manifest das Attribut android:localeConfig deklarieren, um dem System mitzuteilen, dass sie mehrere Sprachen unterstützt. Weitere Informationen finden Sie in der Anleitung zum Erstellen einer Ressourcendatei und ihrer Deklaration in der Manifestdatei Ihrer App.

• Zusätzliche APIs: Mit diesen öffentlichen APIs wie den Methoden l10n-placeholder1">setApplicationLocales() und l10n-placeholder2">getApplicationLocales() in LocaleManager können Apps zur Laufzeit eine andere Sprache als die Systemsprache festlegen.

  Anwendungen, die eine benutzerdefinierte In-App-Sprachauswahl verwenden, können diese APIs nutzen, um Nutzern unabhängig von der Auswahl der Spracheinstellungen eine einheitliche Nutzererfahrung zu bieten. Die öffentlichen APIs helfen Ihnen auch, die Menge an Boilerplate-Code zu reduzieren, und sie unterstützen unterteilte APKs. Sie unterstützen auch die automatische Sicherung für Apps, um die Spracheinstellungen der Nutzer auf App-Ebene zu speichern.

  Für die Abwärtskompatibilität mit früheren Android-Versionen sind auch entsprechende APIs in AndroidX verfügbar. Wir empfehlen die Verwendung von Appcompat 1.6.0-beta01 oder höher.

  Weitere Informationen finden Sie in der Anleitung zur Implementierung der neuen APIs.

Siehe auch

• App lokalisieren
• App-Übersetzungsdienst

Weitere Informationen

Weitere Informationen zur Unterstützung älterer Geräte finden Sie in den folgenden Ressourcen:

Blogposts

• Um Apps barrierefrei zu machen und sie mit verschiedenen Geräten kompatibel zu machen
• Schreiben für ein globales Publikum