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:

  1. Uruchom adb za pomocą polecenia: adb shell
  2. 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:

Przykład dla ustawień regionalnych

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



Modified text is an extract of the original Stack Overflow Documentation
Licencjonowany na podstawie CC BY-SA 3.0
Nie związany z Stack Overflow