Gdzie powinienem przeprowadzić lokalizację (po stronie serwera lub po stronie klienta)?

Obecnie opracowuję nową aplikację internetową opartą na bogatym kliencie JavaScript, który komunikuje się z wieloma usługami internetowymi REST na moim serwerze. Ta aplikacja jest przeznaczona do użytku w co najmniej dwóch krajach z różnymi językami, dlatego musimy ją zlokalizować.

Moje pytanie brzmi: gdzie mam zarządzać lokalizacją: czy usługi REST powinny odbierać żądania i wysyłać odpowiedzi ze zlokalizowanymi danymi, czy też klient powinien otrzymywać i wysyłać dane ogólne, a następnie być odpowiedzialny za lokalizację?

Twój interfejs API REST będzie łatwiejszy w użyciu dla innych, jeśli podasz identyfikatory ciągów zamiast przetłumaczonych ciągów. Korzystanie z interfejsu API, który zwraca, "E_NOT_AUTHORIZED"jest prostsze niż w przypadku zwracania jakiegoś języka ludzkiego, a nawet zlokalizowanego ciągu.

Możesz także chcieć zmienić zlokalizowane ciągi w przyszłych wersjach, co byłoby przełomową zmianą interfejsu API. Dzięki metodzie ciąg znaków nadal powracasz "E_NOT_AUTHORIZED", utrzymując kompatybilność interfejsu API.

Jeśli używasz frameworka, takiego jak Angular.js , łatwo jest zaimplementować przełączanie języka na gorąco, jeśli zastosujesz metodę ciągów znaków. Po prostu ładujesz kolejną tablicę napisów, a wszystkie napisy automatycznie zmieniają język, ponieważ po prostu używasz logiki filtrowania w swoich szablonach, takich jak {{errorStringID | loc}}.

Kolejna uwaga: Aby zmniejszyć obciążenie serwera, zachowaj zaplecze tak proste, jak to możliwe. Będziesz mógł obsługiwać więcej klientów z tą samą liczbą serwerów. Dostarcz swoje tabele ciągów za pośrednictwem CDN i przeprowadź lokalizację w interfejsie.

Poproś klientów o przesłanie znormalizowanego Accept-Languagenagłówka w żądaniach, a następnie zlokalizuj go na serwerze i dołącz Content-Languagenagłówek w odpowiedziach. Aby uzyskać szczegółowe informacje, patrz RFC 7231 sekcja 5.3.5 .

Lokalizacja po stronie serwera skutkuje mniejszą liczbą podróży w obie strony i zużyciem przepustowości niż wysyłanie metadanych lokalizacji klientów. Ale serwer nie może założyć, jakiego języka chce klient, ponieważ co, jeśli ten klient jest serwerem proxy obsługującym go dla kogoś innego? Co się stanie, jeśli między klientem a serwerem znajduje się warstwa buforująca? W jaki sposób serwer powinien „po prostu dowiedzieć się”, jakiego języka należy użyć w przypadku dowolnego dowolnego żądania?

Próba odpowiedzi na te pytania jest skomplikowana, dlatego zamiast tego wymagają, aby żądania były opisowe i używały standardowego nagłówka, aby klienci mogli negocjować w jakim języku chcą. To się nazywa negocjowanie treści. Accept-LanguageNagłówek jest formą aktywnego negocjacji zawartości, gdy klient mówi serwer co to preferencje, to serwer zdecyduje, co odpowiedzieć na podstawie tych preferencji. Negocjacja treści reaktywnych polega na tym, że klient wysyła zapytanie z zapytaniem do serwera, jakie to są treści, zazwyczaj otrzymuje odpowiedź zawierającą listę linków, a następnie wybiera, którą z nich chce, wybierając link do naśladowania.

Powiedziałbym jak najwięcej po stronie serwera, jeśli zamierzasz obsługiwać wiele urządzeń.

Każde urządzenie będzie oczywiście korzystać z niektórych tłumaczeń samodzielnie, ale udostępnianych rzeczy, ponieważ komunikaty o błędach z interfejsu API itp. Będą takie same niezależnie od urządzeń.

To w dużej mierze kwestia osobistego gustu, ale jeśli robisz rzeczy po stronie klienta, zaoszczędzisz na obciążeniu serwera (zakładając statyczne lub buforowane słowniki) i możesz użyć narzędzi niezależnych od języka do testowania usługi.