O jakich zastrzeżeniach powinienem pamiętać podczas lokalizowania liczb w aplikacji front-end?
Przykład: w brazylijskim portugalskim (pt-BR) dzielimy tysiące kropkami i dziesiętnymi przecinkami. W amerykańskim angielskim (en-US) jest inaczej. W pt-BR przedstawiamy cyfry oddzielone tysiącami, takie same jak w en-US. Ale czytając o indyjskim angielskim (en-IN) dzisiaj spotkałem ten klejnot:
Indyjski system numeracji jest preferowany do grupowania cyfr. Liczby mniejsze niż 100 000/100 000 są pisane słowami lub wypowiadane tak, jak w języku angielskim standardowym. Liczby w tym i powyżej 100 000/100 000 są wyrażone w podzbiorze indyjskiego systemu numeracji.
https://en.wikipedia.org/wiki/Indian_English#Numbering_system
Co znaczy:
1000000 units in pt-BR are formatted 1.000.000
1000000 units in en-US are formatted 1,000,000
1000000 units in en-IN are formatted 10,00,000
Oprócz przecinków, kropek i innych specyficznych separatorów wydaje się, że maskowanie jest również ważnym problemem.
Jakie inne zastrzeżenia powinienem znać podczas lokalizowania liczb w mojej aplikacji front-end? Zwłaszcza jeśli wyświetlam liczby zestawom znaków spoza alfabetu łacińskiego?
Odpowiedzi:
Większość języków programowania i struktur ma już rozsądny, działający mechanizm, którego można użyć do tego celu.
Na przykład ekosystem C # ma przestrzeń nazw System.Globalization , która pozwala określić
Culture
żądane:To nie jest coś, co chcesz na nowo wynaleźć. Skorzystaj z funkcji internacjonalizacji zapewnianych przez ulubiony język lub środowisko.
źródło
,
ciągu formatu jest w dużej mierze nieistotna i „#, 0,00” miałby ten sam efekt.,
oznacza po prostu „użyj separatorów grup liczb w sposób określony przez ustawienia regionalne”.Kilka doskonałych odpowiedzi już tutaj, ale nie wspomniały o jednej rzeczy, która moim zdaniem jest ważna, aby nie zapomnieć: upewnij się, że wszędzie tam, gdzie ma miejsce formatowanie liczb, jest jasne (lub można kontrolować), do czego służy wyjście:
w przypadku interfejsu użytkownika należy zastosować zlokalizowane formatowanie
gdy numer ma zostać zapisany do pliku lub wysłany przez sieć lub inną formę, w której numer jest potrzebny w formie do odczytu maszynowego , upewnij się, że nie jest sformatowany zgodnie z bieżącą kulturą, ale zgodnie ze stałym ustawieniem (na przykład w środowisku .NET użyj
InvariantCulture
).W przeciwnym razie występują problemy, gdy liczby są zapisywane lub wysyłane za pomocą kultury A oraz czytane lub odbierane za pomocą kultury B.
Z mojego doświadczenia wynika, że jest to jedna z największych przeszkód w prawidłowej lokalizacji liczb: próbując scentralizować formatowanie i konwersję liczb, ludzie zaczynają tworzyć ogólne funkcje wielokrotnego użytku do formatowania, a następnie zaczynają z nich korzystać w całym miejsce. Jednak gdy tylko liczby będą potrzebne w formacie łańcucha odczytywalnym maszynowo w innym miejscu programu, potrzebne są dwa warianty: formatowanie zlokalizowane i formatowanie nielokalizowane. Wprowadza to wysokie ryzyko pomieszania dwóch form konwersji (szczególnie, gdy programiści i maszyny testujące mają swoje domyślne ustawienia regionalne podobne do „ustalonego” ustawienia używanego do formatowania innego niż interfejs użytkownika, ale część bazy użytkowników tego nie zrobiła).
Dodatek: ten problem może stać się naprawdę paskudny w sytuacjach, w których wcześniej nie jest jasne, czy numer zostanie przetworzony przez maszynę, czy przez człowieka (lub jedno i drugie) później. Na przykład jako część wyniku pliku dziennika. W takich przypadkach prawdopodobnie najlepiej trzymać się „neutralnego” standardu, w którym nie stosuje się separatora oprócz kropki jako separatora dziesiętnego.
źródło
Właściwa lokalizacja jest dość trudna. Większość ekosystemów programistycznych próbuje rozwiązań dla lokalizacji, ale z mojego doświadczenia wynika, że wszystkie są mniej lub bardziej zepsute. Proponuję zatem:
Nie próbuj automatyzować lokalizacji. Nie zawsze będzie działać. Trudno jest dostrzec problemy i frustrujące dla użytkowników.
Bądź spójny: nie mieszaj różnych języków i konwencji formatowania, np. Separatory dziesiętne w stylu brazylijskim w tekście angielskim.
Jawnie obsługuje dany zestaw ustawień narodowych. Współpracuj z tłumaczami, aby znaleźć odpowiednie formatowanie dat i liczb. Najprawdopodobniej skończysz tworzenie własnego zestawu narzędzi lokalizacyjnych, chociaż większość (ale nie wszystkie) problemy można przekazać do istniejącej biblioteki.
Twórz proste opcje formatowania konfigurowane przez każdego użytkownika: formaty dat i godzin, separatory dziesiętne, preferowana waluta,…. Jest to szczególnie przydatne dla podróżników, emigrantów lub innych osób, które muszą mieszać wiele lokalizacji lub kultur niezależnie od języka.
źródło
Ważna uwaga: powinieneś zdecydować, ile wystarczy. Ponieważ jeśli pójdziesz do króliczej nory, próbując perfekcyjnie zlokalizować, stanie się to coraz bardziej złożone.
Wybierz typową etykietę, na przykład „Wybrałeś n elementów”. Czyta się źle, jeśli wybrano tylko jeden element. Brzydkim, ale pragmatycznym rozwiązaniem jest napisanie „Wybrałeś n elementów”. Ale jeśli chcesz to zrobić poprawnie, potrzebujesz dwóch różnych tekstów w zależności od n. Jeśli spróbujesz to zrobić w wielu lokalizacjach, szybko stanie się to naprawdę skomplikowane, ponieważ różne języki mają inną gramatykę. Niektóre języki mają różne koniugacje dla jednego, dwóch i wielu przedmiotów i tak dalej. Z tego powodu znani ludzie zawsze będą narzekać, że istniejące ramy lokalizacyjne są niewystarczające.
Ale musisz wybrać swoje bitwy i zdecydować, jaki poziom wyrafinowania jest wystarczający. Do wielu celów wystarczy standardowa biblioteka lokalizacji do formatowania liczb i dat.
źródło
Nie możesz być świadomy wszystkich zastrzeżeń dotyczących języków. Mówisz o liczbach, ale są też liczby mnogie, rodzaje, zestawienia. Musisz wiedzieć, że istnieją i polegać na rozległej pracy wykonanej przez inne osoby, w szczególności na projektach OIOM i CLDR.
Większość współczesnych języków implementuje niektóre lub wszystkie funkcje tych projektów, ale nawet jeśli tego nie zrobią, czytanie o tych projektach da ci dobry pomysł na to, czego szukać.
http://site.icu-project.org
http://cldr.unicode.org
Aktualizacja
Narzędzie ankiety CLDR zapewnia dostęp do wszystkich wzorców. To pokaże, jak sformatować liczbę w określonym języku i regionie. Na przykład portugalski (Portugalia):
http://st.unicode.org/cldr-apps/v#/pt_PT/Number_Formatting_Patterns/
A jeśli naprawdę chcesz sprawdzić wszystkie dane (i być może je wykorzystać), możesz pobrać CLDR w formacie JSON z GitHub:
https://github.com/unicode-cldr/cldr-json#cldr-json
Więcej informacji na temat pobierania tutaj:
http://cldr.unicode.org/index/downloads
źródło
Cóż, chociaż jestem zadowolony ze wszystkich odpowiedzi tutaj, nie jestem naprawdę zadowolony z każdej z nich osobno, aby oznaczyć jedną jako prawidłową odpowiedź.
Jak do tej pory powinniśmy być świadomi lokalizowania liczb:
Dla ludzi :
Dla komputerów :
Dla programistów :
źródło