Задайте питання та отримайте підсумок документа, вказавши цю сторінку та обраного вами постачальника штучного інтелекту
Вміст цієї сторінки перекладено за допомогою штучного інтелекту.
Переглянути останню версію оригінального вмісту англійськоюЯкщо у вас є ідея щодо покращення цієї документації, будь ласка, долучіться, надіславши pull request на GitHub.
Посилання на документацію на GitHubСкопіювати документацію у форматі Markdown в буфер обміну
Історія інтернаціоналізації в JavaScript (i18n)
Інтернаціоналізація з'явилася задовго до вебу та JavaScript. Програмне забезпечення здавна мало підтримувати різні мови, валюти, формати дат і регіональні стандарти. Ранні графічні операційні системи, такі як GEM і Mac OS, успішно розв'язували багато з цих питань ще у 1980-х роках.
Ці самі принципи згодом перейшли до бекенд-фреймворків. Ruby on Rails, Django, екосистема Java та додатки на PHP розробили власні підходи до інтернаціоналізації. Базові завдання були чітко окреслені:
- Де зберігати файли перекладів?
- Як форматувати дати, числа та валюти?
- Як враховувати форми множини та граматичні особливості?
- Як обирати мову для користувача?
Поки сервер рендерив сторінки повністю, підхід залишався простим. Сервер завантажував потрібні тексти, формував HTML і відправляв результат у браузер.
PHP та GNU gettext стали попередниками функції-помічника t(), яка пізніше стала всюдисущим стандартом у світі JavaScript та JSX.
Потім JavaScript почав домінувати у браузері.
З переходом від серверних сторінок до дедалі складніших Single-Page Applications (SPA) інтернаціоналізація стала завданням фронтенду. Браузер мав динамічно підвантажувати переклади, перемикати мови, форматувати значення, обробляти форми множини й оновлювати інтерфейс без перезавантаження сторінки.
У результаті постало ключове питання:
Як створити багатомовний застосунок, не завантажуючи кожному користувачеві гігантські обсяги перекладів та важкий рантайм-код?
Це питання визначало розвиток i18n у JavaScript понад десять років.
Підходи змінювалися кардинально: від глобальних об'єктів і викликів t('key') до спеціалізованих бібліотек під конкретні фреймворки, компіляційної екстракції, генерації типів у TypeScript, Server Components, tree-shaking і сучасних компіляторних рішень, що перетворюють контент на оптимізований JavaScript ще на етапі збірки.
У цій статті проаналізовано цю еволюцію з 2011 по 2026 рік: завдання кожного покоління інструментів, їхні сильні та слабкі сторони, а також вплив архітектури фронтенду на сучасні підходи до i18n.
Зміст
Ранній веб: інтернаціоналізація JavaScript до 2016 року
Щоб зрозуміти сучасні рішення i18n, корисно згадати реалії веброзробки у період між 2011 та 2015 роками.
Перенесення логіки на бік клієнта
На початку 2010-х років інтернаціоналізація залишалася переважно обов'язком сервера. JavaScript виконував роль допоміжного шару для анімацій, перевірки форм і невеликих віджетів через jQuery.
З поширенням SPA на базі Backbone.js, Knockout.js і раннього AngularJS логіка рендерингу перейшла у браузер. Клієнтський код мав відображати локалізовані дати, форматувати валюти, обробляти множину й змінювати текст без повного перезавантаження.
Проте браузерне середовище 2011 року не було до цього пристосоване:
Специфікація ECMAScript Internationalization API (ECMA-402) була фіналізована лише у грудні 2012 року з появою глобального об'єкта Intl. До її широкого впровадження навіть просте форматування дат вимагало власних функцій або масивних поліфілів.
Інструменти на кшталт Webpack робили перші кроки, а нативних ES-модулів у браузерах не було. Розробники підключали скрипти через теги <script>, нерідко зберігаючи словники в глобальних змінних на зразок window.translations = { ... }.
Переклади складалися у великі централізовані файли JSON. Користувач у Токіо, відкриваючи головну сторінку, завантажував також тексти для налаштувань акаунта, білінгу та адміністративних розділів.
Перша хвиля клієнтських бібліотек
Між 2012 та 2015 роками було закладено фундамент сучасної клієнтської i18n:
Створена Яном Мюлеманом (Jan Mühlemann), i18next задала стандарт для словників ключ-значення під час виконання. Вона запровадила навігацію за ключами, інтерполяцію змінних, правила множини й модульну архітектуру для розпізнавання мови та бекендів. Бібліотека швидко стала стандартом для чистого JS та раннього Node.js.
Створена Кадзуєю Кавагуті (Kazupon), vue-i18n адаптувала інтернаціоналізацію під реактивну модель Vue.js, запропонувавши шаблонні директиви (v-t) та допоміжну функцію $t().
Створена в Yahoo! у рамках проєкту FormatJS, react-intl перенесла стандарт ICU MessageFormat і браузерні API Intl у React через декларативні компоненти (<FormattedMessage>, <FormattedDate>).
Ян Мюлеман адаптував i18next для спільноти React за допомогою Higher-Order Components (withTranslation) і провайдерів контексту для повторного рендерингу під час зміни мови.
Обмеження епохи до 2016 року
Хоча ці інструменти зробили можливими багатомовні клієнтські застосунки, технічні обмеження створювали постійні проблеми:
Пошук через рядки на кшталт t('marketing.landing.hero.cta') не мав статичної перевірки. Помилка у написанні виявлялася лише в роботі програми, спричиняючи порожні блоки або показ неперекладених ключів.
Аналіз синтаксису ICU й регулярні вирази для підстановки змінних споживали процесорний ресурс, особливо на мобільних пристроях.
Без поділу коду за маршрутами чи компонентами всі рядки завантажувалися разом, погіршуючи час першого завантаження.
Словники зберігалися окремо від компонентів, через що з'являлися непотрібні застарілі ключі та пропущені переклади.
Епоха фреймворків: еволюція за екосистемами
Між 2016 та 2026 роками архітектура фронтенду зазнала помітних змін. TypeScript став галузевим стандартом, компоненти дозріли, бандлери Webpack, Vite та Turbopack запровадили поділ коду, React Server Components повернули частину рендерингу на сервер, а компілятори почали аналізувати безпосередньо код застосунку.
Нижче показано, як кожна екосистема відповідала на ці виклики. У цих середовищах react-intlayer та його версії для інших фреймворків (next-intlayer, vue-intlayer, angular-intlayer, svelte-intlayer та solid-intlayer) пропонують оптимізовані рішення, створені під специфіку кожного середовища.
Відкрийте таблицю в модальному вікні, щоб чітко переглянути всі дані
| Перший реліз | Бібліотека | Мета створення | Ключова інновація |
|---|---|---|---|
| Січень 2012 | i18next | Стандартизація словникового пошуку під час виконання для браузера та Node.js без прив'язки до фреймворку. | Модульна архітектура, що відокремлює логіку перекладу від завантажувачів, модулів визначення мови та кешування. |
| Лютий 2021 | typesafe-i18n | Уникнення прихованих помилок під час виконання та неправильної інтерполяції через нетипізовані рядкові ключі. | Повністю типізовані функції перекладу, що генеруються безпосередньо з об'єктів локалізації без рантайм-залежностей. |
| Жовтень 2023 | paraglide (@inlang/paraglide-js) | Усунення пошуку за словниками під час виконання, важких парсерів і зайвого коду в бандлі. | Компіляція повідомлень у чисті ECMAScript-модулі та функції з підтримкою tree-shaking. |
| Квітень 2024 | intlayer | Заміна складних просторів імен, усунення витоку контенту між сторінками, зменшення конфліктів у git та сувора типізація в TypeScript. | Розміщення файлів .content поруч із компонентами, автоматична генерація типів TypeScript, інтегрована візуальна CMS та інструменти перекладу через CLI. |
| Червень 2025 | wuchale | Позбавлення від ручного вилучення рядків і вигадування ключів перекладу під час розробки. | Препроцесор рівня AST, який розпізнає вбудований текст і компілює його у локалізовані функції під час збірки. |
Відкрийте таблицю в модальному вікні, щоб чітко переглянути всі дані
| Перший реліз | Бібліотека | Мета створення | Ключова інновація |
|---|---|---|---|
| Червень 2014 | react-intl | Стандартизація форматування чисел, дат, валют і складних форм множини в React. | Декларативні компоненти (<FormattedMessage>, <FormattedDate>) на базі ICU MessageFormat та стандарту ECMA-402. |
| Грудень 2015 | react-i18next | Зручна інтеграція i18next у React з реактивним оновленням інтерфейсу. | Розвиток разом із React: перехід від Higher-Order Components до інтерполяції JSX через <Trans> і хука useTranslation. |
| Січень 2018 | @lingui/react | Зменшення розміру бандла завдяки уникненню складних ICU-парсерів у браузері. | Макроси Babel/SWC, які компілюють <Trans> і t у компактні індексовані масиви під час збірки. |
| Грудень 2020 | use-intl | Легковажна альтернатива старим бібліотекам з орієнтацією на хуки та типізацію для React. | Зручні хуки useTranslations та useFormatter із глибокою інтеграцією в TypeScript. |
| Лютий 2021 | @tolgee/react | Прискорення комунікації між розробниками, перекладачами та дизайнерами. | Редагування текстів у контексті браузера за Alt-кліком зі збереженням та створенням скріншотів на льоту. |
| Квітень 2024 | react-intlayer | Швидке рішення для життєвого циклу React без централізованих JSON-монолітів та громіздких просторів імен. | Хук useIntlayer під рендеринг React, автогенерація типів TypeScript, tree-shaking для кожного компонента та пряма синхронізація з візуальною CMS. |
| Липень 2024 | gt-react | Автоматизація ручного експорту файлів і підтримки перекладів. | Автоматична локалізація за допомогою ШІ безпосередньо в компонентах React через хмарні процеси. |
| Серпень 2025 | @wuchale/jsx | Відмова від ручного створення ключів і повторюваних хуків у JSX. | AST-трансформація, що виділяє текстові вузли JSX і компілює їх у локалізовані аналоги. |
Відкрийте таблицю в модальному вікні, щоб чітко переглянути всі дані
| Перший реліз | Бібліотека | Мета створення | Ключова інновація |
|---|---|---|---|
| Листопад 2018 | next-i18next | Підтримка SSR та SSG з i18next у Next.js Pages Router без каскадних запитів на клієнті. | Функції serverSideTranslations та appWithTranslation для передачі локалізованих даних через пропси сторінок. |
| Грудень 2019 | next-translate | Спрощення конфігурації та оптимізація розміру бандла у додатках Pages Router. | Плагін для завантажувача Webpack, що додає на кожну сторінку лише потрібні простори імен перекладу. |
| Листопад 2020 | next-intl | Переосмислення інтернаціоналізації для App Router, React Server Components (RSC) та потокового SSR. | Нативна інтеграція з middleware, Server Actions та асинхронними Server Components без необхідності передавати клієнтський JS. |
| Липень 2022 | next-international | Максимальна безпека типів TypeScript із мінімальним впливом на клієнтський код у Next.js. | Сувора генерація типів для обмежених ключів із легкими адаптерами для App Router і Pages Router. |
| Квітень 2024 | paraglide-next (@inlang/paraglide-next) | Скомпільовані повідомлення без додаткового рантайму для App Router та Pages Router у Next.js. | Маршрутизація на middleware разом із функціями повідомлень, що виключають аналіз JSON у рантаймі RSC та клієнтських бандлах. |
| Квітень 2024 | next-intlayer | Адаптер для Server Components без потреби передавати функції t() чи словники через пропси між компонентами. | Прямий виклик useIntlayer у синхронних Server Components без prop-drilling, рендеринг без затримок на сервері, локалізований middleware і синхронізація з CMS. |
| Вересень 2024 | gt-next | Автоматизація створення багатомовного вмісту та динамічної маршрутизації в Next.js за допомогою ШІ. | Інтеграція з App Router, яка поєднує машинний переклад у хмарі з edge-middleware та кешуванням Next.js. |
Відкрийте таблицю в модальному вікні, щоб чітко переглянути всі дані
| Перший реліз | Бібліотека | Мета створення | Ключова інновація |
|---|---|---|---|
| Травень 2014 | vue-i18n | Зручна реактивна інтернаціоналізація для застосунків на Vue.js. | Глибока інтеграція з реактивністю Vue, директиви шаблонів (v-t), помічники $t та блоки <i18n> в однофайлових компонентах (SFC). |
| Листопад 2017 | @nuxt/i18n | Маршрутизація локалізованих URL, теги SEO hreflang і гідратація SSR у Nuxt. | Повноцінний модуль маршрутизації, який створює шляхи (префікси, домени), мета-теги та забезпечує ліниве завантаження фрагментів перекладу. |
| Серпень 2019 | fluent-vue | Підтримка складного граматичного роду, відмінків і несиметричних структур у Vue. | Інтеграція синтаксису Project Fluent від Mozilla, що усуває потребу у розгалужених умовних конструкціях для мовних нюансів. |
| Квітень 2025 | vue-intlayer | Рішення на базі Intlayer для Composition API у Vue 3 та Nuxt без засмічення глобальної області видимості. | Композабл useIntlayer з урахуванням реактивності Vue 3, ізоляція на рівні компонентів, повне автодоповнення TypeScript та підтримка візуального редактора. |
Відкрийте таблицю в модальному вікні, щоб чітко переглянути всі дані
| Перший реліз | Бібліотека | Мета створення | Ключова інновація |
|---|---|---|---|
| Лютий 2017 | ngx-translate | Динамічний переклад під час виконання в Angular без створення окремих збірок для кожної мови. | Сервіс TranslateService та пайп translate для динамічного завантаження текстів і перемикання мов на льоту. |
| Липень 2019 | @ngneat/transloco | Усунення обмежень продуктивності та відсутності ізоляції у старіших інструментах Angular. | Структурна директива (*transloco), ізольовані переклади для лінивих модулів, підтримка SSR і CLI для вилучення текстів. |
| Вересень 2019 | @angular/localize | Модернізація вбудованої системи i18n в Angular без повної перекомпіляції TypeScript для кожної мови. | Теговані шаблонні літерали з $localize, які обробляються як швидкий крок після збірки в компіляторі Ivy. |
| Лютий 2021 | @tolgee/ngx | Спільний переклад у контексті інтерфейсу та збереження знімків екрана в робочих процесах Angular. | Пайпи та директиви з підключенням до Tolgee для зміни тексту безпосередньо у вікні браузера. |
| Квітень 2025 | angular-intlayer | Нативна інтеграція Intlayer для сучасного Angular (Signals, standalone-компоненти та SSR). | Реактивна інтеграція на базі Signals для механізму Change Detection в Angular, робота зі standalone-компонентами та миттєва синхронізація з візуальною CMS. |
Відкрийте таблицю в модальному вікні, щоб чітко переглянути всі дані
| Перший реліз | Бібліотека | Мета створення | Ключова інновація |
|---|---|---|---|
| Липень 2018 | svelte-i18n | Реактивна бібліотека інтернаціоналізації на основі сховищ (stores) Svelte. | Пошук через $t на базі сховищ, що гарантує точне оновлення DOM у разі зміни мови. |
| Грудень 2021 | sveltekit-i18n | Коректна обробка SSR і завантаження перекладів за маршрутами у додатках SvelteKit. | Модульна архітектура завантажувача, що отримує лише ті рядки та форматери, які потрібні для активного маршруту. |
| Листопад 2021 | @tolgee/svelte | Переклад у контексті інтерфейсу для застосунків на Svelte. | Зв'язування зі сховищами Svelte з інтеграцією в оверлей Tolgee та автоматичним створенням скріншотів. |
| Квітень 2025 | svelte-intlayer | Швидке рішення Intlayer, розроблене безпосередньо для Svelte 5 та SvelteKit. | Реактивні зв'язки для рун Svelte 5 ($state), файли .content поруч із компонентами, збірка без конфігурації та візуальний редактор. |
| Липень 2025 | @wuchale/svelte | Усунення рутини з оголошення словників та імпорту функцій $t у компонентах Svelte. | Препроцесор Svelte, що аналізує шаблони під час збірки та компілює текстові вузли у локалізований вивід без додаткових обгорток. |
Відкрийте таблицю в модальному вікні, щоб чітко переглянути всі дані
| Перший реліз | Бібліотека | Мета створення | Ключова інновація |
|---|---|---|---|
| Вересень 2021 | @solid-primitives/i18n | Примітив i18n, що відповідає гранулярній реактивності SolidJS. | Реактивний резолвер перекладів на сигналах, який оновлює вузли DOM без Virtual DOM і зайвих повторних рендерів. |
| Квітень 2025 | solid-intlayer | Продуктивне рішення Intlayer, створене спеціально для SolidJS та SolidStart. | Прив'язка до сигналів Solid без накладних витрат Virtual DOM, повна автопідстановка схем TypeScript та інтеграція з візуальним редактором. |
| Червень 2026 | @lingui/solid | Екстракція через макроси під час збірки та підтримка ICU MessageFormat у SolidJS. | Макротрансформації, адаптовані до сигналів Solid, що перетворюють повідомлення на компактні структури для виконання. |
Чотири архітектурні епохи JavaScript i18n
Аналізуючи п'ятнадцять років розвитку, історію інтернаціоналізації в JavaScript можна розділити на чотири ключові періоди:
Представлена i18next, react-intl та vue-i18n. Застосунки завантажували статичні каталоги JSON повністю в пам'ять, а функції під час виконання зіставляли текстові ключі у вкладених об'єктах. Форми множини та підстановка змінних обчислювалися у браузері через регулярні вирази та клієнтські парсери ICU.
Представлена lingui, next-translate, transloco та typesafe-i18n. Розробники звернули увагу на втрати продуктивності через парсинг під час виконання та нестабільність нетипізованих ключів. Макроси Babel вилучали фрази на етапі збірки, плагіни бандлерів розділяли словники за сторінками, а компілятор TypeScript почав перевіряти параметри перекладів.
Окреслена next-intl, next-international та першими адаптерами для RSC. З появою React Server Components та Next.js App Router головною метою стало рендерити локалізований контент на сервері без відправлення зайвих словників або важких бібліотек i18n у браузер.
Представлена paraglide, intlayer та wuchale. Сучасні інструменти розглядають інтернаціоналізацію як цілісну архітектуру контенту, а не звичайну підстановку рядків. Компілятори перетворюють повідомлення на оптимізований код із підтримкою tree-shaking, оголошення розташовуються поруч із компонентами, а візуальні редактори та процеси зі штучним інтелектом інтегруються безпосередньо в розробку. У цій моделі Intlayer відділяє опис контенту та генерацію типів від рантайму, надаючи спеціалізовані рішення (react-intlayer, next-intlayer, vue-intlayer, angular-intlayer, svelte-intlayer та solid-intlayer) під особливості кожного фреймворку.
Висновок: баланс між зручністю розробки, продуктивністю та розвитком ШІ
За п'ятнадцять років і чотири технологічні хвилі фундаментальне завдання JavaScript i18n залишилося незмінним: забезпечити зручність розробки (DX) та надійність кодової бази, гарантуючи водночас найвищу швидкість для користувача.
Те, що починалося з глобальних змінних і неповоротких JSON-файлів, еволюціонувало у контент поруч із компонентами, автоматичну типізацію TypeScript, рендеринг на сервері без затримок і компіляцію без зайвого коду під час виконання.
Автоматизація за допомогою ШІ та традиційні платформи локалізації
Важливим зрушенням останніх років стала автоматична генерація перекладів за допомогою ШІ, що змушує переглянути підходи традиційних систем управління перекладами (TMS).
Раніше збирання текстів в один великий JSON було вимушеним компромісом для спрощення роботи з TMS. Єдиний файл полегшував імпорт та експорт стороннім командам перекладачів. Але розробники платили за це конфліктами в git, втратою контексту компонентів і сотнями покинутих рядків.
Завдяки генеративному ШІ та можливостям компіляторів пріоритетом знову стає зручність розробників. Інструменти збірки та CLI можуть самостійно виявляти, перевіряти та перекладати файли контенту поруч із компонентами, зберігаючи архітектурну чистоту проєкту.
Комерційні платформи понад десять років будували свої пропозиції навколо ручних процесів:
- Сервіси на зразок Locize (комерційна платформа для
i18next) та Crowdin (партнер низки відкритих бібліотек) базували свої плани на збереженні перекладів, лімітах обсягу та платі за кількість слів. - Оскільки їхня модель прив'язана до обсягу та ручної обробки, у них менше стимулів безкоштовно додавати пряму автоматизацію у робоче середовище інженерів.
Нові інструменти ШІ та пряма вартість API
Зі зниженням вартості роботи великих мовних моделей до часток цента за високої якості з'явилося нове покоління комерційних інструментів:
- Рішення на кшталт Paraglide з linguo.dev або General Translation (
gt-react,gt-next) пропонують власні хмарні платформи за передплатою. - На противагу цьому, Intlayer надає можливість перекладу за допомогою ШІ безпосередньо через власну CLI, дозволяючи командам підключати власні ключі API (OpenAI, Anthropic, Mistral або Google Gemini). Без посередників, націнок чи прив'язки до сервісу розрахунок відбувається за прямими тарифами обраного провайдера.
Більше ніж i18n: повноцінна система багатомовного контенту
Сучасна веброзробка вже давно вийшла за межі перекладу окремих слів на зразок "Надіслати" чи "Увійти". Застосункам потрібен багатий, динамічний і структурований контент на всіх етапах взаємодії з користувачем.
Intlayer розглядає це завдання не просто як пошук рядків за ключами, а як комплексну систему керування багатомовним контентом. Завдяки підтримці Markdown, HTML-структур, складних схем даних і візуального редактора він поєднує інженерну розробку, процеси зі штучним інтелектом та редагування текстів.
Для детального порівняння архітектурних підходів і практичних посібників з міграції перегляньте такі матеріали:
Коментарі
Поки що немає коментарів. Будьте першим, хто поділиться своїми думками.