App lokalisieren

Android wird auf vielen Geräten in vielen Regionen ausgeführt. Damit du möglichst viele Nutzer erreichst, solltest du darauf achten, dass deine App Text, Audiodateien, Zahlen, Währungen und Grafiken so verarbeitet, dass sie für die Regionen, in denen deine App verwendet wird, geeignet sind.

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

Sie sollten über gute Kenntnisse in Kotlin verfügen und mit dem Laden von Android-Ressourcen, Entwicklungsaspekten wie dem Aktivitätslebenszyklus und 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.

  • Lege die meisten oder alle Inhalte der Benutzeroberfläche deiner App in Ressourcendateien ab, wie auf dieser Seite und in der Übersicht über App-Ressourcen beschrieben.
  • Das Verhalten der Benutzeroberfläche wird dagegen durch Ihren Kotlin-basierten Code gesteuert. Wenn Nutzer beispielsweise Daten eingeben, die je nach Sprache unterschiedlich formatiert oder sortiert werden müssen, können Sie die Daten mit Kotlin programmatisch verarbeiten. Auf dieser Seite wird nicht beschrieben, wie Sie Ihren Kotlin-basierten Code lokalisieren.

In diesem Leitfaden wird das zentrale Android-Lokalisierungssystem beschrieben, das in allen Android-Apps verwendet wird. Informationen zum Laden dieser lokalisierten Ressourcen in Ihre 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, Töne, 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 Touchscreentyp, finden Sie unter Alternative Ressourcen bereitstellen.

Wenn Sie Ihre App schreiben, erstellen Sie Standard- und alternative Ressourcen, die Ihre App verwenden kann. Wenn Nutzer deine App ausführen, wählt das Android-System anhand des Gebietsschemas des Geräts aus, welche Ressourcen geladen werden sollen. Wenn Sie Ressourcen erstellen möchten, legen Sie Dateien in speziell benannten Unterverzeichnissen des Verzeichnisses res/ des Projekts ab.

Warum Standardressourcen wichtig sind

Wenn die App in einer Sprache ausgeführt wird, für die du keinen sprachspezifischen Text angegeben hast, lädt Android die Standardstrings aus res/values/strings.xml. Wenn diese Standarddatei fehlt oder ein String fehlt, den Ihre App benötigt, wird die App 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-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) mit einer Definition für text_a, aber nicht für text_b.

  • Wenn diese App auf einem Gerät gestartet wird, auf dem die Sprache auf Englisch eingestellt ist, wird sie möglicherweise ohne Probleme ausgeführt, 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, sieht 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 Arten von Ressourcen, nicht nur für Strings: Du musst einen Satz von Standardressourcendateien erstellen, die alle Ressourcen enthalten, die deine App aufruft, z. B. Drawables, Schriftarten oder Farben. Informationen zum Testen finden Sie im Abschnitt Test für Standardressourcen.

Ressourcen für die Lokalisierung verwenden

In diesem Abschnitt wird erläutert, wie Sie Standardressourcen und alternative Ressourcen erstellen. Außerdem wird erläutert, wie Ressourcen priorisiert werden 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. Verwende für diese Strings die Standardsprache, also die Sprache, die die meisten Nutzer deiner App voraussichtlich sprechen.

Der Standardressourcensatz enthält auch alle Standard-Drawables und kann andere Ressourcentypen wie Symbole oder Strings enthalten. Diese Ressourcen werden in den folgenden Verzeichnissen abgelegt:

  • res/drawable/: Erforderliches Verzeichnis mit mindestens einer Grafikdatei für das App-Symbol bei Google Play.
  • res/xml/: erforderlich, wenn Sie res/xml-<qualifiers>-Ordner haben
  • res/raw/: erforderlich, wenn Sie res/raw-<qualifiers>-Ordner haben

Alternative Ressourcen erstellen

Ein großer Teil der Lokalisierung einer App besteht darin, alternativen Text für verschiedene Sprachen bereitzustellen. In einigen Fällen stellen Sie auch alternative Grafiken, Sounds und andere länderspezifische 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 Qualifizierer, der eine Sprache oder eine Kombination aus Sprache und Region angibt. Der Name eines Ressourcenverzeichnisses muss dem unter 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 außer dem Titel der App ins Japanische lokalisieren. In diesem Fall erstellen Sie drei strings.xml-Dateien, die jeweils in einem länderspezifischen Ressourcenverzeichnis gespeichert werden:

  1. res/values/strings.xml
    Enthält englischen Text für alle Strings, die die App verwendet, 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
    Alle Strings müssen japanischen Text enthalten, außer title.

Wenn Ihr Kotlin-basierter Code auf R.string.title verweist, geschieht 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 diese Datei jedoch keinen solchen String enthält, greift Android auf die Standardeinstellung zurück und lädt den title auf Englisch 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 Ressource-Verzeichnisnamen angegeben werden können, hat die Sprache 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äteeinrichtung 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 von einem 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 Eingaben von einem Eingabestift erwartet und einen QVGA-Bildschirm mit niedriger Pixeldichte im Querformat hat.

Ausnahme: Die einzigen Qualifizierer, die im Auswahlprozess Vorrang vor der Sprache haben, sind der Mobile Country Code (MCC) und der Mobile Network Code (MNC).

Beispiel:

Angenommen, Sie haben die folgende Situation:

  • Der App-Code fordert R.string.text_a an.
  • 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, einschließlich text_a auf Hindi.
  • 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) festgelegt.

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 MCC-Übereinstimmung einer Sprachübereinstimmung vorzieht.

Der Auswahlprozess ist nicht immer so einfach, wie diese Beispiele vermuten lassen. Eine detailliertere Beschreibung des Prozesses finden Sie unter How Android finds the best-matching resource. Alle Qualifikatoren 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

Verwenden Sie beim Erstellen Ihrer Apps keine hartcodierten Strings. Deklarieren Sie stattdessen alle Strings als Ressourcen in einer Standard-strings.xml-Datei. So lassen sie sich leicht aktualisieren und lokalisieren. Strings in der Datei strings.xml können einfach extrahiert, übersetzt und mit entsprechenden Qualifizierern wieder in die App eingebunden werden, 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, 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

Achte beim Entwerfen und Entwickeln deiner Benutzeroberflächen genau darauf, wie du mit deinen Nutzern kommunizierst. Verwenden Sie im Allgemeinen einen prägnanten, freundlichen, aber kurzen Stil und einen einheitlichen Stil für alle Benutzeroberflächen.

Lesen und befolgen Sie die Material Design-Empfehlungen für Schreibstil und Wortwahl. Dadurch wirken deine Apps auf Nutzer professioneller und sie können deine Benutzeroberfläche schneller verstehen.

Verwende außerdem nach Möglichkeit immer die Android-Standardterminologie, z. B. für UI-Elemente wie die App-Leiste, das Optionsmenü, die Systemleiste und Benachrichtigungen. Wenn Android-Begriffe korrekt und einheitlich verwendet werden, ist die Übersetzung einfacher und das Endprodukt für Nutzer besser.

Ausreichend Kontext für deklarierte Strings bereitstellen

Wenn Sie Strings in der Datei strings.xml deklarieren, sollten Sie den Kontext beschreiben, in dem der String verwendet wird. Diese Informationen sind für die Ü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 gedacht? Wann und wo wird es dem Nutzer präsentiert?
  • Wo finde ich das in der Benutzeroberfläche? Beispielsweise sind Übersetzungen in Schaltflächen 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. Gängige Beispiele sind ein Code-Snippet, ein Platzhalter für einen Wert, ein Sonderzeichen oder ein Name. Wenn Sie Ihre Strings für die Übersetzung vorbereiten, suchen und markieren Sie Text, der unverändert bleiben muss, 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" bei der Übersetzung nicht geändert werden soll, damit die Nachricht nicht 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 erklärt, wofür der Platzhalter gedacht ist. Wenn der Platzhalterwert später in Ihrer App ersetzt wird, 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 Bereitstellung einer Android-App finden Sie unter App übersetzen und lokalisieren.

Tipps zur Lokalisierung

Beachten Sie die folgenden Tipps, wenn Sie Ihre App lokalisieren.

App für alle Sprachen und Regionen entwickeln

Gehe nicht davon aus, dass du das Gerät kennst, auf dem ein Nutzer deine App ausführt. Das Gerät verfügt möglicherweise über Hardware, die du nicht erwartet hast, oder es ist auf eine Sprache eingestellt, die du nicht eingeplant hast oder die du nicht testen kannst. Entwickeln Sie Ihre App so, dass sie auf jedem Gerät normal funktioniert oder ordnungsgemäß fehlschlägt.

Wichtig:Achte darauf, dass deine App einen vollständigen Satz von Standardressourcen enthält: Füge die Ordner res/drawable/ und res/values/ ohne zusätzliche Modifikatoren in den Ordnernamen hinzu, die alle Bilder und Texte enthalten, die deine App benötigt.

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

Weitere Informationen finden Sie im Abschnitt Auf Standardressourcen testen.

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

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

Außerdem müssen Sie möglicherweise nicht für jeden String einen Alternativtext erstellen. Angenommen, Sie haben Folgendes:

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

Erstelle 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 greift die App auf die Standardwerte zurück und verwendet die in res/values/strings.xml definierten Strings.

LocalConfiguration für die manuelle Suche nach Sprache verwenden

Sie können die Sprache mit dem 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 integriert. Sie können ein sofortiges Angebot erhalten und eine Bestellung bei einem Übersetzungsunternehmen aufgeben. Sie können Übersetzungen in eine oder mehrere Sprachen für UI-Strings der App, Texte für den Google Play Store-Eintrag, Namen von In-App-Produkten und Texte 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

Denke daran, dass sich das Gerät, auf dem du testest, erheblich von den Geräten unterscheiden kann, die Nutzern an anderen Orten zur Verfügung stehen. Die auf deinem Gerät verfügbaren Sprachen können sich von denen auf anderen Geräten unterscheiden. Außerdem können sich die Auflösung und die Pixeldichte des Gerätebildschirms unterscheiden, was sich auf die Darstellung von Strings und Drawables in der Benutzeroberfläche auswirken kann.

Wenn du die Sprache oder Region auf einem Gerät ändern möchtest, verwende die Einstellungen.

Mit composable Vorschauen testen

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

In einem Emulator testen

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

Benutzerdefinierte Sprache erstellen und verwenden

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

  • Verwenden Sie die App „Custom Locale“, die Sie über den App-Tab aufrufen können. Nachdem Sie eine benutzerdefinierte Sprache erstellt haben, können Sie zu ihr wechseln, indem Sie den Namen der Sprache berühren und halten.
  • Ändern Sie die Sprache in der adb-Shell in eine benutzerdefinierte Sprache, wie im folgenden Abschnitt beschrieben.

Wenn Sie den Emulator auf eine Sprache festlegen, die im Android-System-Image nicht verfügbar ist, wird das System selbst in der Standardsprache angezeigt. Ihre App wird jedoch ordnungsgemäß lokalisiert.

Emulator-Sprache über die adb-Shell ändern

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

  1. Wählen Sie die Sprache aus, die Sie testen möchten, und ermitteln Sie das entsprechende BCP-47-Sprach-Tag, z. B. fr-CA für kanadisches Französisch.
  2. Emulator starten
  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 mit der Option -e an, dass Sie den Emulator verwenden möchten:
    adb -e shell
  4. Führen Sie in der adb-Shell-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 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, starten Sie die App neu. Sie wird dann mit dem neuen Gebietsschema gestartet.

Auf Standardressourcen testen

So testen 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 die Sprache des Emulators auf Spanisch fest. Mit der App „Custom Locale“ können Sie den Emulator auf ein nicht unterstütztes Gebietsschema festlegen.
  2. Führen Sie die Anwendung aus.
  3. Wenn die App eine Fehlermeldung und eine Schaltfläche zum Schließen anzeigt, sucht sie möglicherweise nach einem String, der nicht verfügbar ist. Achten Sie darauf, dass die Datei res/values/strings.xml eine Definition für jeden String enthält, der in der App verwendet wird.

Wenn der Test erfolgreich ist, wiederholen Sie ihn für andere Konfigurationstypen. Wenn die App beispielsweise eine Stringdatei mit dem Namen res/values-land/strings.xml, 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