Android
Internacjonalizacja i lokalizacja (I18N i L10N)
Szukaj…
Wprowadzenie
Internacjonalizacja (i18n) i lokalizacja (L10n) służą do dostosowania oprogramowania do różnic w językach, różnic regionalnych i odbiorców docelowych.
Internacjonalizacja: proces planowania przyszłej lokalizacji, tj. Uelastycznienie projektu oprogramowania w stopniu umożliwiającym dostosowanie i dostosowanie do przyszłych działań lokalizacyjnych.
Lokalizacja: proces dostosowywania oprogramowania do określonego regionu / kraju / rynku (lokalizacji).
Uwagi
Aby przetestować urządzenie pod kątem lokalizacji, urządzenie lub emulator można ponownie uruchomić w określonych ustawieniach adb
używając adb
w następujący sposób:
- Uruchom adb za pomocą polecenia:
adb shell
- Uruchom następujące polecenie w wierszu polecenia adb:
setprop persist.sys.locale [BCP-47 language tag];stop;sleep 5;start
gdzie [znacznik języka BCP-47] to kod specyficzny dla języka, jak opisano tutaj: kody BCP47
np. aby sprawdzić japońską lokalizację w aplikacji, użyj polecenia: setprop persist.sys.locale ja-JP;stop;sleep 5;start
Planowanie lokalizacji: włącz obsługę RTL w Manifeście
Obsługa RTL (od prawej do lewej) jest istotną częścią planowania i18n i L10n. W przeciwieństwie do języka angielskiego, który jest pisany od lewej do prawej, wiele języków, takich jak arabski, japoński, hebrajski itp., Jest pisanych od prawej do lewej. Aby odwołać się do bardziej globalnej publiczności, dobrze jest zaplanować układy, aby obsługiwały ten język od samego początku projektu, aby później ułatwić dodanie lokalizacji.
Wsparcie RTL może być włączone w aplikacji na Androida dodając supportsRtl
tag w AndroidManifest
, tak jak poniżej:
<application
...
android:supportsRtl="true"
...>
...
</application>
Planowanie lokalizacji: dodaj obsługę RTL w układach
Począwszy od SDK 17 (Android 4.2), dodano obsługę RTL w układach Androida i jest istotną częścią lokalizacji. Idąc dalej, left/right
notację w układach należy zastąpić notacją start/end
. Jeśli jednak twój projekt ma wartość minSdk
mniejszą niż 17
, wówczas w układach należy stosować zarówno left/right
i start/end
notację.
W przypadku układów względnych należy alignParentStart
i alignParentEnd
, podobnie jak:
<RelativeLayout
android:layout_width="match_parent"
android:layout_height="match_parent">
<TextView
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:layout_alignParentTop="true"
android:layout_alignParentLeft="true"
android:layout_alignParentStart="true"/>
<TextView
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:layout_alignParentTop="true"
android:layout_alignParentRight="true"
android:layout_alignParentEnd="true"/>
</RelativeLayout>
Do określenia grawitacji i grawitacji układu należy użyć podobnej notacji, tak jak:
<TextView
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:layout_gravity="left|start"
android:gravity="left|start"/>
<TextView
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:layout_gravity="right|end"
android:gravity="right|end"/>
Należy również odpowiednio określić wypełnienia i marginesy:
<include layout="@layout/notification"
android:layout_width="fill_parent"
android:layout_height="wrap_content"
android:layout_marginLeft="12dp"
android:layout_marginStart="12dp"
android:paddingLeft="128dp"
android:paddingStart="128dp"
android:layout_toLeftOf="@id/cancel_action"
android:layout_toStartOf="@id/cancel_action"/>
<include layout="@layout/notification2"
android:layout_width="fill_parent"
android:layout_height="wrap_content"
android:layout_marginRight="12dp"
android:layout_marginEnd="12dp"
android:paddingRight="128dp"
android:paddingEnd="128dp"
android:layout_toRightOf="@id/cancel_action"
android:layout_toEndOf="@id/cancel_action"/>
Planowanie lokalizacji: Układy testowe dla RTL
Aby sprawdzić, czy utworzone układy są zgodne z RTL, wykonaj następujące czynności:
Przejdź do Ustawienia -> Opcje programisty -> Rysunek -> Wymuś kierunek układu RTL
Włączenie tej opcji zmusiłoby urządzenie do korzystania z ustawień regionalnych RTL i można łatwo zweryfikować wszystkie części aplikacji pod kątem obsługi RTL. Pamiętaj, że do tego momentu nie musisz dodawać żadnych nowych lokalizacji / obsługi języków.
Kodowanie dla lokalizacji: tworzenie domyślnych ciągów i zasobów
Pierwszym krokiem do kodowania lokalizacji jest utworzenie zasobów domyślnych. Ten krok jest tak niejawny, że wielu programistów nawet o tym nie myśli. Jednak tworzenie zasobów domyślnych jest ważne, ponieważ jeśli urządzenie działa w nieobsługiwanych ustawieniach narodowych, ładuje wszystkie swoje zasoby z folderów domyślnych. Jeśli brakuje nawet jednego z zasobów w folderach domyślnych, aplikacja po prostu ulegnie awarii.
Domyślny zestaw ciągów znaków należy umieścić w następującym folderze w określonej lokalizacji:
res/values/strings.xml
Ten plik powinien zawierać ciągi w języku, którym powinna posługiwać się większość użytkowników aplikacji.
Ponadto domyślne zasoby aplikacji należy umieścić w następujących folderach i lokalizacjach:
res/drawable/
res/layout/
Jeśli aplikacja wymaga folderów takich jak anim
lub xml
, domyślne zasoby należy dodać do następujących folderów i lokalizacji:
res/anim/
res/xml/
res/raw/
Kodowanie dla lokalizacji: dostarczanie alternatywnych ciągów
Aby zapewnić tłumaczenia na inne języki (ustawienia narodowe), musimy utworzyć plik strings.xml
w osobnym folderze zgodnie z następującą konwencją:
res/values-<locale>/strings.xml
Przykład tego samego podano poniżej:
W tym przykładzie mamy domyślne angielskie ciągi znaków w pliku res/values/strings.xml
, tłumaczenia francuskie znajdują się w folderze res/values-fr/strings.xml
a tłumaczenia japońskie w folderze res/values-ja/strings.xml
Inne tłumaczenia dla innych ustawień regionalnych można podobnie dodać do aplikacji.
Pełna lista kodów regionalnych znajduje się tutaj: kody ISO 639
Ciągi nieprzetłumaczalne:
Twój projekt może mieć pewne ciągi, których nie należy tłumaczyć. Ciągi używane jako klucze dla SharedPreferences lub ciągi używane jako symbole należą do tej kategorii. Ciągi te powinny być przechowywane tylko w domyślnym strings.xml
i powinny być oznaczone atrybutem do translatable="false"
. na przykład
<string name="pref_widget_display_label_hot">Hot News</string>
<string name="pref_widget_display_key" translatable="false">widget_display</string>
<string name="pref_widget_display_hot" translatable="false">0</string>
Ten atrybut jest ważny, ponieważ tłumaczenia są często wykonywane przez osoby dwujęzyczne. Pozwoliłoby to osobom zaangażowanym w tłumaczenia zidentyfikować ciągi, które nie powinny być tłumaczone, oszczędzając w ten sposób czas i pieniądze.
Kodowanie lokalizacji: udostępnianie alternatywnych układów
Tworzenie układów specyficznych dla języka jest często niepotrzebne, jeśli określono prawidłową notację start/end
, jak opisano we wcześniejszym przykładzie. Mogą jednak wystąpić sytuacje, w których domyślne układy mogą nie działać poprawnie w niektórych językach. Czasami układy od lewej do prawej mogą nie tłumaczyć dla języków RTL. W takich przypadkach konieczne jest zapewnienie prawidłowego układu.
Aby zapewnić pełną optymalizację układów RTL, możemy użyć całkowicie oddzielne pliki układu pomocą ldrtl
kwalifikator zasobów ( ldrtl
oznacza układ kierunku-prawo-lewo}). Na przykład możemy zapisać domyślne pliki układów w res/layout/
a nasze zoptymalizowane układy RTL w res/layout-ldrtl/
.
Kwalifikator ldrtl
doskonale nadaje się do zasobów, które można wyciągać, dzięki czemu można dostarczać grafiki zorientowane w kierunku odpowiadającym kierunkowi czytania.
Oto świetny post, który opisuje pierwszeństwo układów ldrtl
: Układy specyficzne dla języka