Dlaczego lokalizacja potrzebuje danych regionalnych
Przetłumaczenie etykiety „Razem” nie rozstrzyga zapisu liczby obok niej. Produkt wymaga też decyzji o datach, walutach, sortowaniu i konwencjach właściwych użytkownikom.
Praktyczny wniosek to oddzielenie przekładu tekstu od prezentacji regionalnej. Tłumacz nie powinien przepisywać ciągu daty przy każdym wyświetleniu nowej daty przez aplikację.
Przykładowy problem formatowania
Strona faktury ma pięć wersji językowych. Kwota, waluta i data pochodzą z danych strukturalnych. Jeśli programista składa je jednym ręcznie napisanym wzorcem dla wszystkich regionów, przetłumaczone etykiety mogą otaczać niejednoznaczne lub nietypowe wartości.
Zalecamy określić ustawienia regionalne każdego scenariusza i wyrenderować reprezentatywne kwoty oraz daty przez obsługiwany system formatowania aplikacji. Porównaj wynik z udokumentowanymi oczekiwaniami odbiorców. Uwzględnij zero, duże kwoty i daty odczytywane w dwóch kolejnościach.
To redakcyjne propozycje testów, nie lista obowiązkowych kontroli zgodności CLDR ani twierdzenie o konkretnym formatowaniu w danym środowisku.
Wsparcie wersji zależy od wdrożenia
Publikacja CLDR nie oznacza, że każda przeglądarka, system i biblioteka już jej używa. Badając różnice, zalecamy zapisać wersję danych odniesienia i wdrożone środowisko wykonawcze.
Dla zespołu produktowego aktualizacja biblioteki może być równie ważna jak redakcja przekładu. Różnica może wynikać ze starego pakietu danych, a nie tekstu.
LISA i AI
CLDR jest projektem Unicode o własnej historii. W tej kolekcji stanowi techniczną podstawę lokalizacji, nie bezpośredniego następcę normy LISA.
W pracy z AI zalecamy dane strukturalne i odpowiednie formatowanie w środowisku wykonawczym, zamiast zlecania modelowi wymyślania reguł przy każdym żądaniu. AI może wykryć podejrzany przykład, lecz nie powinno niejawnie redefiniować konwencji regionu.
Źródła i dalsza lektura
wydania CLDR, opis projektu i UTS #35.
Powiązane: BCP 47, MessageFormat 2, XLIFF.