Wspieraj różne języki i kultury

Aplikacje zawierają zasoby, które mogą być charakterystyczne dla danej kultury. Na przykład aplikacja może zawierać ciągi tekstowe dotyczące kultury, które są tłumaczone na język bieżącego języka.

Dobrym pomysłem jest oddzielenie zasobów związanych z kulturą do innych aplikacji. Android rozpozna zasoby charakterystyczne dla danego języka i kultury na podstawie ustawień regionalnych systemu. Możesz zapewnić obsługę różnych języków, korzystając z katalogu zasobów w projekcie Androida.

Możesz określić zasoby dostosowane do kultury osób korzystających z Twojej aplikacji. Możesz udostępnić dowolny typ zasobów odpowiedni do języka i kultury użytkowników. Na przykład na poniższych zrzutach ekranu widać aplikację z ciągami znaków i możliwymi do użycia zasobami, które są wyświetlane w domyślnym języku en_US urządzenia i języku hiszpańskim (es_ES).

Tekst i ikona różnią się w zależności od regionu

Rysunek 1. Aplikacja korzysta z różnych zasobów w zależności od bieżącego języka.

Gdy tworzysz projekt przy użyciu narzędzi Android SDK, narzędzia generują katalog res/ na najwyższym poziomie projektu. W tym katalogu res/ znajdują się podkatalogi różnych typów zasobów. Istnieje też kilka plików domyślnych, np. res/values/strings.xml, który zawiera wartości ciągów znaków.

Obsługa różnych języków wykracza poza zasoby typowe dla danego języka. Niektórzy użytkownicy wybierają w swoim interfejsie język korzystający ze skryptów pisanych od prawej do lewej (takich jak arabski czy hebrajski). Inni użytkownicy, którzy ustawili język interfejsu na język korzystający ze skryptów LTR (np. angielski), mogą wyświetlać lub generować treści w języku wykorzystującym skrypty RTL. Aby można było obsługiwać oba te rodzaje użytkowników, aplikacja musi:

  • Zastosowanie układu interfejsu RTL w językach RTL.
  • Wykrywa i zadeklaruj kierunek danych tekstowych wyświetlanych w sformatowanych wiadomościach. Zwykle możesz wywołać metodę (zgodnie z opisem w tym przewodniku), która określa kierunek danych tekstowych.

Tworzenie katalogów regionalnych i plików zasobów

Aby dodać obsługę większej liczby języków, utwórz dodatkowe katalogi w res/. Nazwa każdego katalogu musi być zgodna z tym formatem:

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

Na przykład values-b+es/ zawiera zasoby w postaci ciągu znaków dla języków z kodem języka es. Podobnie mipmap-b+es+ES/ zawiera ikony języków z kodem języka es i kraju ES.

Android wczytuje odpowiednie zasoby zgodnie z ustawieniami regionalnymi urządzenia w czasie działania. Więcej informacji znajdziesz w artykule Udostępnianie zasobów alternatywnych.

Gdy wybierzesz obsługiwane języki, utwórz podkatalogi i pliki zasobów. Na przykład:

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

Wypełnij pliki zasobów zlokalizowanymi zasobami. Oto przykłady zlokalizowanych plików zasobów graficznych i ciągów tekstowych:

Angielskie ciągi znaków (domyślne ustawienia regionalne) w języku /values/strings.xml:

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

Hiszpańskie ciągi tekstowe (język es) w języku /values-b+es/strings.xml:

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

Ikona flagi USA (ustawienia domyślne) w języku /mipmap/country_flag.png:

Ikona flagi Stanów Zjednoczonych

Rysunek 2. Ikona używana dla języka domyślnego (en_US).

Ikona flagi Hiszpanii (język es_ES) w języku /mipmap-b+es+ES/country_flag.png:

Ikona flagi Hiszpanii

Rysunek 3. Ikona używana dla języka: es_ES.

Uwaga: w przypadku każdego typu zasobu możesz używać kwalifikatorów konfiguracji, takich jak kwalifikator języka. Możesz na przykład udostępnić zlokalizowane wersje elementów rysowalnych map bitowych. Więcej informacji znajdziesz w artykule Lokalizowanie aplikacji.

Wykorzystanie zasobów w aplikacji

Odwołaj się do zasobów w swoim kodzie źródłowym i innych plikach XML, używając atrybutu name każdego zasobu: R.<resource type>.<resource name>. Istnieje wiele metod, które akceptują zasoby w ten sposób, co pokazano w tych przykładach:

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

W plikach XML możesz się odwoływać do zasobu o składni @<resource type>/<resource name>, gdy atrybut XML akceptuje zgodną wartość – jak w tym przykładzie:

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

Uwaga: aby mieć pewność, że ustawienia języka użytkownika mają prawidłowy priorytet, za pomocą właściwości resConfigs określ języki obsługiwane przez Twoją aplikację. Więcej informacji znajdziesz w artykule Określanie, jakie języki obsługuje aplikacja.

Formatowanie tekstu w wiadomościach

Jednym z najczęstszych zadań w aplikacji jest formatowanie tekstu. Zlokalizowane wiadomości są formatowane przez wstawianie danych tekstowych i liczbowych w odpowiednich miejscach. Niestety w przypadku danych w interfejsie RTL lub RTL proste formatowanie może skutkować nieprawidłowym lub nawet nieczytelnym tekstem wyjściowym.

W przypadku takich języków jak arabski, hebrajski, perski i urdu używany jest zapis RTL. Jednak niektóre elementy, np. liczby i umieszczony tekst LTR, są zapisywane w formacie LTR w innym miejscu w tekście od prawej do lewej. Języki używające skryptów LTR, w tym angielski, również są dwukierunkowe, ponieważ mogą zawierać osadzone skrypty RTL, które muszą wyświetlać się od prawej do lewej.

Aplikacje często generują tego typu wystąpienia tego typu umieszczonego w odwrotnym kierunku, na przykład wstawiając dane tekstowe w dowolnym języku i w dowolnym kierunku tekstu w zlokalizowanych wiadomościach. Takie połączenie wskazówek często nie wskazuje, gdzie zaczyna się i kończy tekst o przeciwnej stronie, więc tekst generowany przez aplikację może źle wpływać na wygodę użytkowników.

Choć domyślna obsługa dwukierunkowego tekstu w systemie zwykle renderuje się zgodnie z oczekiwaniami, może się on nie wyświetlać prawidłowo, gdy aplikacja wstawi go do zlokalizowanej wiadomości. Oto przykłady sytuacji, w których tekst może się nieprawidłowo wyświetlać:

  • Tekst wstawiony na początku wiadomości:

    PERSON_NAME dzwoni do Ciebie

  • tekst zaczynający się od numeru, np. adresu lub numeru telefonu:

    987 654-3210

  • Tekst zaczynający się od znaków interpunkcyjnych, np. numer telefonu:

    +19876543210

  • Tekst, który kończy się znakiem interpunkcyjnym:

    Czy na pewno chcesz to zrobić?

  • Tekst, który zawiera już obie kierunki:

    Słowo CPV VPC to hebrajski skrót oznaczający banan.

Przykład

Załóżmy, że aplikacja musi czasami wyświetlić komunikat „Czy chodziło Ci o %s?”, w którym zamiast %s pojawia się adres. Aplikacja obsługuje różne języki interfejsu, więc komunikat pochodzi z zasobów w konkretnej lokalizacji i używa kierunku RTL, gdy urządzenie jest ustawione na język RTL. Na przykład w interfejsie hebrajskim komunikat ten wygląda tak:

PLACEHOLDER כוルר ל %s

Sugerowany adres może jednak pochodzić z bazy danych, która nie zawiera tekstu w języku regionu. Jeśli na przykład adres dotyczy miejsca w Kalifornii, zostanie wyświetlony w bazie danych w języku angielskim. Jeśli w wiadomości RTL wstawisz adres „15 Bay Street, Laurel, CA” bez podawania wskazówek dotyczących kierunku tekstu, wynik będzie nieprawidłowy:

電 盡וル Identification ל 15 Bay Street, Laurel, Kalifornia?

Numer domu wyświetla się po prawej stronie adresu, a nie po lewej. W ten sposób numer domu wygląda jak dziwny kod pocztowy. Ten sam problem może wystąpić, jeśli umieścisz tekst od prawej do lewej w wiadomości z tekstem w kierunku LTR.

Wyjaśnienie i rozwiązanie

W tym przykładzie problem występuje, ponieważ narzędzie do formatowania tekstu nie określa, że ciąg „15” jest częścią adresu, tak więc system nie jest w stanie określić, czy numer „15” jest częścią tekstu RTL poprzedzającego ten tekst, czy też tekstu LTR, który następuje po nim.

Aby rozwiązać ten problem, użyj metody unicodeWrap() z klasy BidiFormatter. Ta metoda wykrywa kierunek ciągu i zawija go w znaki formatu Unicode, które deklarują ten kierunek.

Ten fragment kodu pokazuje, jak używać unicodeWrap():

Kotlin

val mySuggestion = "15 Bay Street, Laurel, CA"
val myBidiFormatter: BidiFormatter = BidiFormatter.getInstance()

// The "did_you_mean" localized string resource includes
// a "%s" placeholder for the suggestion.
String.format(getString(R.string.did_you_mean), myBidiFormatter.unicodeWrap(mySuggestion))

Java

String mySuggestion = "15 Bay Street, Laurel, CA";
BidiFormatter myBidiFormatter = BidiFormatter.getInstance();

// The "did_you_mean" localized string resource includes
// a "%s" placeholder for the suggestion.
String.format(getString(R.string.did_you_mean),
        myBidiFormatter.unicodeWrap(mySuggestion));

Ponieważ liczba „15” pojawia się teraz w tekście zadeklarowanym jako LTR, wyświetla się we właściwym miejscu:

電話כוו fazie ל 15 Bay Street, Laurel, Kalifornia

Używaj metody unicodeWrap() w każdym fragmencie tekstu, który umieszczasz w zlokalizowanej wiadomości, chyba że spełniony jest jeden z tych warunków:

  • Tekst jest wstawiany do ciągu zrozumiałego dla komputera, takiego jak identyfikator URI lub zapytanie SQL.
  • Wiesz, że ten fragment tekstu jest już prawidłowo zawinięty.

Uwaga: jeśli Twoja aplikacja jest kierowana na Androida 4.3 (poziom interfejsu API 18) lub nowszego, użyj wersji BidiFormatter dostępnej w Android Framework. W przeciwnym razie użyj wersji BidiFormatter z biblioteki pomocy.

Formatowanie liczb

Użyj ciągów formatu, a nie wywołań metod, aby przekonwertować liczby na ciągi znaków w logice aplikacji:

Kotlin

var myIntAsString = "$myInt"

Java

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

Sformatuje on liczby odpowiednio do Twojego regionu, co może obejmować użycie innego zestawu cyfr.

Gdy używasz String.format() do tworzenia zapytań SQL na urządzeniu z ustawieniami języka, który korzysta z własnego zestawu cyfr (np. w języku perskim i większości języków arabskich), problemy występują wtedy, gdy którymkolwiek z parametrów zapytania są liczby. Wynika to z faktu, że numer jest sformatowany w postaci cyfr obowiązujących w danym języku, przez co są one nieprawidłowe w kodzie SQL.

Aby zachować liczby w formacie ASCII i prawidłowe zapytanie SQL, musisz użyć przeciążonej wersji String.format(), która jako pierwszy parametr zawiera język lokalny. Użyj argumentu dotyczącego języka Locale.US.

Obsługa powielania układu

Użytkownicy korzystający ze skryptów RTL wolą interfejs od prawej do lewej, który zawiera menu wyrównane do prawej, tekst wyrównany do prawej i strzałki do przodu wskazujące lewą stronę.

Rysunek 4 przedstawia kontrast między wersją LTR ekranu w aplikacji Ustawienia a jego odpowiednikiem z widokiem od prawej do lewej:

Obszar powiadomień jest wyrównany do prawej w prawym górnym rogu, przycisk menu na pasku aplikacji znajduje się w lewym górnym rogu, treść w głównej części ekranu jest wyrównana do lewej i ma postać LTR, a przycisk Wstecz znajduje się w lewym dolnym rogu i wskazuje w lewo. Obszar powiadomień jest wyrównany do lewej w lewym górnym rogu, przycisk menu na pasku aplikacji znajduje się w prawym górnym rogu, zawartość w głównej części ekranu jest wyrównana do prawej strony od prawej do lewej, a przycisk Wstecz znajduje się w prawym dolnym rogu i wskazuje w prawo
Rysunek 4. Warianty ekranu ustawień w formacie LTR i RTL.

Dodając obsługę RTL do aplikacji, pamiętaj o tych kwestiach:

  • Odbicie lustrzane tekstu RTL jest obsługiwane tylko w aplikacjach na urządzeniach z Androidem 4.2 (poziom interfejsu API 17) lub nowszym. Aby dowiedzieć się, jak włączyć odbicie lustrzane tekstu na starszych urządzeniach, przeczytaj sekcję Zapewnianie obsługi starszych aplikacji w tym przewodniku.
  • Aby sprawdzić, czy aplikacja obsługuje kierunek tekstu od prawej do lewej, przetestuj go za pomocą opcji programisty opisanych w tym przewodniku i zaproś do korzystania z aplikacji osoby używające skryptów RTL.

Uwaga: więcej wskazówek projektowych związanych z odbiciem lustrzanym układu, w tym listę elementów, które są i których nie można powielić w wersji lustrzanej, znajdziesz w wytycznych dotyczących dwukierunkowości.

Aby odzwierciedlić w aplikacji układ interfejsu od prawej do lewej w ustawieniach języka od prawej do lewej, wykonaj czynności opisane w sekcjach poniżej.

Zmodyfikuj pliki kompilacji i pliku manifestu.

Zmodyfikuj plik build.gradle modułu aplikacji i plik manifestu aplikacji w następujący sposób:

build.gradle (Module: app)

Odlotowy

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

Kotlin

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

AndroidManifest.xml

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

Uwaga: jeśli Twoja aplikacja jest kierowana na Androida 4.1.1 (poziom interfejsu API 16) lub starszego, atrybut android:supportsRtl zostanie zignorowany wraz z wartościami atrybutów start i end, które występują w plikach układu aplikacji. W takim przypadku odbicie lustrzane układu RTL nie odbywa się automatycznie w aplikacji.

Aktualizowanie istniejących zasobów

Przekonwertuj odpowiednio left i right na start i end w istniejących plikach zasobów układu. Dzięki temu platforma może dostosowywać elementy interfejsu aplikacji do ustawień języka użytkownika.

Uwaga: zanim zaktualizujesz swoje zasoby, dowiedz się, jak zapewnić pomoc dotyczącą starszych aplikacji lub aplikacji kierowanych na Androida 4.1.1 (poziom API 16) lub niższy.

Aby skorzystać z możliwości wyrównywania RTL platformy, zmień atrybuty w plikach układu, które są widoczne w tabeli 1.

Tabela 1. Atrybuty do użycia, gdy aplikacja obsługuje wiele wskazówek tekstowych

Atrybut obsługujący tylko LTR Atrybut obsługujący LTR i RTL
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

Tabela 2 pokazuje, jak system obsługuje atrybuty wyrównania interfejsu użytkownika w zależności od docelowej wersji pakietu SDK, czy są zdefiniowane atrybuty left i right oraz czy zdefiniowano atrybuty start i end.

Tabela 2. Zachowanie dopasowania elementów interfejsu na podstawie docelowej wersji pakietu SDK i zdefiniowanych atrybutów

Kierowanie na Androida 4.2
(poziom interfejsu API 17) lub nowszego? 		Zdefiniowano lewą i prawą stronę? Zdefiniowano datę rozpoczęcia i zakończenia? Wynik
Tak Tak Tak Używane są start i end; zastępują one left i right
Tak Tak Nie Użyto left i right
Tak Nie Tak Użyto start i end
Nie Tak Tak Używane są left i right (start i end są ignorowane)
Nie Tak Nie Użyto left i right
Nie Nie Tak start i end łączą się z: left i right

Dodawanie zasobów związanych z kierunkiem i językiem

Ten krok obejmuje dodanie określonych wersji układu, elementów rysowanych i wartości plików zasobów zawierających niestandardowe wartości dla różnych języków i kierunków tekstu.

W Androidzie 4.2 (poziom interfejsu API 17) i nowszych możesz używać kwalifikatorów zasobów -ldrtl (układ-kierunku-od prawej do lewej) i -ldltr (układ-kierunku od lewej do prawej). Aby zachować wsteczną zgodność z istniejącymi zasobami, starsze wersje Androida używają kwalifikatorów języka zasobu w celu określenia prawidłowego kierunku tekstu.

Załóżmy, że chcesz dodać plik układu do obsługi skryptów RTL, np. hebrajski, arabski i perski. Aby to zrobić, dodaj katalog layout-ldrtl/ do katalogu res/, jak pokazano w tym przykładzie:

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.

Jeśli chcesz dodać konkretną wersję układu przeznaczoną tylko dla tekstu arabskiego, struktura katalogów wygląda tak:

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.

Uwaga: zasoby specyficzne dla języka mają pierwszeństwo przed zasobami dotyczącymi układu, które mają pierwszeństwo przed zasobami domyślnymi.

Korzystanie z obsługiwanych widżetów

Od Androida 4.2 (poziom interfejsu API 17) większość elementów interfejsu platformy automatycznie obsługuje kierunek tekstu RTL automatycznie. Jednak kilka elementów platformy, np. ViewPager, nie obsługuje kierunku tekstu od prawej do lewej.

Widżety na ekranie głównym obsługują kierunek tekstu od prawej do lewej, o ile odpowiadające im pliki manifestu zawierają przypisanie atrybutu android:supportsRtl="true".

Obsługa starszych aplikacji

Jeśli Twoja aplikacja jest kierowana na Androida 4.1.1 (poziom interfejsu API 16) lub starszego, oprócz start i end dodaj atrybuty left i right.

Aby sprawdzić, czy układ musi mieć kierunek tekstu od prawej do lewej, użyj tej logiki:

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

Uwaga: aby uniknąć problemów ze zgodnością, używaj narzędzi do kompilacji pakietu Android SDK w wersji 23.0.1 lub nowszej.

Testowanie za pomocą opcji programisty

Na urządzeniach z Androidem 4.4 (poziom interfejsu API 19) lub nowszym możesz włączyć Wymuś kierunek układu RTL w opcjach programisty na urządzeniu. Dzięki temu ustawieniu możesz wyświetlać w trybie RTL tekst wykorzystujący skrypty LTR, np. tekst w języku angielskim.

Zaktualizuj logikę aplikacji

W tej sekcji omawiamy konkretne aspekty logiki aplikacji, które należy zaktualizować podczas jej dostosowywania pod kątem obsługi wielu wskazówek tekstowych.

Zmiany usługi

Aby wprowadzić zmianę w dowolnej właściwości związanej z od strony RTL, np. kierunku układu, parametrów układu, dopełnienia, kierunku tekstu, wyrównania tekstu lub pozycjonowania, użyj wywołania zwrotnego onRtlPropertiesChanged(). To wywołanie zwrotne pozwala uzyskać bieżący kierunek układu i odpowiednio zaktualizować obiekty View aktywności.

Wyświetlenia

Jeśli tworzysz widżet interfejsu, który nie jest bezpośrednio częścią hierarchii widoków aktywności, na przykład okno lub element interfejsu przypominający komunikat, ustaw prawidłowy kierunek układu w zależności od kontekstu. Ten fragment kodu pokazuje, jak wykonać ten proces:

Kotlin

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

Java

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

Niektóre metody klasy View wymagają dodatkowej uwagi:

onMeasure()
Wymiary widocznego obszaru mogą się różnić w zależności od kierunku tekstu.
onLayout()
Jeśli tworzysz własną implementację układu, musisz wywołać super() w swojej wersji onLayout() i dostosować swoją logikę do obsługi skryptów RTL.
onDraw()
Jeśli implementujesz widok niestandardowy lub dodajesz do rysunku zaawansowane funkcje, musisz zaktualizować kod pod kątem obsługi skryptów RTL. Aby określić, czy widżet działa w trybie RTL, użyj tego kodu:

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

Elementy rysowalne

Jeśli masz obiekt rysowalny, który wymaga odbicia lustrzanego w układzie od prawej do lewej, wykonaj jedną z tych czynności w zależności od wersji Androida na urządzeniu:

  • Na urządzeniach z Androidem 4.3 (poziom interfejsu API 18) lub starszym dodaj i zdefiniuj pliki zasobów -ldrtl.

  • Na Androidzie 4.4 (poziom interfejsu API 19) i nowszych użyj do definiowania elementów rysowanych za pomocą android:autoMirrored="true", dzięki czemu system będzie obsługiwać odbicie lustrzane układu RTL.

    Uwaga: atrybut android:autoMirrored działa tylko w przypadku prostych elementów rysowanych, których dwukierunkowe odbicie lustrzane jest po prostu graficznym odbiciem całego elementu rysowalnego. Jeśli obiekt rysowalny zawiera wiele elementów lub jego odbicie zmienia jego interpretację, możesz wykonać odbicie lustrzane. W miarę możliwości skonsultuj się z ekspertem ds. dwukierunkowej, aby określić, czy powielane elementy rysowania są zgodne z oczekiwaniami użytkowników.

Ciążenie

Jeśli kod układu aplikacji korzysta z elementów Gravity.LEFT lub Gravity.RIGHT, zmień te wartości odpowiednio na Gravity.START i Gravity.END.

Jeśli masz kod Kotlin lub Java, który zależy od właściwości Gravity.LEFT lub Gravity.RIGHT, możesz go dostosować do tej zmiany, ustawiając wartość absoluteGravity zgodnie z wartością layoutDirection.

Na przykład jeśli używasz tego kodu:

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

Zmień go na taki:

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

Oznacza to, że możesz zachować obecny kod, który obsługuje wartości wyrównane do lewej lub do prawej, nawet jeśli używasz atrybutów start i end jako wartości grawitacji.

Uwaga: podczas stosowania ustawień grawitacji używaj przeciążonej wersji Gravity.apply() z argumentem layoutDirection.

Marginesy i dopełnienie

Aby obsługiwać w aplikacji skrypty RTL, postępuj zgodnie z tymi sprawdzonymi metodami dotyczącymi wartości marginesów i dopełnienia:

Obsługa preferencji językowych dla poszczególnych aplikacji

W wielu przypadkach użytkownicy wielojęzyczni ustawiają w swoim systemie język na jeden język, np. angielski, ale chcą wybrać inne języki dla poszczególnych aplikacji, takie jak niderlandzki, chiński czy hindi. Aby zapewnić użytkownikom lepsze wrażenia podczas korzystania z aplikacji, Android 13 wprowadza te funkcje w aplikacjach obsługujących wiele języków:

  • Ustawienia systemu: centralne miejsce, w którym użytkownicy mogą wybrać preferowany język każdej aplikacji.

    Aplikacja musi zadeklarować atrybut android:localeConfig w swoim pliku manifestu, aby poinformować system, że obsługuje ona wiele języków. Więcej informacji znajdziesz w instrukcjach tworzenia pliku zasobów i deklarowania go w pliku manifestu aplikacji.

  • Dodatkowe interfejsy API: te publiczne interfejsy API, takie jak metody l10n-placeholder1">setApplicationLocales() i l10n-placeholder2">getApplicationLocales() w LocaleManager, pozwalają aplikacjom ustawiać w czasie działania język inny niż język systemu.

    Aplikacje korzystające z niestandardowych selektorów języka w aplikacji mogą używać tych interfejsów API, aby zapewnić użytkownikom spójne wrażenia niezależnie od tego, gdzie wybiorą ustawienia językowe. Publiczne interfejsy API również pomagają ograniczyć ilość powtarzającego się kodu i obsługują dzielone pakiety APK. Obsługują też Automatyczną kopię zapasową dla aplikacji, która pozwala na przechowywanie ustawień języka użytkownika na poziomie aplikacji.

    Aby zapewnić zgodność wsteczną z poprzednimi wersjami Androida, w AndroidzieX dostępne są też odpowiadające im interfejsy API. Zalecamy użycie Appcompat w wersji 1.6.0-beta01 lub nowszej.

    Więcej informacji znajdziesz w instrukcjach wdrażania nowych interfejsów API.

Zobacz także:

Dodatkowe materiały

Więcej informacji o obsłudze starszych urządzeń znajdziesz w tych materiałach:

Posty na blogu

Wstecz
创建多个具有多个尺寸的 APK
Dalej
支持不同的平台版本