Архітектура інтернаціоналізації Angular для справжніх ринків

Інтернаціоналізація дає продукту змогу правильно представляти різні мови, локалі, системи письма, напрями тексту, формати й правила ринків; локалізація наповнює цю здатність вмістом і пристосуванням до конкретної аудиторії. У застосунку Angular вона охоплює маршрути, відтворення сторінок, шаблони, дизайн, дані, API, кеші, аналітику, SEO, конвеєри складання й випуску, перекладачів, підтримку та відповідальність за продукт. Якщо звести все до заміни рядків, найважливіші рішення залишаться невирішеними.

Почніть із користувачів і ринків. Зафіксуйте підтримувані мови й варіанти локалей, системи письма та напрям тексту, публічні й автентифіковані сценарії, канали пошуку продукту, регуляторні та комерційні відмінності, відповідальних за вміст, ритм випусків, правила резервного вмісту, поведінку без мережі чи зі застарілим клієнтом і ціну помилкового перекладу або формату. Підтвердження фінансової операції, медична інструкція, юридична згода, рекламна сторінка й внутрішня панель потребують різних правил перевірки та випуску.

Визначте вимірюваний успіх: користувачі потрапляють на правильний URL локалі, завершують критичні сценарії без випадкового переходу на резервну мову, бачать правильні дати й суми, пошукові системи індексують передбачені варіанти, перекладачі безпечно випускають зміни, а експлуатаційна команда діагностує відмови окремої локалі. До розширення каталогу доведіть один показовий сценарій із множиною, змінними, форматуванням, перевіркою, SSR або попереднім відтворенням, аналітикою та резервною поведінкою.

Проєктуйте мови, локалі й ринки як окремі поняття

Розділяйте мову, локаль і ринок у предметній моделі. Мова визначає слова; локаль може впливати на правила множини, запис чисел і дат; ринок — на валюту, податки, доступність, ціну, юридичний текст, способи оплати, підтримку й місце зберігання даних. Ці поняття часто пов’язані, але не взаємозамінні. Франкомовні користувачі в Канаді та Франції можуть бачити спільний текст, проте потребувати різних правил торгівлі.

Обирайте локаль за явною ієрархією. Локаль в URL або профілі користувача може бути головним джерелом; збережене налаштування, правила облікового запису чи організації та мова браузера — допомагати під час першого відвідування. Географічне визначення може запропонувати варіант, але не повинно непомітно скасовувати вибір користувача чи створювати хибне враження про доступність на ринку. Нормалізуйте псевдоніми, перевіряйте підтримувані значення, визначте типову локаль і за потреби зберігайте вибір під час навігації, автентифікації та переходу між пристроями.

Проєктуйте текст з огляду на зміст і контекст. Використовуйте сталі ідентифікатори повідомлень або послідовну стратегію вихідних повідомлень, докладні описи, знімки чи відомості про місце появи та іменовані змінні. Не з’єднуйте перекладені уривки й не припускайте англійського порядку слів. Явно моделюйте форми множини, вибору чи роду, вкладене виділення, посилання й доступні підписи. Помилки бізнес-правил із сервера передавайте сталими кодами, які локалізує клієнт, а серверний текст, що підлягає аудиту або юридично закріплений, ведіть за окремими версійними правилами.

Зробіть URL локалей сталими й однозначними

Публічному локалізованому вмісту зазвичай потрібна окрема доступна для пошукових роботів адреса для кожної передбаченої локалі: префікс шляху, піддомен або національний домен. Префікси спрощують спільну репутацію домену й інфраструктуру; піддомени та національні домени можуть відповідати поділу організації чи ринків, але ускладнюють сертифікати, аналітику, розгортання й роботу з SEO. Параметри запиту чи налаштування лише на клієнті гірше підходять для тривалого публічного пошуку. Оберіть одну канонічну схему й задокументуйте причину.

Визначте поведінку типової локалі, завершальну скісну риску, регістр, псевдоніми, непідтримувані локалі, переспрямування, локалізовані частини адрес, збереження параметрів запиту, прямі посилання, шлях повернення після автентифікації та перемикання. Під час зміни локалі користувач має потрапляти на відповідну сторінку, якщо вона існує, або на явно визначений запасний варіант, а не на адресу зі сліпо заміненим сегментом. Запобігайте циклам переспрямування між визначенням мови браузера, правилами на периферії, SSR і клієнтом.

Зосередьте створення маршрутів в одному місці або зробіть його типізованим, щоб шаблони, навігація, карти сайту, канонічні позначки, посилання на мовні варіанти, аналітика й тести користувалися спільною картою локалей. Зміна локалізованої частини адреси потребує переспрямування та строку його збереження. Ключі кешу й правила CDN повинні враховувати головну локаль і доречний ринок, інакше одна аудиторія може отримати HTML або каталог іншої.

Обирайте час доставлення перекладів за експлуатаційними потребами

Локалізація під час складання створює окремий скомпільований варіант застосунку для кожної локалі. Вона забезпечує статичну перевірку, вилучення невикористаного коду з локалізованої збірки, визначені каталоги й просте локалізоване SSR або попереднє відтворення. Ціна — кілька складань і наборів файлів, узгоджений випуск програми та тексту й менш зручне миттєве перемикання мови. Цей підхід пасує продуктам, де локалі виходять разом із кодом, а правила випуску цінують незмінність.

Локалізація під час виконання завантажує або містить каталоги в працюючому застосунку. Вона дає змогу перемикати мову без повного перезавантаження, незалежно оновлювати текст, підтримувати вміст окремих клієнтів і не множити складання. Водночас з’являються завантаження й кешування каталогів, початкові та резервні стани, сумісність версій, поведінка за відсутнього ключа, цілісність та авторизація віддаленого вмісту, вплив на швидкодію клієнта й більше станів для тестування. Система керування перекладами не знімає цієї відповідальності.

Обирайте за експлуатаційними потребами: хто змінює текст, як швидко, з яким погодженням, чи потрібна робота без мережі, як працює SSR, скільки існує локалей, чи налаштовують клієнти власні терміни та яка відмова прийнятна. Змішаний підхід може вбудовувати сталий продуктовий текст і завантажувати ринковий або клієнтський вміст із версійних API. Для кожного класу повідомлень визначте одну модель відповідальності, виводьте версії каталогу й програми в телеметрії та робіть резервний перехід помітним, а не змішуйте мови непомітно.

Узгодьте SSR, гідратацію, кешування та SEO

Сервер, периферійна мережа й браузер повинні визначати ту саму локаль з одного головного джерела. Уже в першій відповіді відтворюйте правильні текст, формати, напрям, метадані та URL; передавайте це рішення для гідратації й не дозволяйте клієнту повторно визначити іншу локаль. Невідповідність під час гідратації — це не лише попередження: вона спричиняє мерехтіння, дубльовану роботу, зламану взаємодію та оманливу аналітику.

На сервері задавайте мову й напрям HTML, локалізовані назву та опис, канонічний URL, посилання на мовні варіанти, метадані соціальних мереж, структуровані дані й навігацію, якщо їх потребує публічний пошук. Кожний варіант має бути справжньою індексованою сторінкою з рівнозначним наміром. Карти сайту, переспрямування, правила robots, коди стану й локалізовані частини адрес мають узгоджуватися. Не оголошуйте локалі з неповним або автоматично змішаним критичним вмістом.

Проєктуйте кеші з урахуванням локалі та ринку. Поділ за широким заголовком мови браузера може надмірно дробити кеш і працювати непередбачувано; сталі URL локалей спрощують ключі. Не допускайте автентифікований або клієнтський вміст до публічних кешів. За кожною локаллю спостерігайте за помилками серверного відтворення, часткою влучань у кеш, часом до першого байта, збоями гідратації, відсутніми повідомленнями та індексуванням. Перевіряйте пошукових роботів і звичайних користувачів через той самий робочий шлях маршрутизації.

Форматуйте зміст, а не лише текст

Зберігайте значення бізнесу окремо від подання. Гроші потребують суми, валюти, правил округлення й обліку; локаль визначає лише відображення. Миті часу зберігайте з однозначною часовою основою, а там, де це потрібно розкладам, зберігайте також часовий пояс або календарний зміст бізнесу. Дата без часу, місцева зустріч, розрахунковий період і часова позначка є різними типами. Розбір локалізованого тексту не повинен ставати першоджерелом даних.

Користуйтеся підтримуваними даними локалей і стандартними засобами форматування чисел, валют, відсотків, одиниць, дат, часу, списків і відносних значень, окремо визначивши потрібні продукту точність та округлення. Перевіряйте нерозривні пробіли, групування, від’ємні й нульові значення, вузькі екрани, копіювання, вивантаження та допоміжні технології. Не закріплюйте в коді розташування символу, десятковий роздільник, перший день тижня, порядок адреси, будову особистого імені чи припущення про довжину тексту.

Категорії множини різняться між мовами й можуть не обмежуватися одниною та множиною. Змінним потрібні граматичний контекст і безпечне екранування. Двонапрямний вміст потребує напряму документа й компонента, логічних властивостей CSS, перевірки значків, ізоляції чисел і коду, випробування курсора та фокуса й опрацювання змішаних систем письма у вмісті користувачів. Переклад не виправить макет, чиї контейнери та взаємодія розраховані лише на коротку англійську зліва направо.

Перетворіть переклад на версійний процес розвитку продукту

Призначте відповідальних на всьому шляху від вихідного тексту до робочої системи. Власники продукту чи вмісту затверджують зміст; інженери визначають договори повідомлень і змінних; керівники локалізації відповідають за термінологію та мовну якість; перекладачі отримують контекст; юридичні чи предметні фахівці погоджують тексти з істотними наслідками; відповідальні за випуск керують відкриттям; підтримка повідомляє про нерозуміння користувачів. Зафіксуйте, хто може змінити критичне повідомлення й чи дозволено випускати текст окремо від коду.

Автоматизуйте видобування повідомлень, перевірку схеми, пошук дублів і пропусків, відповідність заповнювачів, заборонену розмітку, версійність каталогів та імпорт. Платформа перекладів може керувати завданнями, пам’яттю перекладів, словником, коментарями й перевіркою, але сховище коду та система випуску все одно повинні мати простежувану затверджену збірку. Не дозволяйте застарілим гілкам перезаписувати нові переклади, а непотрібним повідомленням — залишатися назавжди. Кожний виняток повинен мати відповідального й строк завершення.

Використовуйте псевдолокалізацію для перевірки розширення тексту, наголосів, відсутніх знаків, двонапрямного макета й неперекладених уривків. Проходьте критичні сценарії в кожній локалі запуску з показовими формами множини, валютами, датами, іменами, адресами, перевірками, помилками й дозволами. Знімки інтерфейсу корисні, але не підтверджують змісту чи доступності. Істотний текст повинен перевіряти кваліфікований фахівець у контексті на показових пристроях.

За можливості випускайте каталоги поступово. Спостерігайте за відсутніми й резервними повідомленнями, збоями завантаження, помилками JavaScript та SSR, завершенням сценаріїв, зверненнями до підтримки й результатами бізнесу в розрізі локалі та версії каталогу. Передбачте повернення до попереднього сумісного каталогу або збірки застосунку. Переклади мають залишатися сумісними з клієнтами, що можуть довше зберігатися в кеші чи бути встановленими довше за найновіший випуск.

Масштабуйте готовність до ринку, а не кількість локалей

Вихід на новий ринок є випуском цілісної продуктової можливості, а не додаванням файла перекладу. Підтвердьте право пропонувати продукт, юридичні умови, згоду, приватність і місце даних, податки й рахунки, валюту й оплату, вимоги до ідентифікації, ціноутворення, одиниці, адреси та імена, вміст, сповіщення, електронну пошту й документи, SEO, години та мову підтримки, аналітику, протидію шахрайству, експлуатацію й спілкування під час інцидентів. Явно відокремте спільне для мови від того, що змінюється за ринком.

Використовуйте матрицю готовності ринку з відповідальним, доказами, станом, залежністю, критеріями прийняття й повернення для кожного критичного сценарію. Конфігурація ринку має бути типізованою, перевіреною, придатною до аудиту й відокремленою від довільних функціональних перемикачів. Не створюйте окремі відгалуження всього застосунку. Якщо поведінка ринку справді відрізняється, ізолюйте її за правилом або можливістю з чітким власником, а не розкидайте перевірки локалі по компонентах.

Спочатку відкривайте ринок внутрішнім користувачам або обмеженій групі, перевіряйте маршрути й пошук, проходьте купівлю чи регульовані сценарії зі справжніми постачальниками та спостерігайте за розділеними результатами. Установіть цілі обслуговування для локалі й ринку, межі резервної поведінки, порядок звернення підтримки, свіжість каталогу та правила вилучення вмісту. Локаль має вимикатися або призупинятися без пошкодження спільних даних і без недоступних публічних сторінок.

Коли корисна незалежна експертиза з інтернаціоналізації

Незалежна допомога корисна, коли локалізація охоплює SSR, маршрутизацію на периферії, SEO, кілька застосунків, налаштування окремих клієнтів, підтримку письма справа наліво, регульований текст, особливу для ринку торгівлю або наявний каталог із нечіткою відповідальністю. Цільове оцінювання має дати модель локалей і ринків, рішення щодо маршрутів та відтворення, стратегію каталогів, правила повідомлень і форматування, робочий процес, карту ризиків, показову реалізацію, матрицю тестів, послідовність випуску, критерії прийняття, відновлення й передавання знань.

Оцінюйте досвід за доказами з умов, наближених до робочих: локалізованими SSR та гідратацією, канонічним і альтернативним виведенням, поділом кешу, формами множини й двонапрямною поведінкою, договорами помилок серверної частини, автоматизацією перекладу, псевдолокалізацією, доступністю, версійністю каталогів, поділом аналітики та виходом на ринок. Внутрішні відповідальні за продукт, інженерію, вміст, право, локалізацію й підтримку мають брати участь, щоб інтернаціоналізація стала спроможністю організації, а не постійним знанням підрядника.

• Моделюйте мову, локаль і ринок: визначте головне джерело вибору, налаштування користувача, резервні варіанти, контекст повідомлень, відповідальність за вміст і незалежно змінювану поведінку бізнесу.
• Забезпечте сталі URL локалей: узгодьте переспрямування, перемикання, прямі посилання, локалізовані частини адрес, канонічні й альтернативні посилання, карти сайту, аналітику та ключі кешу в одній політиці маршрутів.
• Обирайте доставлення каталогів за потребами експлуатації: порівняйте незмінність під час складання з гнучкістю під час виконання за керуванням випуском, перемиканням, SSR, кешуванням, роботою без мережі, версійністю, швидкодією та відмовами.
• Узгодьте відтворення та пошук: сервер, периферійна мережа, браузер, кеш, метадані, канонічні й альтернативні сторінки, карти сайту та гідратація повинні однаково визначати локаль і ринок.
• Зберігайте зміст даних: відокремлюйте значення бізнесу від подання, використовуйте підтримувані дані локалей, явно моделюйте час і гроші та перевіряйте множину, розширення тексту, доступність і двонапрямний вміст.
• Керуйте перекладом як продуктовою зміною: призначте відповідальних за зміст, мову, право, інженерію, випуск і підтримку; автоматизуйте контроль каталогів; перевіряйте в контексті; випускайте й спостерігайте за версіями.