App lokalisieren

Android ist auf vielen Geräten in zahlreichen Regionen installiert. Wenn Sie möglichst viele Nutzer mit Ihrer App erreichen möchten, sollten Sie die darin verwendeten Text‑ und Audiodateien, Zahlen, grafischen Elemente sowie die Währung auf den jeweiligen Zielmarkt abstimmen.

Auf dieser Seite werden Best Practices für die Lokalisierung von Android-Apps beschrieben.

Sie benötigen grundlegende Kenntnisse in Kotlin und sollten mit dem Laden von Android-Ressourcen, Entwicklungsaspekten wie dem Aktivitätslebenszyklus sowie den allgemeinen Grundsätzen der Internationalisierung und Lokalisierung vertraut sein.

Es empfiehlt sich, das Android-Ressourcenframework zu verwenden, um die lokalisierten Aspekte Ihrer App so weit wie möglich von den Kernfunktionen der App zu trennen.

  • Speichern Sie die meisten oder alle Inhalte der Benutzeroberfläche Ihrer App in Ressourcendateien, wie auf dieser Seite und in der Übersicht über App-Ressourcen beschrieben.
  • Das Verhalten der Benutzeroberfläche wird hingegen durch Ihren Kotlin-basierten Code bestimmt. Wenn Nutzer beispielsweise Daten eingeben, die je nach Gebietsschema unterschiedlich formatiert oder sortiert werden müssen, verwenden Sie Kotlin, um die Daten programmatisch zu verarbeiten. Auf dieser Seite wird nicht beschrieben, wie Sie Ihren Kotlin-basierten Code lokalisieren.

In diesem Leitfaden wird das Android-Lokalisierungssystem beschrieben, das in allen Android-Apps verwendet wird. Informationen zum Laden dieser lokalisierten Ressourcen in Ihrer Jetpack Compose-UI finden Sie unter Ressourcen in Compose.

Eine kurze Anleitung zum Lokalisieren von Strings in Ihrer App finden Sie unter Verschiedene Sprachen und Kulturen unterstützen.

Übersicht: Ressourcenwechsel in Android

Ressourcen sind Textstrings, Sounds, Grafiken und alle anderen statischen Daten, die Ihre Android-App benötigt. Eine App kann mehrere Ressourcensätze enthalten, die jeweils für eine andere Gerätekonfiguration angepasst sind. Wenn ein Nutzer die App ausführt, wählt Android automatisch die Ressourcen aus, die am besten zum Gerät passen, und lädt sie.

Auf dieser Seite geht es um Lokalisierung und Gebietsschema. Eine vollständige Beschreibung des Ressourcenwechsels und aller Konfigurationstypen, die Sie angeben können, z. B. Bildschirmausrichtung oder Touchscreen-Typ, finden Sie unter Alternative Ressourcen bereitstellen.

Beim Schreiben Ihrer App erstellen Sie Standard- und alternative Ressourcen, die von Ihrer App verwendet werden. Wenn Nutzer Ihre App ausführen, wählt das Android-System anhand des Gebietsschemas des Geräts aus, welche Ressourcen geladen werden sollen. Um Ressourcen zu erstellen, platzieren Sie Dateien in Unterverzeichnissen des res/-Verzeichnisses des Projekts, die einen bestimmten Namen haben.

Warum sind Standardressourcen wichtig?

Wenn die App in einem Gebietsschema ausgeführt wird, für das Sie keinen gebietsschemaspezifischen Text angegeben haben, lädt Android die Standardstrings aus res/values/strings.xml. Wenn diese Standarddatei fehlt oder ein String fehlt, den Ihre App benötigt, wird Ihre App nicht ausgeführt und es wird ein Fehler angezeigt. Das folgende Beispiel veranschaulicht, was passieren kann, wenn die Standardtextdatei unvollständig ist.

Beispiel:

Der Kotlin-basierte Code einer App bezieht sich nur auf zwei Strings, text_a und text_b. Die App enthält eine lokalisierte Ressourcendatei (res/values-en/strings.xml), in der text_a und text_b auf Englisch definiert sind. Die App enthält auch eine Standardressourcendatei (res/values/strings.xml), die eine Definition für text_a, aber nicht für text_b enthält.

  • Wenn diese App auf einem Gerät mit der auf Englisch eingestellten Sprache gestartet wird, funktioniert sie möglicherweise problemlos, da res/values-en/strings.xml beide erforderlichen Textstrings enthält.
  • Wenn diese App jedoch auf einem Gerät gestartet wird, das auf eine andere Sprache als Englisch eingestellt ist, wird dem Nutzer eine Fehlermeldung und die Schaltfläche „Schließen erzwingen“ angezeigt. Die App wird nicht geladen.

Um dies zu vermeiden, muss eine res/values/strings.xml-Datei vorhanden sein, in der alle erforderlichen Strings definiert sind. Das gilt für alle Arten von Ressourcen, nicht nur für Strings. Sie müssen eine Reihe von Standardressourcendateien erstellen, die alle Ressourcen enthalten, auf die Ihre App zugreift, z. B. Drawables, Schriftarten oder Farben. Informationen zum Testen finden Sie im Abschnitt Standardressourcen testen.

Ressourcen für die Lokalisierung verwenden

In diesem Abschnitt wird beschrieben, wie Sie Standardressourcen und alternative Ressourcen erstellen. Außerdem wird erläutert, wie Ressourcen Priorität zugewiesen wird und wie Sie in Ihrem Code auf Ihre Ressourcen verweisen.

Standardressourcen erstellen

Fügen Sie den Standardtext der App in res/values/strings.xml ein. Verwenden Sie für diese Strings die Standardsprache, also die Sprache, die die meisten Nutzer Ihrer App sprechen.

Der Standardressourcensatz enthält auch alle Standard-Drawables und kann andere Ressourcentypen wie Symbole oder Strings enthalten. Diese Ressourcen gehören in die folgenden Verzeichnisse:

  • res/drawable/: Das erforderliche Verzeichnis, das mindestens eine Grafikdatei für das App-Symbol bei Google Play enthält.
  • res/xml/: erforderlich, wenn Sie res/xml-<qualifiers>-Ordner haben
  • res/raw/: erforderlich, wenn Sie res/raw-<qualifiers>-Ordner haben

Alternative Ressourcen erstellen

Ein wichtiger Teil der Lokalisierung einer App ist die Bereitstellung von alternativem Text für verschiedene Sprachen. In einigen Fällen stellen Sie auch alternative Grafiken, Sounds und andere sprachspezifische Ressourcen bereit.

Eine App kann viele res/<qualifiers>/-Verzeichnisse mit jeweils unterschiedlichen Qualifizierern angeben. Wenn Sie eine alternative Ressource für ein anderes Gebietsschema erstellen möchten, verwenden Sie einen Qualifier, der eine Sprache oder eine Kombination aus Sprache und Region angibt. Der Name eines Verzeichnisses der Ressourcen muss dem in Alternative Ressourcen bereitstellen beschriebenen Benennungsschema entsprechen, da Ihre App sonst nicht kompiliert werden kann.

Beispiel:

Angenommen, die Standardsprache Ihrer App ist Englisch und Sie möchten den gesamten Text in Ihrer App ins Französische und den gesamten Text mit Ausnahme des App-Titels ins Japanische übersetzen. In diesem Fall erstellen Sie drei strings.xml-Dateien, die jeweils in einem gebietsschemaspezifischen Ressourcenverzeichnis gespeichert werden:

  1. res/values/strings.xml
    Enthält englischen Text für alle Strings, die von der App verwendet werden, einschließlich Text für einen String mit dem Namen title.
  2. res/values-fr/strings.xml
    Alle Strings, einschließlich title, müssen französischen Text enthalten.
  3. res/values-ja/strings.xml
    Enthält japanischen Text für alle Strings außer title.

Wenn sich Ihr Kotlin-basierter Code auf R.string.title bezieht, passiert Folgendes zur Laufzeit:

  • Wenn auf dem Gerät eine andere Sprache als Französisch eingestellt ist, lädt Android title aus der Datei res/values/strings.xml.
  • Wenn das Gerät auf Französisch eingestellt ist, lädt Android title aus der Datei res/values-fr/strings.xml.

Wenn das Gerät auf Japanisch eingestellt ist, sucht Android in der Datei res/values-ja/strings.xml nach title. Da in dieser Datei jedoch kein solcher String enthalten ist, greift Android auf die Standardeinstellung zurück und lädt title in englischer Sprache aus der Datei res/values/strings.xml.

Welche Ressourcen haben Vorrang?

Wenn mehrere Ressourcendateien mit der Konfiguration eines Geräts übereinstimmen, folgt Android einer Reihe von Regeln, um zu entscheiden, welche Datei verwendet werden soll. Unter den Qualifizierern, die in einem Verzeichnis der Ressourcen angegeben werden können, hat das Gebietsschema fast immer Vorrang.

Beispiel:

Angenommen, eine App enthält einen Standardsatz von Grafiken und zwei weitere Sätze von Grafiken, die jeweils für eine andere Gerätekonfiguration optimiert sind:

  • res/drawable/
    Enthält Standardgrafiken.
  • res/drawable-small-land-stylus/
    Enthält Grafiken, die für die Verwendung mit einem Gerät optimiert sind, das Eingaben über einen Eingabestift erwartet und einen QVGA-Bildschirm mit niedriger Pixeldichte im Querformat hat.
  • res/drawable-ja/
    Enthält Grafiken, die für die Verwendung mit Japanisch optimiert sind.

Wenn die App auf einem Gerät ausgeführt wird, das für die Verwendung von Japanisch konfiguriert ist, lädt Android Grafiken aus res/drawable-ja/, auch wenn das Gerät für die Eingabe über einen Eingabestift vorgesehen ist und einen QVGA-Bildschirm mit niedriger Pixeldichte im Querformat hat.

Ausnahme:Die einzigen Qualifizierer, die bei der Auswahl Vorrang vor dem Gebietsschema haben, sind der Mobile Country Code (MCC) und der Mobile Network Code (MNC).

Beispiel:

Angenommen, Sie haben die folgende Situation:

  • Der App-Code ruft R.string.text_a auf.
  • Es gibt zwei relevante Ressourcendateien:
    • res/values-mcc404/strings.xml, einschließlich text_a in der Standardsprache der App, in diesem Fall Englisch.
    • res/values-hi/strings.xml, das text_a auf Hindi enthält.
  • Die App wird auf einem Gerät mit der folgenden Konfiguration ausgeführt:
    • Die SIM-Karte ist mit einem Mobilfunknetz in Indien (MCC 404) verbunden.
    • Die Sprache ist auf Hindi (hi) eingestellt.

Unter Android wird text_a aus res/values-mcc404/strings.xml (auf Englisch) geladen, auch wenn das Gerät für Hindi konfiguriert ist. Das liegt daran, dass Android bei der Ressourcenauswahl einen MCC-Abgleich einem Sprachabgleich vorzieht.

Die Auswahl ist nicht immer so einfach, wie diese Beispiele vermuten lassen. Eine detailliertere Beschreibung des Prozesses finden Sie unter So findet Android die am besten passende Ressource. Alle Qualifizierer werden in der Übersicht über App-Ressourcen beschrieben und in der Reihenfolge ihrer Priorität aufgeführt.

Auf Ressourcen im Code verweisen

Im Kotlin-basierten Code Ihrer App verweisen Sie mit der Syntax R.resource_type.resource_name oder android.R.resource_type.resource_name auf Ressourcen. Weitere Informationen finden Sie unter Auf App-Ressourcen zugreifen.

Strings für die Lokalisierung verwalten

In diesem Abschnitt werden Best Practices für die Verwaltung von Strings im Zusammenhang mit der Lokalisierung beschrieben.

Alle Strings in „strings.xml“ verschieben

Beim Erstellen von Apps sollten Sie keine Strings fest codieren. Deklarieren Sie stattdessen alle Ihre Strings als Ressourcen in einer Standarddatei strings.xml. So lassen sie sich ganz einfach aktualisieren und lokalisieren. Strings in der Datei strings.xml lassen sich einfach extrahieren, übersetzen und mit den entsprechenden Qualifizierern wieder in Ihre App einfügen, ohne dass Änderungen am kompilierten Code erforderlich sind.

Mit Compose können Sie beispielsweise einen String so laden:

// In the res/values/strings.xml file
// <string name="compose">Jetpack Compose</string>

// In your Compose code
Text(
    text = stringResource(R.string.compose)
)

Wenn Sie Bilder mit Text generieren, setzen Sie diese Strings ebenfalls in strings.xml und generieren Sie die Bilder nach der Übersetzung neu.

Android-Richtlinien für UI-Strings beachten

Achten Sie beim Entwerfen und Entwickeln Ihrer Benutzeroberflächen genau darauf, wie Sie mit dem Nutzer kommunizieren. Verwenden Sie generell einen prägnanten Stil, der freundlich, aber kurz ist, und achten Sie auf einen einheitlichen Stil in allen Benutzeroberflächen.

Achten Sie darauf, dass Sie die Material Design-Empfehlungen für Stil und Wortwahl lesen und befolgen. So wirken Ihre Apps für Nutzer professioneller und sie können die Benutzeroberfläche schneller verstehen.

Verwenden Sie außerdem nach Möglichkeit immer die Standardterminologie von Android, z. B. für UI-Elemente wie die App-Leiste, das Optionsmenü, die Systemleiste und Benachrichtigungen. Wenn Sie Android-Begriffe richtig und einheitlich verwenden, wird die Übersetzung einfacher und das Endprodukt ist für Nutzer besser.

Ausreichend Kontext für deklarierte Strings angeben

Wenn Sie Strings in Ihrer strings.xml-Datei deklarieren, sollten Sie den Kontext beschreiben, in dem der String verwendet wird. Diese Informationen sind für den Übersetzer von unschätzbarem Wert und führen zu einer besseren Übersetzungsqualität. Außerdem können Sie Ihre Strings so effektiver verwalten.

Hier ein Beispiel:

<!-- The action for submitting a form. This text is on a button that can fit 30 chars -->
<string name="login_submit_button">Sign in</string>

Sie können Kontextinformationen wie die folgenden angeben:

  • Wofür ist dieser String? Wann und wo wird sie dem Nutzer präsentiert?
  • Wo finde ich das in der Benutzeroberfläche? Übersetzungen in Schaltflächen sind beispielsweise weniger flexibel als in Textfeldern.

Nachrichtenteile markieren, die nicht übersetzt werden sollen

Häufig enthalten Strings Text, der nicht in andere Sprachen übersetzt werden soll. Häufige Beispiele sind ein Codeabschnitt, ein Platzhalter für einen Wert, ein Sonderzeichen oder ein Name. Wenn Sie Ihre Strings für die Übersetzung vorbereiten, suchen Sie nach Text, der unverändert bleiben muss, und markieren Sie ihn. So wird verhindert, dass der Übersetzer ihn ändert.

Verwenden Sie das Platzhalter-Tag <xliff:g>, um Text zu kennzeichnen, der nicht übersetzt werden soll. Hier ein Beispiel für ein Tag, das angibt, dass der Text "%1$s" während der Übersetzung nicht geändert werden soll, um die Nachricht nicht zu beschädigen:

<string name="countdown">
  <xliff:g id="time" example="5 days">%1$s</xliff:g> until holiday
</string>

Wenn Sie ein Platzhalter-Tag deklarieren, fügen Sie ein ID-Attribut hinzu, das erklärt, wofür der Platzhalter verwendet wird. Wenn Ihre App den Platzhalterwert später ersetzt, sollten Sie ein Beispielattribut angeben, um die erwartete Verwendung zu verdeutlichen.

Hier sind einige weitere Beispiele für Platzhalter-Tags:

<resources xmlns:xliff="urn:oasis:names:tc:xliff:document:1.2">
<!-- Example placeholder for a special Unicode symbol -->
<string name="star_rating">Check out our 5
    <xliff:g id="star">\u2605</xliff:g>
</string>
<!-- Example placeholder for a URL -->
<string name="app_homeurl">
    Visit us at <xliff:g
    id="application_homepage">http://my/app/home.html</xliff:g>
</string>
<!-- Example placeholder for a name -->
<string name="prod_name">
    Learn more at <xliff:g id="prod_gamegroup">Game Group</xliff:g>
</string>
<!-- Example placeholder for a literal -->
<string name="promo_message">
    Please use the "<xliff:g id="promotion_code">ABCDEFG</xliff:g>" to get a discount.
</string>
...
</resources>

Lokalisierungs-Checkliste

Eine vollständige Übersicht über die Lokalisierung und Verteilung einer Android-App finden Sie unter App übersetzen und lokalisieren.

Lokalisierungstipps

Beachten Sie diese Tipps bei der Lokalisierung Ihrer App.

App für alle Sprachen und Regionen entwickeln

Gehen Sie nicht davon aus, dass Sie wissen, auf welchem Gerät ein Nutzer Ihre App ausführt. Das Gerät hat möglicherweise Hardware, die Sie nicht erwartet haben, oder es ist auf ein Gebietsschema eingestellt, das Sie nicht eingeplant haben oder das Sie nicht testen können. Entwickeln Sie Ihre App so, dass sie unabhängig vom Gerät, auf dem sie ausgeführt wird, normal funktioniert oder mit gradueller Fehlertoleranz reagiert.

Wichtig:Achten Sie darauf, dass Ihre App einen vollständigen Satz von Standardressourcen enthält: res/drawable/- und res/values/-Ordner ohne zusätzliche Modifizierer in den Ordnernamen, die alle Bilder und Texte enthalten, die Ihre App benötigt.

Wenn in einer App auch nur eine Standardressource fehlt, kann sie auf einem Gerät, das auf ein nicht unterstütztes Gebietsschema eingestellt ist, nicht ausgeführt werden. Wenn beispielsweise in der Standarddatei res/values/strings.xml ein String fehlt, den die App benötigt, und die App in einem nicht unterstützten Gebietsschema ausgeführt wird und versucht, res/values/strings.xml zu laden, wird dem Nutzer eine Fehlermeldung und die Schaltfläche „Schließen erzwingen“ angezeigt.

Weitere Informationen finden Sie im Abschnitt Standardressourcen testen.

Vermeiden Sie es, mehr Ressourcendateien und Textstrings zu erstellen als nötig.

Sie müssen wahrscheinlich nicht für jede Ressource in Ihrer App eine gebietsschemaspezifische Alternative erstellen. Ein App-Logo, das im Verzeichnis res/drawable/ definiert ist, kann beispielsweise in jedem Gebietsschema verwendet werden. In diesem Fall müssen Sie keine alternativen Grafikdateien erstellen.

Außerdem müssen Sie möglicherweise nicht für jeden String Alternativtext erstellen. Nehmen wir beispielsweise Folgendes an:

  • Die Standardsprache Ihrer App ist US-amerikanisches Englisch. Jeder String, der von der App verwendet wird, ist in res/values/strings.xml mit amerikanisch-englischer Rechtschreibung definiert.
  • Für einige wichtige Begriffe möchten Sie die britische Schreibweise angeben. Diese alternativen Strings sollen verwendet werden, wenn Ihre App auf einem Gerät im Vereinigten Königreich ausgeführt wird.

Erstellen Sie dazu eine kleine Datei namens res/values-en-rGB/strings.xml, die nur die Strings enthält, die sich unterscheiden, wenn die App im Vereinigten Königreich ausgeführt wird. Für alle anderen Strings greift die App auf die Standardeinstellungen zurück und verwendet die in res/values/strings.xml definierten Werte.

LocalConfiguration für die manuelle Suche nach Gebietsschemas verwenden

Sie können das Gebietsschema mit der von Android bereitgestellten LocalConfiguration nachschlagen, wie im folgenden Beispiel gezeigt:

val locale = LocalConfiguration.current.locales[0]

Nutze den App-Übersetzungsdienst

Der App-Übersetzungsdienst ist in die Play Console eingebunden. Sie können sofort ein Angebot erhalten und eine Bestellung bei einem Übersetzungsunternehmen aufgeben. Sie können Übersetzungen in eine oder mehrere Sprachen für App-UI-Strings, Text für Google Play Store-Einträge, In-App-Käufe und Text für Werbekampagnen bestellen.

App-Strings mit Gemini übersetzen

Sie können Gemini in Android Studio verwenden, um die String-Ressourcen Ihrer App direkt in Ihrem Projekt zu übersetzen. Weitere Informationen finden Sie unter App übersetzen und lokalisieren.

Lokalisierte Apps testen

Testen Sie Ihre lokalisierte App auf einem Gerät oder mit dem Android-Emulator. Testen Sie Ihre App insbesondere, um sicherzustellen, dass alle erforderlichen Standardressourcen enthalten sind.

Auf einem Gerät testen

Das Gerät, auf dem Sie testen, kann sich erheblich von den Geräten unterscheiden, die Verbrauchern an anderen Orten zur Verfügung stehen. Die auf Ihrem Gerät verfügbaren Gebietsschemas können sich von denen auf anderen Geräten unterscheiden. Außerdem können sich die Auflösung und Dichte des Gerätebildschirms unterscheiden, was sich auf die Darstellung von Strings und Drawables in Ihrer Benutzeroberfläche auswirken kann.

Wenn Sie die Region oder Sprache auf einem Gerät ändern möchten, verwenden Sie die Einstellungen.

Mit zusammensetzbaren Vorschauen testen

Bevor Sie auf einem Gerät testen, können Sie Composable-Vorschauen in Android Studio verwenden, um lokalisierte UIs zu testen, ohne sie auf einem Emulator bereitzustellen. Wenn Sie die Benutzeroberfläche in verschiedenen Sprachen in der Vorschau ansehen möchten, verwenden Sie die Annotation @Preview (z. B. @Preview(locale = "fr")). Sie können auch linksläufige (RTL) Layouts testen, indem Sie ein RTL-Gebietsschema wie @Preview(locale = "ar") angeben.

Auf einem Emulator testen

Weitere Informationen zur Verwendung des Emulators finden Sie unter Apps im Android-Emulator ausführen.

Benutzerdefiniertes Gebietsschema erstellen und verwenden

Ein „benutzerdefiniertes“ Gebietsschema ist eine Kombination aus Sprache und Region, die vom Android-Systemimage nicht explizit unterstützt wird. Sie können testen, wie Ihre App in einem benutzerdefinierten Gebietsschema ausgeführt wird, indem Sie ein benutzerdefiniertes Gebietsschema im Emulator erstellen. Dafür gibt es zwei Möglichkeiten:

  • Verwenden Sie die App „Benutzerdefiniertes Gebietsschema“, auf die Sie über den App-Tab zugreifen können. Nachdem Sie ein benutzerdefiniertes Gebietsschema erstellt haben, können Sie es aktivieren, indem Sie den Namen des Gebietsschemas berühren und halten.
  • Wechseln Sie in der adb-Shell zu einem benutzerdefinierten Gebietsschema, wie im folgenden Abschnitt beschrieben.

Wenn Sie den Emulator auf ein Gebietsschema einstellen, das im Android-Systemimage nicht verfügbar ist, wird das System selbst in der Standardsprache angezeigt. Ihre App wird jedoch korrekt lokalisiert.

Emulatorsprache über die ADB-Shell ändern

So ändern Sie das Gebietsschema im Emulator mit der adb-Shell:

  1. Wählen Sie das Gebietsschema aus, das Sie testen möchten, und ermitteln Sie das BCP-47-Sprachtag, z. B. fr-CA für kanadisches Französisch.
  2. Starten Sie einen Emulator.
  3. Führen Sie in einer Befehlszeilenshell auf dem Hostcomputer den folgenden Befehl aus:
    adb shell
    Wenn Sie ein Gerät angeschlossen haben, können Sie den Emulator angeben, indem Sie die Option -e hinzufügen:
    adb -e shell
  4. Führen Sie an der adb-Eingabeaufforderung (#) diesen Befehl aus:
    setprop persist.sys.locale [BCP-47 language tag];stop;sleep 5;start
    Ersetzen Sie die Abschnitte in Klammern durch die entsprechenden Codes aus Schritt 1.

    Beispiel für einen Test auf Französisch (Kanada):
    setprop persist.sys.locale fr-CA;stop;sleep 5;start

Dadurch wird der Emulator neu gestartet. Wenn der Startbildschirm wieder angezeigt wird, starten Sie die App neu. Sie wird dann mit dem neuen Gebietsschema gestartet.

Standardressourcen testen

So prüfen Sie, ob eine App alle erforderlichen String-Ressourcen enthält:

  1. Stellen Sie den Emulator oder das Gerät auf eine Sprache ein, die von Ihrer App nicht unterstützt wird. Wenn die App beispielsweise französische Strings in res/values-fr/, aber keine spanischen Strings in res/values-es/ hat, legen Sie das Gebietsschema des Emulators auf Spanisch fest. Mit der App „Custom Locale“ können Sie den Emulator auf ein nicht unterstütztes Gebietsschema einstellen.
  2. Führen Sie die App aus.
  3. Wenn in der App eine Fehlermeldung und die Schaltfläche „Schließen erzwingen“ angezeigt werden, wird möglicherweise nach einem String gesucht, der nicht verfügbar ist. Achten Sie darauf, dass die Datei res/values/strings.xml eine Definition für jeden String enthält, der von der App verwendet wird.

Wenn der Test erfolgreich ist, wiederholen Sie ihn für andere Konfigurationstypen. Wenn die App beispielsweise eine String-Datei mit dem Namen res/values-land/strings.xml hat, aber keine Datei mit dem Namen res/values-port/strings.xml enthält, stellen Sie den Emulator oder das Gerät auf Hochformat ein und prüfen Sie, ob die App ausgeführt wird.

Zusätzliche Ressourcen

Weitere Informationen zur Lokalisierung finden Sie in den folgenden zusätzlichen Ressourcen:

Dokumentation

Inhalte ansehen

Weiter
Test your app with pseudolocales