Інтернаціоналізація

Додайте підтримку кількох мов до свого застосунку. Використовуйте Proyecta Content API для локалізації редакційного контенту або попросіть ШІ підключити i18n-фреймворк безпосередньо в коді.

Proyecta підтримує два взаємодоповнювальні підходи до інтернаціоналізації застосунків, які ви створюєте:

1. Локалізація контенту через Proyecta Content API — для редакційного контенту (дописи у блозі, FAQ, маркетингові тексти), який потрібно перекласти кількома мовами
2. i18n на рівні коду через фреймворк перекладів — для рядків інтерфейсу, дат, валют і перемикання локалі під час виконання

Обидва підходи працюють вже сьогодні. Який саме вам потрібен — залежить від того, що ви перекладаєте.

Сам builder Proyecta постачається з 24 локалями, тож продукт добре розуміється на i18n. Ті самі патерни застосовуються до застосунків, які ви створюєте всередині нього.

Варіант 1: Локалізація контенту (Proyecta Content API)

Якщо ви будуєте сайт із великим обсягом контенту — блог, базу знань, маркетингові сторінки, каталог продуктів — використовуйте вбудовану підтримку локалей. Скажіть ШІ, які мови ви підтримуєте ("Make the site available in English, Spanish and French"), і він зареєструє їх за вас, де англійська буде мовою за замовчуванням. Далі отримуйте контент мовою відвідувача.

На frontend типізовані хуки контенту шаблону автоматично повертають локалізовані поля — передайте активну локаль відвідувача, і кожне поле з типом localized повернеться як єдине перекладене значення:

import { useCollection, useEntry } from '@/hooks/useContent';
import { useTranslation } from 'react-i18next';

function Blog({ slug }: { slug: string }) {
    const { i18n } = useTranslation();

    // List a collection in the current locale
    const { data: posts } = useCollection('posts', { locale: i18n.language });

    // Or read one entry by slug in the current locale
    const { data: post } = useEntry('posts', slug, { locale: i18n.language });

    // ...render posts / post
}

За лаштунками CMS проходить ланцюжок резервних локалей — запитана локаль → її налаштовані резервні варіанти → локаль за замовчуванням — і повідомляє код фактично використаної локалі для кожного запису у полі localeResolved. Якщо не передавати locale для одномовних сайтів, поля повертаються як звичайні значення.

Цей підхід підходить, коли:

• Редактори без технічних навичок мають перекладати контент
• Потрібна версійність перекладів
• Потрібна публікація для конкретних локалей (заплановану публікацію незабаром буде додано — наразі записи потрібно публікувати вручну через API)

Дивіться Content Management для повної документації Content API.

Варіант 2: i18n-фреймворк на рівні коду

Для рядків інтерфейсу — підписів, кнопок, повідомлень про помилки, дат, валют — попросіть ШІ підключити i18n-фреймворк безпосередньо до вашого проєкту:

Add internationalization to my app.
Support English, Spanish, French, and Arabic.
Add message catalogs in src/locales/.
Add a language switcher in the header.
Use locale-prefixed URLs like /en/about and /es/about.
Make sure RTL layout works correctly for Arabic.

ШІ виконає наступне:

1. Обере фреймворк — ШІ використовує i18next з react-i18next (стандарт Proyecta)
2. Створить файли каталогів у src/locales/ (один JSON на мову)
3. Огорне тексти у виклики t() (з хука useTranslation бібліотеки react-i18next)
4. Додасть компонент перемикача мов
5. Налаштує маршрутизацію URL з префіксами локалей
6. Обробить RTL-макети (dir="rtl") для арабської, іврит тощо
7. Відформатує числа, дати та валюти відповідно до локалі

Автопереклад за допомогою ШІ

Коли базова мова готова, ШІ чудово справляється зі створенням інших файлів каталогів:

• "Translate every string in src/locales/en.json into Spanish, French, German, and Japanese. Use natural, idiomatic phrasing — don't translate brand names."
• "My app is fully built in English. Add Spanish translations for everything and an es/ route prefix."

Для важливого контенту (юридичні тексти, медицина, фінанси) перегляньте результат ШІ разом із людиною-перекладачем перед публікацією.

Поєднання обох підходів

Більшість реальних застосунків використовують обидва варіанти: i18n на рівні коду для елементів інтерфейсу (кнопки, помилки, навігація) і Content API для редакційного контенту (статті, описи продуктів). Вони чудово співіснують — ваш i18n-фреймворк обробляє файли каталогів під час збірки, Content API повертає локалізовані записи під час виконання.

Найкращі практики

1. Спочатку визначтеся з базовою мовою та доведіть тексти до фіналу. Перекладати мінливу основу — болісно.
2. Перекладайте партіями. Не перекладайте в процесі — зачекайте, поки функція стабілізується.
3. Перевіряйте RTL завчасно, якщо підтримуєте арабську або іврит. Помилки RTL ховаються, поки ви справді не подивитеся.
4. Вказуйте lang і dir на <html>. Від цього залежать браузери та скринридери.
5. Використовуйте Intl для форматування. Не пишіть власний код для форматування дат або валют — використовуйте Intl.DateTimeFormat, Intl.NumberFormat.

Незабаром

• UI управління локалями прямо в builder — обирайте локалі, відстежуйте покриття перекладів, редагуйте каталоги, не виходячи з Proyecta
• Автоматичний переклад під час збереження для нових рядків
• Шаблони проєктів із готовим i18n з попередньо підключеним фреймворком