Tworzysz aplikację ASP.Net MVC, prawda? Inne odpowiedzi wydają się być specyficzne dla aplikacji komputerowych. Pozwól mi uchwycić wspólne rzeczy:
Wykrywanie ustawień regionalnych
Bardzo ważne jest, aby aplikacja poprawnie wykrywała lokalizację użytkownika. W aplikacji komputerowej CultureInfo.CurrentCulture posiada preferowane ustawienia formatowania (ten, który powinien być używany do formatowania liczb, dat, walut itp.), Podczas gdy CultureInfo.CurrentUICulture posiada preferowane ustawienia regionalne interfejsu użytkownika (ten, który powinien być używany do wyświetlania zlokalizowanych wiadomości) . W przypadku aplikacji internetowych należy ustawić obie kultury na automatyczne (aby automatycznie wykrywać ustawienia regionalne z nagłówka AcceptLanguage), chyba że chcesz wdrożyć jakiś wymyślny proces wykrywania ustawień regionalnych (tj. Chcesz obsługiwać zmianę języka na żądanie).
Zewnętrzne ciągi znaków
Wszystkie ciągi powinny pochodzić z zasobów, czyli plików Resx. W aplikacji Winforms można to łatwo osiągnąć, ustawiając właściwość Form Localizable na true. Będziesz także musiał ręcznie (niestety) eksternalizować ciągi, które pochodzą z twoich modeli. Jest to również stosunkowo proste. W Asp.Net trzeba ręcznie wszystko uzewnętrznić ...
Układy
Zdecydowanie musisz zezwolić na rozszerzenie łańcucha. W świecie Winforms jest to możliwe dzięki TableLayoutPanel, którego należy użyć, aby upewnić się, że układ dostosuje się automatycznie, aby uwzględnić dłuższy tekst. W świecie internetowym masz trochę szczęścia. Może być konieczne wdrożenie mechanizmu lokalizacji CSS - sposobu modyfikowania (zastępowania) definicji CSS. Umożliwiłoby to pracownikom Lokalizacji modyfikowanie problemów dotyczących stylu na żądanie. Upewnij się, że każdy element HTML na renderowanej stronie ma unikalny identyfikator - pozwoli to na precyzyjne ukierunkowanie.
Problemy specyficzne dla kultury
Unikaj używania grafiki, kolorów i dźwięków, które mogą być specyficzne dla kultury zachodniej. Jeśli naprawdę tego potrzebujesz, podaj środki lokalizacji. Unikaj grafiki kierunkowej (ponieważ byłby to problem przy próbie lokalizacji w języku arabskim lub hebrajskim). Nie zakładaj też, że cały świat używa tych samych liczb (tj. Nie jest to prawda w przypadku języka arabskiego).
ToString () i Parse ()
Pamiętaj, aby zawsze przekazywać CultureInfo podczas wywoływania ToString (), chyba że nie jest ono obsługiwane. W ten sposób komentujesz swoje zamiary. Na przykład: jeśli używasz jakiegoś numeru wewnętrznie i z jakiegoś powodu musisz go przekonwertować na ciąg znaków:
int i = 42;
var s = i.ToString(CultureInfo.InvariantCulture);
W przypadku numerów, które będą wyświetlane użytkownikom:
var s = i.ToString(CultureInfo.CurrentCulture); // formatting culture used
To samo dotyczy Parse (), TryParse (), a nawet ParseExact () - niektóre nieprzyjemne błędy można wprowadzić bez właściwego użycia CultureInfo. To dlatego, że jakaś biedna dusza w Microsoft, pełna dobrych intencji, zdecydowała, że warto traktować CultureInfo.CurrentCulture jako domyślną (byłaby użyta, jeśli niczego nie przekażesz) - w końcu, gdy ktoś używa ToString ( ) chce wyświetlić go użytkownikowi, prawda? Okazało się, że nie zawsze tak jest - na przykład spróbuj zapisać numer wersji aplikacji w bazie danych, a następnie przekonwertuj go na instancję klasy Version. Powodzenia.
Daty i strefy czasowe
Pamiętaj, aby zawsze przechowywać i tworzyć DateTime w UTC (użyj DateTime.UtcNow zamiast DateTime.Now). Konwertuj go na czas lokalny w formacie lokalnym po wyświetleniu:
DateTime now = DateTime.UtcNow;
var s = now.ToLocalTime().ToString(CultureInfo.CurrentCulture);
Jeśli chcesz wysyłać wiadomości e-mail z odniesieniem do czasu w treści, pamiętaj o podaniu informacji o strefie czasowej - uwzględnij zarówno przesunięcie UTC, jak i listę miast:
DateTime someDate; // i.e. from database
var formattedDate = String.Format("{0} {1}",
someDate.ToLocaleTime().ToString(CultureInfo.CurrentCulture),
TimeZoneInfo.Local.DisplayName);
Wiadomości złożone
Zostałeś już ostrzeżony, aby nie łączyć łańcuchów. Zamiast tego prawdopodobnie użyłbyś String.Format () jak pokazano powyżej. Muszę jednak stwierdzić, że należy zminimalizować użycie wiadomości złożonych. Jest tak dlatego, że reguły gramatyki docelowej są dość często różne, więc tłumacze mogą potrzebować nie tylko zmienić kolejność zdań (byłoby to rozwiązane za pomocą symboli zastępczych i String.Format ()), ale tłumaczyć całe zdanie w inny sposób na podstawie co zostanie podstawione. Pozwól, że podam kilka przykładów:
// Multiple plural forms
English: 4 viruses found.
Polish: Znaleziono 4 wirusy. **OR** Znaleziono 5 wirusów.
// Conjugation
English: Program encountered incorrect character | Application encountered incorrect character.
Polish: Program napotkał nieznaną literę | Aplikacja napotkała nieznaną literę.
Inne problemy konkatenacji
Łączenie nie ogranicza się do łańcuchów. Unikaj układania kontroli razem, powiedz:
Przypomnij mi jeszcze raz w [polu tekstowym z liczbą] dni.
Powinno to zostać zmienione na coś w stylu: Przypomnij mi ponownie za tę liczbę dni: [pole tekstowe].
Kodowanie znaków i czcionki
Zawsze zapisuj, przesyłaj, dowolny tekst w Unicode (tj. W UTF-8). Nie koduj czcionek na stałe - Lokalizacja może wymagać ich modyfikacji, a to wyłączy domyślny mechanizm cofania czcionek (w przypadku Winforms). Pamiętaj, aby dopuścić „dziwne” znaki w większości pól (tj. Nazwa użytkownika).
Test
Prawdopodobnie będziesz musiał wdrożyć tak zwane pseudo tłumaczenie, czyli utworzyć zasoby dla powiedzmy niemieckiej kultury i skopiować swoje angielskie ciągi znaków, dodając prefiks i sufiks. Możesz także zawijać symbole zastępcze, aby łatwo wykrywać ciągi złożone. Celem pseudo tłumaczenia jest wykrycie problemów związanych z lokalizowalnością, takich jak zakodowane ciągi, problemy z układem i nadmierne użycie komunikatów złożonych.