В даний час я розробляю новий веб-додаток на основі багатого клієнта JavaScript, який спілкується з декількома веб-сервісами REST на моєму сервері. Ця програма призначена для використання щонайменше у двох країнах з різними мовами, тому нам потрібно її локалізувати.
Моє запитання: де я повинен керувати локалізацією: чи повинні служби REST отримувати запит та надсилати відповіді з локалізованими даними, чи повинен клієнт отримувати та надсилати загальні дані, а потім відповідати за локалізацію?
Відповіді:
Ваш REST API буде простішим у використанні іншими, якщо ви надасте ідентифікатори рядків замість перекладених рядків. Використання API, який повертається, "E_NOT_AUTHORIZED"є більш простим, ніж якщо він повертає якусь людську мову та навіть локалізовану рядок.
Крім того, можливо, ви захочете змінити локалізовані рядки в майбутніх версіях, що було б переломним зміною API. При підході до рядкового ідентифікатора ви все одно повертаєтесь "E_NOT_AUTHORIZED", зберігаючи API сумісним.
Якщо ви використовуєте такий фреймворк, як Angular.js , реалізувати мовну гарячу комутацію легко, якщо використовувати підхід з ідентифікатором рядка. Ви просто завантажуєте інший рядковий рядок, і всі рядки автоматично змінюють мову, тому що ви просто використовуєте певну логіку фільтру у своїх шаблонах, наприклад {{errorStringID | loc}}.
Ще одне врахування: щоб зменшити навантаження сервера, тримайте його якнайпростіше. Ви зможете обслуговувати більше клієнтів з однаковою кількістю серверів. Доставте свої рядки через CDN та виконайте локалізацію в передній частині.
Запропонуйте клієнтам надіслати стандартизований Accept-Languageзаголовок у запитах, а потім локалізувати їх на сервері та включити Content-Languageзаголовок у відповіді. Докладніше див. У розділі 5.3.5 RFC 7231 .
Локалізація на стороні сервера призводить до меншої кількості туристів і споживання пропускної здатності, ніж надсилання метаданих локалізації клієнтів. Але сервер не може припустити, яку мову хоче клієнт, бо що робити, якщо цей клієнт є проксі-сервісом, який обслуговує його комусь іншому? Що робити, якщо між клієнтом і сервером є шар кешування? Як сервер повинен "просто розібратися", якою мовою слід користуватися для будь-якого довільного запиту?
Спроба відповісти на ці запитання є складною, тому натомість вимагайте, щоб запити були самостійно описовими та використовували стандартний заголовок, щоб клієнти могли домовитись, якою мовою вони бажають. Це називається зміст переговорів. Accept-LanguageТема є формою активного контенту переговорів , коли клієнт говорить сервер , що це перевагу, то сервер вирішує , що відповісти на основі цих переваг. Реактивне узгодження контенту - це коли клієнт надсилає запит, запитуючи сервер, які типи вмісту є, як правило, отримує відповідь, що містить перелік посилань, а потім вибирає, який саме він буде бажати, вибравши посилання, яке слід перейти.
Я б сказав якомога більше на стороні сервера, якщо ви збираєтесь підтримувати кілька пристроїв.
Кожен пристрій, звичайно, буде використовувати деякі переклади самостійно, але спільні речі, оскільки повідомлення про помилки з api тощо будуть однаковими незалежно від пристроїв.