App lokalisieren

Android läuft auf vielen Geräten in vielen Regionen. Damit Sie möglichst viele Nutzer erreichen, sollten Sie darauf achten, dass Ihre App Text, Audiodateien, Zahlen, Währungen und Grafiken in der Sprache verarbeitet, in der sie verwendet wird.

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

Sie müssen Grundkenntnisse in Kotlin oder der Programmiersprache Java haben und mit dem Laden von Android-Ressourcen, der Erklärung von Benutzeroberflächenelementen in XML, der Entwicklungsaspekte wie dem Aktivitätslebenszyklus und den allgemeinen Prinzipien der Internationalisierung und Lokalisierung vertraut sein.

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

  • Fügen Sie den Großteil oder den gesamten Inhalt der Benutzeroberfläche Ihrer Anwendung in Ressourcendateien ein, wie auf dieser Seite und in der Übersicht über Anwendungsressourcen beschrieben.
  • Das Verhalten der Benutzeroberfläche wird dagegen durch Ihren Kotlin- oder Java-basierten Code gesteuert. Wenn Nutzer beispielsweise Daten eingeben, die je nach Sprache unterschiedlich formatiert oder sortiert werden müssen, verwenden Sie Kotlin oder die Programmiersprache Java, um die Daten programmatisch zu verarbeiten. Auf dieser Seite wird nicht beschrieben, wie Sie Kotlin- oder Java-basierten Code lokalisieren.

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 Textzeichenfolgen, Layouts, Töne, Grafiken und andere statische Daten, die Ihre Android-App benötigt. Eine App kann mehrere Sätze von Ressourcen enthalten, die alle an eine andere Gerätekonfiguration angepasst sind. Wenn ein Nutzer die App ausführt, wählt Android automatisch die für das Gerät am besten geeigneten Ressourcen aus und lädt sie.

Auf dieser Seite geht es vorrangig um Lokalisierung und Sprache. Eine vollständige Beschreibung des Wechsels von Ressourcen und aller möglichen Konfigurationstypen, z. B. Bildschirmausrichtung oder Touchscreen-Typ, finden Sie unter Alternative Ressourcen bereitstellen.

Wenn Sie Ihre Anwendung schreiben, erstellen Sie Standard- und alternative Ressourcen, die die Anwendung verwenden soll. Wenn Nutzer deine App ausführen, wählt das Android-System anhand der Sprache des Geräts aus, welche Ressourcen geladen werden sollen. Zum Erstellen von Ressourcen platzieren Sie Dateien in speziell benannten Unterverzeichnissen des Projektverzeichnisses res/.

Warum Standardressourcen wichtig sind

Wenn die App in einer Sprache ausgeführt wird, für die du keinen länderspezifischen Text angegeben hast, lädt Android die Standardstrings aus res/values/strings.xml. Wenn diese Standarddatei nicht vorhanden ist oder wenn ein von der Anwendung benötigter String fehlt, wird die Anwendung nicht ausgeführt und es wird ein Fehler angezeigt. Das folgende Beispiel zeigt, was passieren kann, wenn die Standardtextdatei unvollständig ist.

Beispiel:

Der Kotlin- oder Java-basierte Code einer App bezieht sich nur auf die beiden 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 Anwendung enthält außerdem eine Standardressourcendatei (res/values/strings.xml), die eine Definition für text_a, jedoch nicht für text_b enthält.

  • Wenn die App auf einem Gerät gestartet wird, bei dem die Sprache auf Englisch eingestellt ist, funktioniert sie möglicherweise ohne Probleme, 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, erhält der Nutzer eine Fehlermeldung und die Schaltfläche „Schließen erzwingen“. Die App wird nicht geladen.

Um dies zu verhindern, muss eine res/values/strings.xml-Datei vorhanden sein, in der alle erforderlichen Strings definiert sind. Dies gilt für alle Ressourcentypen, nicht nur für Strings: Sie müssen eine Reihe von Standardressourcendateien erstellen, die alle Ressourcen enthalten, die von Ihrer App aufgerufen werden, z. B. Layouts, Drawables oder Animationen. Informationen zu Tests finden Sie im Abschnitt Auf Standardressourcen testen.

Ressourcen für die Lokalisierung verwenden

In diesem Abschnitt wird erläutert, wie Sie Standardressourcen sowie alternative Ressourcen erstellen. Außerdem wird erläutert, wie Ressourcen Vorrang erhalten und wie Sie im Code auf Ihre Ressourcen verweisen.

Standardressourcen erstellen

Geben 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 umfasst außerdem alle Standard-Drawables und -Layouts und kann andere Arten von Ressourcen wie Animationen enthalten. Diese Ressourcen werden in die folgenden Verzeichnisse aufgenommen:

  • res/drawable/: erforderliches Verzeichnis mit mindestens einer Grafikdatei für das Symbol der App bei Google Play
  • res/layout/: erforderliches Verzeichnis mit einer XML-Datei, die das Standardlayout definiert
  • res/anim/: erforderlich, wenn Sie res/anim-<qualifiers>-Ordner haben
  • res/xml/: erforderlich, wenn Sie res/xml-<qualifiers>-Ordner haben
  • res/raw/: erforderlich, wenn Sie res/raw-<qualifiers>-Ordner haben

Tipp:Untersuchen Sie in Ihrem Code jeden Verweis auf eine Android-Ressource. Achten Sie darauf, dass für jede Ressource eine Standardressource definiert ist. Achten Sie außerdem darauf, dass die Standardstringdatei vollständig ist. Eine localized-Stringdatei kann nur einen Teil der Strings enthalten, die Standardstringdatei default muss jedoch alle Strings enthalten.

Alternative Ressourcen erstellen

Ein großer Teil der Lokalisierung einer App besteht darin, Alternativtexte für verschiedene Sprachen bereitzustellen. In manchen Fällen stellst du auch alternative Grafiken, Töne, Layouts und andere länderspezifische Ressourcen zur Verfügung.

Für eine Anwendung können mehrere res/<qualifiers>/-Verzeichnisse mit jeweils unterschiedlichen Qualifizierern angegeben werden. Um eine alternative Ressource für eine andere Sprache zu erstellen, verwenden Sie einen Qualifizierer, der eine Sprache oder eine Kombination aus Sprache und Region angibt. Der Name eines Ressourcenverzeichnisses muss dem Benennungsschema entsprechen, das unter Alternative Ressourcen bereitstellen beschrieben ist. Andernfalls kann die Anwendung nicht kompiliert werden.

Beispiel:

Angenommen, die Standardsprache Ihrer App ist Englisch und Sie möchten den gesamten Text in Ihrer App in Französisch und den gesamten Text mit Ausnahme des App-Titels auf Japanisch lokalisieren. In diesem Fall erstellen Sie drei strings.xml-Dateien, die jeweils in einem länderspezifischen Ressourcenverzeichnis gespeichert sind:

  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
    Enthält französischen Text für alle Strings, einschließlich title.
  3. res/values-ja/strings.xml
    Enthält japanischen Text für alle Strings außer title.

Wenn in Ihrem Kotlin- oder Java-basierten Code auf R.string.title verwiesen wird, geschieht bei der Laufzeit Folgendes:

  • Wenn das Gerät auf 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.

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

Welche Ressourcen haben Vorrang?

Wenn mehrere Ressourcendateien der Konfiguration eines Geräts entsprechen, folgt Android einer Reihe von Regeln bei der Entscheidung, welche Datei verwendet wird. Unter den Qualifizierern, die in einem Ressourcenverzeichnisnamen angegeben werden können, hat die Sprache fast immer Vorrang.

Beispiel:

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

  • res/drawable/
    Enthält Standardgrafiken.
  • res/drawable-small-land-stylus/
    Die Grafiken sind für die Verwendung mit einem Gerät optimiert, das Eingabe über einen Eingabestift erwartet, und ein QVGA-Display mit geringer Dichte im Querformat.
  • res/drawable-ja/
    Umfasst 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 wahrscheinlich eine Eingabe von einem Eingabestift erwartet und einen QVGA-Bildschirm mit geringer Dichte im Querformat hat.

Ausnahme:Die einzigen Qualifier, die beim Auswahlverfahren Vorrang vor der Sprache haben, sind Mobile Country Code (MCC) und Mobile Network Code (MNC).

Beispiel:

Nehmen wir an, Sie haben die folgende Situation:

  • Mit dem App-Code wird R.string.text_a aufgerufen
    • .
  • Es sind zwei relevante Ressourcendateien verfügbar:
    • res/values-mcc404/strings.xml, die text_a in der Standardsprache der App enthält, in diesem Fall Englisch.
    • res/values-hi/strings.xml, was text_a auf Hindi umfasst.
  • Die App wird auf einem Gerät mit folgender Konfiguration ausgeführt:
    • Die SIM-Karte ist mit einem Mobilfunknetz in Indien (MCC 404) verbunden.
    • Die Sprache ist auf Hindi (hi) eingestellt.

Android lädt text_a aus res/values-mcc404/strings.xml (auf Englisch), auch wenn das Gerät für Hindi konfiguriert ist. Das liegt daran, dass Android bei der Ressourcenauswahl eine Kundencenter-Übereinstimmung gegenüber einer Sprachübereinstimmung bevorzugt.

Der Auswahlprozess ist nicht immer so einfach, wie diese Beispiele nahelegen. Eine differenziertere Beschreibung des Vorgangs finden Sie unter So findet Android die am besten übereinstimmende Ressource. Alle Qualifizierer werden in der Übersicht über Anwendungsressourcen in der Reihenfolge ihrer Priorität beschrieben und aufgelistet.

Ressourcen im Code konsultieren

Im Kotlin- oder Java-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 Anwendungsressourcen zugreifen.

Strings zur Lokalisierung verwalten

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

Alle Strings in string.xml verschieben

Sie sollten keine Strings hartcodieren, wenn Sie Ihre Apps erstellen. Deklarieren Sie stattdessen alle Strings als Ressourcen in einer strings.xml-Standarddatei, um sie leicht aktualisieren und lokalisieren zu können. Strings in der Datei strings.xml können ohne Änderungen am kompilierten Code einfach extrahiert, übersetzt und mit entsprechenden Qualifizierern wieder in Ihre Anwendung eingebunden werden.

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

Android-Richtlinien für UI-Strings beachten

Achten Sie beim Entwerfen und Entwickeln von UIs genau darauf, wie Sie mit Ihren Nutzern sprechen. Verwenden Sie im Allgemeinen einen prägnanten Stil, der freundlich, aber kurz ist, und verwenden Sie in allen UIs einen einheitlichen Stil.

Lies dir die Material Design-Empfehlungen für den Schreibstil und die Wortwahl durch und befolge sie. Dadurch wirken Ihre Anwendungen für den Nutzer ausgefeilter und die Nutzer können Ihre UI schneller verstehen.

Verwende nach Möglichkeit immer die Android-Standardterminologie, z. B. für UI-Elemente wie die App-Leiste, das Optionsmenü, die Systemleiste und Benachrichtigungen. Die korrekte und einheitliche Verwendung von Android-Begriffen erleichtert die Übersetzung und führt zu einem besseren Endprodukt für die Nutzer.

Ausreichend Kontext für deklarierte Strings bereitstellen

Wenn Sie Strings in der Datei strings.xml deklarieren, müssen 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 qualitativ besseren Übersetzung. Außerdem können Sie damit Ihre Strings 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>

Erwägen Sie, Kontextinformationen wie die folgenden bereitzustellen:

  • Wozu dient dieser String? Wann und wo werden sie den Nutzenden präsentiert?
  • Wo im Layout ist das zu sehen? Übersetzungen sind beispielsweise bei Schaltflächen weniger flexibel als in Textfeldern.

Teile der Nachricht markieren, die nicht übersetzt werden sollen

Zeichenfolgen enthalten häufig Text, der nicht in andere Sprachen übersetzt werden sollte. Gängige Beispiele sind ein Code-Snippet, ein Platzhalter für einen Wert, ein Sondersymbol oder ein Name. Suchen Sie bei der Vorbereitung Ihrer Strings für die Übersetzung nach Text, der unverändert und nicht übersetzt werden muss, und markieren Sie ihn, damit der Übersetzer ihn nicht ändert.

Verwenden Sie ein <xliff:g>-Platzhalter-Tag, um Text zu markieren, der nicht übersetzt werden soll. Hier ist ein Beispiel-Tag, das angibt, dass der Text "%1$s" während der Übersetzung nicht geändert wird, um zu verhindern, dass die Meldung beschädigt wird:

<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 erläutert, wozu der Platzhalter dient. Wenn Ihre Anwendung den Platzhalterwert später ersetzt, geben Sie ein Beispielattribut an, um die erwartete Verwendung zu verdeutlichen.

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>

Lokalisierungscheckliste

Eine vollständige Übersicht über das Lokalisieren und Vertrieb einer Android-App finden Sie unter App übersetzen und lokalisieren.

Lokalisierungstipps

Beachten Sie bei der Lokalisierung Ihrer App die folgenden Tipps.

Entwickeln Sie Ihre App so, dass sie in jeder Sprache funktioniert

Vermuten Sie nichts über das Gerät, auf dem ein Nutzer Ihre Anwendung ausführt. Möglicherweise hat das Gerät Hardware, die Sie nicht erwartet haben, oder es ist auf eine Sprache eingestellt, für die Sie nicht geplant haben oder die Sie nicht testen können. Gestalten Sie Ihre App so, dass sie unabhängig vom Gerät, auf dem sie ausgeführt wird, normal funktioniert oder ordnungsgemäß funktioniert.

Wichtig:Ihre App muss eine vollständige Reihe von Standardressourcen enthalten: Fügen Sie die Ordner res/drawable/ und res/values/ ohne zusätzliche Modifikatoren in den Ordnernamen ein, die alle Bilder und Texte enthalten, die Ihre App benötigt.

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

Weitere Informationen finden Sie im Abschnitt Auf Standardressourcen testen.

Ein flexibles Layout entwerfen

Wenn Sie Ihr Layout für eine bestimmte Sprache neu anordnen müssen, können Sie ein alternatives Layout für diese Sprache erstellen, z. B. res/layout-de/main.xml für ein deutschsprachiges Layout. Dies kann jedoch die Wartung deiner App erschweren. Es ist besser, ein einzelnes Layout zu erstellen, das flexibler ist.

Eine weitere typische Situation ist eine Sprache, die ein anderes Layout erfordert. Angenommen, Sie haben ein Kontaktformular, das zwei Namensfelder enthält, wenn die Anwendung auf Japanisch ausgeführt wird, und drei Namensfelder, wenn die Anwendung in einer anderen Sprache ausgeführt wird. Dafür gibt es zwei Möglichkeiten:

  • Erstellen Sie ein Layout mit einem Feld, das sich je nach Sprache programmatisch aktivieren oder deaktivieren lässt.
  • das Hauptlayout ein weiteres Layout mit dem änderbaren Feld enthalten. Das zweite Layout kann für verschiedene Sprachen unterschiedliche Konfigurationen haben.

Vermeiden Sie es, mehr Ressourcendateien und Textstrings zu erstellen, als Sie benötigen.

Sie müssen wahrscheinlich nicht für jede Ressource in Ihrer Anwendung eine länderspezifische Alternative erstellen. Beispielsweise kann das in der Datei res/layout/main.xml definierte Layout in jeder Sprache funktionieren. In diesem Fall müssen keine alternativen Layoutdateien erstellt werden.

Außerdem müssen Sie möglicherweise nicht für jede Zeichenfolge einen alternativen Text erstellen. Nehmen wir beispielsweise Folgendes an:

  • Die Standardsprache Ihrer App ist amerikanisches Englisch. Jeder String, den die Anwendung verwendet, wird in amerikanischem Englisch in res/values/strings.xml definiert.
  • Für einige wichtige Sätze ist die Rechtschreibung im britischen Englisch erforderlich. Diese alternativen Strings sollen verwendet werden, wenn deine App auf einem Gerät im Vereinigten Königreich ausgeführt wird.

Erstellen Sie dazu eine kleine Datei mit dem Namen 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 verwendet die App die Standardwerte und verwendet die in res/values/strings.xml definierten Strings.

Android-Kontextobjekt für die manuelle Gebietsschemasuche verwenden

Sie können die Sprache mithilfe des Context-Objekts ermitteln, das Android bereitstellt, wie im folgenden Beispiel gezeigt:

Kotlin

val primaryLocale: Locale = context.resources.configuration.locales[0]
val locale: String = primaryLocale.displayName

Java

Locale primaryLocale = context.getResources().getConfiguration().getLocales().get(0);
String locale = primaryLocale.getDisplayName();

Nutze den App-Übersetzungsdienst

Der App-Übersetzungsdienst ist in die Play Console eingebunden. Damit können Sie sofort ein Angebot einholen und bei einem Übersetzungsunternehmen einen Auftrag aufgeben. Sie können Übersetzungen in eine oder mehrere Sprachen für App-UI-Strings, Text von Play Store-Einträgen, Namen von In-App-Käufen und Kampagnentexten in Auftrag geben.

Lokalisierte Apps testen

Teste deine lokalisierte App auf einem Gerät oder mit dem Android-Emulator. Testen Sie insbesondere Ihre Anwendung, 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 für Nutzer an anderen Orten verfügbar sind. Die auf deinem Gerät verfügbaren Sprachen können sich von denen auf anderen Geräten unterscheiden. Außerdem kann die Auflösung und Dichte des Gerätebildschirms abweichen, was sich auf die Anzeige von Strings und Drawables in deiner UI auswirken kann.

Das Gebietsschema oder die Sprache auf einem Gerät kannst du in den Einstellungen ändern.

In einem Emulator testen

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

Benutzerdefinierte Sprache erstellen und verwenden

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

  • Verwenden Sie die Anwendung „Benutzerdefiniertes Gebietsschema“, auf die Sie über den Tab „Anwendung“ zugreifen können. Nachdem Sie eine benutzerdefinierte Sprache erstellt haben, können Sie zu dieser wechseln, indem Sie den Namen der Sprache gedrückt halten.
  • Wechseln Sie von der adb-Shell zu einer benutzerdefinierten Sprache, wie im folgenden Abschnitt beschrieben.

Wenn Sie für den Emulator eine Sprache festlegen, die im Android-System-Image nicht verfügbar ist, wird das System selbst in seiner Standardsprache angezeigt. Ihre App wird jedoch korrekt lokalisiert.

Sprache des Emulators über die ADB-Shell ändern

So ändern Sie die Sprache im Emulator mit der adb-Shell:

  1. Wählen Sie die Sprache aus, die Sie testen möchten, und legen Sie das BCP-47-Sprach-Tag fest, z. B. fr-CA für kanadisches Französisch.
  2. Starten Sie einen Emulator.
  3. Führen Sie in einer Befehlszeilen-Shell auf dem Hostcomputer den folgenden Befehl aus:
    adb shell
    Wenn Sie ein Gerät angeschlossen haben, geben Sie durch Hinzufügen der Option -e an, dass der Emulator verwendet werden soll:
    adb -e shell
  4. Führen Sie in der adb-Shell-Eingabeaufforderung (#) den folgenden Befehl aus:
    setprop persist.sys.locale [BCP-47 language tag];stop;sleep 5;start
    Ersetzen Sie die in Klammern gesetzten Abschnitte durch die entsprechenden Codes aus Schritt 1.

    Zum Beispiel für Tests in kanadischem Französisch:
    setprop persist.sys.locale fr-CA;stop;sleep 5;start

Dadurch wird der Emulator neu gestartet. Sobald der Startbildschirm wieder angezeigt wird, starte die App neu. Die App wird dann mit der neuen Sprache gestartet.

Auf Standardressourcen testen

So testen Sie, ob eine App jede benötigte String-Ressource enthält:

  1. Stellen Sie für den Emulator oder das Gerät eine Sprache ein, die von Ihrer App nicht unterstützt wird. Wenn die App beispielsweise französische Strings in res/values-fr/ hat, aber keine spanischen Strings in res/values-es/, dann setze die Sprache des Emulators auf Spanisch. Sie können die Anwendung für benutzerdefiniertes Gebietsschema verwenden, um für den Emulator eine nicht unterstützte Sprache festzulegen.
  2. Führen Sie die App aus.
  3. Wenn die Anwendung eine Fehlermeldung und die Schaltfläche „Schließen erzwingen“ anzeigt, sucht sie möglicherweise nach einem String, der nicht verfügbar ist. Die Datei res/values/strings.xml muss eine Definition für jeden String enthalten, den die Anwendung verwendet.

Wenn der Test erfolgreich ist, wiederholen Sie ihn für andere Konfigurationsarten. Wenn die App beispielsweise eine Layoutdatei namens res/layout-land/main.xml, aber keine Datei mit dem Namen res/layout-port/main.xml enthält, setze den Emulator oder das Gerät auf das Hochformat und prüfe, ob die App ausgeführt wird.

Weiter
Test your app with pseudolocales