현지화 (서버 측 또는 클라이언트 측)는 어디에서해야합니까?

현재 서버의 여러 REST 웹 서비스와 통신하는 풍부한 JavaScript 클라이언트를 기반으로 새 웹 응용 프로그램을 개발 중입니다. 이 응용 프로그램은 언어가 다른 두 개 이상의 국가에서 사용하도록되어 있으므로 현지화해야합니다.

내 질문은 현지화를 어디에서 관리해야 하는가입니다. REST 서비스는 현지화 된 데이터로 요청을 받아서 응답을 보내야합니까, 아니면 클라이언트가 일반 데이터를 받아서 보내서 현지화를 수행해야합니까?

변환 된 문자열 대신 문자열 ID를 제공하면 다른 사용자가 REST API를 더 쉽게 사용할 수 있습니다. 반환하는 API를 사용하면 "E_NOT_AUTHORIZED"일부 언어 및 현지화 된 문자열을 반환하는 것보다 더 간단합니다.

또한, 향후 버전에서 현지화 된 문자열을 변경하려고 할 수 있으며 이는 API 변경에 영향을 줄 수 있습니다. 문자열 ID 접근 방식을 사용하면 "E_NOT_AUTHORIZED"API 호환성을 유지하면서 여전히을 반환 합니다.

Angular.js 와 같은 프레임 워크를 사용하는 경우 문자열 ID 접근 방식을 사용하면 언어 핫 전환을 쉽게 구현할 수 있습니다. 다른 문자열 테이블을로드하면 템플릿과 같은 필터 논리를 사용하기 때문에 모든 문자열이 자동으로 언어를 변경합니다 {{errorStringID | loc}}.

다른 고려 사항 : 서버로드를 줄이려면 백엔드를 가능한 단순하게 유지하십시오. 동일한 수의 서버로 더 많은 클라이언트를 지원할 수 있습니다. CDN을 통해 문자열 테이블을 제공하고 프론트 엔드에서 현지화를 수행하십시오.

클라이언트가 요청에서 표준화 된 Accept-Language헤더를 보낸 다음 서버에서 현지화 Content-Language하고 응답에 헤더를 포함 시킵니다. 자세한 내용은 RFC 7231 섹션 5.3.5 를 참조하십시오.

서버 측에서 지역화하면 클라이언트 지역화 메타 데이터를 보내는 것보다 왕복 및 대역폭 소비가 줄어 듭니다. 그러나 서버는 클라이언트가 원하는 언어를 추측 할 수 없습니다. 클라이언트가 다른 사람에게 서비스를 제공하는 프록시라면 어떨까요? 클라이언트와 서버 사이에 캐싱 계층이 있으면 어떻게합니까? 서버는 어떤 임의의 요청에 어떤 언어를 사용해야하는지 "어떻게 파악해야"하는가?

이러한 질문에 대답하는 것은 복잡하기 때문에 대신 요청 에 대한 설명이 필요 하고 표준 헤더를 사용해야 클라이언트가 원하는 언어를 협상 할 수 있습니다. 이를 컨텐츠 협상이라고합니다. Accept-Language헤더의 한 형태 사전 클라이언트가 그것의 기본이 무엇인지 서버를 지시 내용 협상, 서버는 그 기본 설정에 따라 응답에 무엇을 결정한다. 사후 컨텐츠 협상은 클라이언트가 서버에 어떤 종류의 컨텐츠가 있는지 묻는 요청을 보내고, 일반적으로 링크 목록이 포함 된 응답을 수신 한 다음 수행 할 링크를 선택하여 원하는 것을 선택하는 곳입니다.

여러 장치를 지원하려는 경우 서버 측에서 가능한 한 많이 말하고 싶습니다.

각 장치는 물론 일부 번역을 자체적으로 사용하지만 API 등의 오류 메시지는 장치에 관계없이 동일하므로 공유됩니다.

개인적인 취향에 대한 문제이지만 클라이언트 측에서 작업을 수행하면 정적 또는 캐시 된 사전을 가정하여 서버로드를 줄이고 서비스를 테스트하기 위해 언어에 구애받지 않는 도구를 사용할 수 있습니다.