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
).
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 Hiszpanii (język es_ES
) w języku
/mipmap-b+es+ES/country_flag.png
:
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:
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 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
.
|
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 wersjionLayout()
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:
-
Użyj właściwości
getMarginStart()
igetMarginEnd()
zamiast ich odpowiedników w atrybutach kierunku:leftMargin
irightMargin
. -
Gdy używasz funkcji
setMargins()
, zamień wartości argumentówleft
iright
, jeśli aplikacja wykryje skrypty RTL. -
Jeśli aplikacja obsługuje niestandardowe dopełnienie, zastąp
setPadding()
isetPaddingRelative()
.
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()
wLocaleManager
, 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: