Tôi nên thực hiện nội địa hóa (phía máy chủ hoặc phía máy khách) ở đâu?

Tôi hiện đang phát triển một ứng dụng web mới dựa trên ứng dụng khách JavaScript phong phú, giao tiếp với nhiều dịch vụ web REST trên máy chủ của tôi. Ứng dụng đó dự định sẽ được sử dụng ở ít nhất hai quốc gia với các ngôn ngữ khác nhau, vì vậy chúng tôi cần bản địa hóa nó.

Câu hỏi của tôi là tôi nên quản lý bản địa hóa ở đâu: các dịch vụ REST có nên nhận yêu cầu và gửi câu trả lời với dữ liệu được bản địa hóa hay khách hàng nên nhận và gửi dữ liệu chung và sau đó chịu trách nhiệm thực hiện bản địa hóa?

API REST của bạn sẽ dễ sử dụng hơn bởi những người khác nếu bạn cung cấp ID chuỗi thay vì chuỗi dịch. Sử dụng API trả về "E_NOT_AUTHORIZED"đơn giản hơn so với việc trả về một số ngôn ngữ của con người và thậm chí cả chuỗi được bản địa hóa.

Ngoài ra, bạn có thể muốn thay đổi các chuỗi được bản địa hóa trong các phiên bản trong tương lai, đây sẽ là một thay đổi API phá vỡ. Với cách tiếp cận ID chuỗi, bạn vẫn quay lại "E_NOT_AUTHORIZED", giữ cho API của bạn tương thích.

Nếu bạn sử dụng một khung như Angular.js , có thể dễ dàng thực hiện chuyển đổi ngôn ngữ nóng nếu bạn sử dụng phương pháp tiếp cận chuỗi ID. Bạn chỉ cần tải một chuỗi ký tự khác và tất cả các chuỗi tự động thay đổi ngôn ngữ của chúng vì bạn chỉ sử dụng một số logic bộ lọc trong các mẫu của mình, như thế {{errorStringID | loc}}.

Một cân nhắc khác: Để giảm tải máy chủ của bạn, hãy giữ back-end của bạn đơn giản nhất có thể. Bạn sẽ có thể phục vụ nhiều khách hàng hơn với cùng số lượng máy chủ. Cung cấp chuỗi ký tự của bạn thông qua CDN và thực hiện bản địa hóa ở mặt trước.

Có khách hàng gửi tiêu Accept-Languageđề được tiêu chuẩn hóa trong các yêu cầu, sau đó bản địa hóa trên máy chủ và bao gồm một Content-Languagetiêu đề trong các phản hồi. Xem RFC 7231 Mục 5.3.5 để biết chi tiết.

Việc bản địa hóa ở phía máy chủ dẫn đến các chuyến đi khứ hồi và tiêu thụ băng thông ít hơn so với việc gửi siêu dữ liệu bản địa hóa của máy khách. Nhưng một máy chủ không thể giả sử ngôn ngữ nào khách hàng muốn, bởi vì nếu khách hàng đó là proxy phục vụ cho người khác thì sao? Điều gì xảy ra nếu có một lớp bộ đệm giữa máy khách và máy chủ? Làm thế nào một máy chủ được cho là "chỉ ra" ngôn ngữ nào nên được sử dụng cho một số yêu cầu tùy ý?

Cố gắng trả lời những câu hỏi đó rất phức tạp, vì vậy thay vào đó, yêu cầu các yêu cầu phải tự mô tả và sử dụng tiêu đề tiêu chuẩn để khách hàng có thể thương lượng ngôn ngữ họ muốn. Đó gọi là đàm phán nội dung. Các Accept-Languagetiêu đề là một hình thức chủ động đàm phán nội dung mà một khách hàng nói với một máy chủ gì sở thích của nó là, thì máy chủ sẽ quyết định những gì để đáp ứng với dựa trên những sở thích. Đàm phán nội dung phản ứng là nơi khách hàng gửi yêu cầu hỏi máy chủ về loại nội dung nào, thường nhận được phản hồi có chứa danh sách các liên kết và sau đó chọn liên kết nào muốn chọn bằng cách chọn liên kết để theo dõi.

Tôi sẽ nói càng nhiều càng tốt về phía máy chủ nếu bạn sẽ hỗ trợ nhiều thiết bị.

Mỗi thiết bị tất nhiên sẽ sử dụng một số bản dịch riêng nhưng nội dung được chia sẻ dưới dạng thông báo lỗi từ api, v.v. sẽ giống nhau bất kể thiết bị.

Đó là một câu hỏi về sở thích cá nhân, nhưng nếu bạn làm việc phía khách hàng, bạn sẽ tiết kiệm được tải máy chủ (giả sử từ điển tĩnh hoặc được lưu trong bộ nhớ cache) và có thể sử dụng các công cụ bất khả tri ngôn ngữ để kiểm tra dịch vụ.