Безперервна локалізація

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

Дивись також

Інтеграція із Weblate describes basic ways to integrate your development with Weblate. Code hosting integrations lists provider-specific setup steps for common code hosting sites.

Ось процедура:

  1. Розробники змінюють код і записують його до сховища системи керування версіями.

  2. Якщо потрібно, оновлюються файли перекладу, див. Додавання нових рядків.

  3. Weblate отримує зміни з сховища системи керування версіями, обробляє файли перекладу та оновлює свою базу даних, див. Оновлення сховищ.

  4. Перекладачі подають переклади за допомогою вебінтерфейсу Weblate або вивантажують зроблені поза інтернетом переклади.

  5. Щойно переклад буде завершено, Weblate надсилає зміни до локального сховища (див. «Ліниві» внески).

  6. Changes are pushed back to the upstream repository (see Записування змін з Weblate).

digraph translations { graph [fontname = "sans-serif", fontsize=10, ranksep=0.6, newrank=true]; node [fontname = "sans-serif", fontsize=10, margin=0.15]; edge [fontname = "sans-serif", fontsize=10]; subgraph cluster_codehosting { rank=same; graph [color=lightgrey, label="Upstream code hosting", style=filled ]; "VCS repository" [shape=cylinder]; } subgraph cluster_weblate { rank=same; graph [color=lightgrey, label="Weblate", style=filled ]; repo [label="Weblate repository", shape=cylinder]; database [label=Database, shape=cylinder]; } "Developers" [shape=box, fillcolor="#144d3f", fontcolor=white, style=filled]; "Translators" [shape=box, fillcolor="#144d3f", fontcolor=white, style=filled]; "Developers" -> "VCS repository" [label=" 1. Push "]; "VCS repository" -> "VCS repository" [label=" 2. Updating translations ", style=dotted]; "VCS repository" -> repo [label=" 3. Pull "]; repo -> database [label=" 3. Parse translations "]; "database" -> repo [label=" 5. Commit changes "]; "Translators" -> "database" [label=" 4. Translate "]; "repo" -> "VCS repository" [label=" 6. Push repository "]; }

Підказка

Зберігання коду в основній гілці розробки не є обов’язковим — ви можете скористатися Weblate з Локальні файли, де існує лише сховище всередині Weblate.

Оновлення сховищ

Вам слід налаштувати певний спосіб оновлення сховищ з початкового коду.

Кожного разу, коли оновлюватиме Weblate, буде увімкнено додатки остаточної обробки, див. Додатки.

Уникання конфліктів об’єднання

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

Уникайте конфліктів злиття, змінюючи файли перекладу лише в Weblate

Уникати редагування за межами Weblate легко з одномовними файлами — ви можете додати нові рядки в Weblate і залишити повне редагування файлів там. Для двомовних файлів зазвичай існує певний процес вилучення повідомлень для створення файлів, які можна перекладати, із вихідного коду. У деяких випадках це можна розділити на дві частини:

  1. Витяг генерує шаблон (наприклад, gettext POT генерується за допомогою xgettext).

  2. Подальший процес об’єднує його у фактичні переклади (файли gettext PO оновлюються за допомогою msgmerge).

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

Уникнення конфліктів злиття шляхом блокування Weblate під час внесення зовнішніх змін

Інтеграцію Weblate у ваш процес оновлення, щоб він знімав зміни перед оновленням файлів поза Weblate, можна досягти за допомогою Програмний інтерфейс REST Weblate, щоб змусити Weblate надіслати всі незавершені зміни та заблокувати переклад, поки ви вносите зміни на своєму боці.

Скрипт для виконання оновлень може виглядати ось так:

# Lock Weblate translation
wlc lock
# Push changes from Weblate to upstream repository
wlc push
# Pull changes from upstream repository to your local copy
git pull
# Update translation files, this example is for Django
./manage.py makemessages --keep-pot -a
git commit -m 'Locale updates' -- locale
# Push changes to upstream repository
git push
# Tell Weblate to pull changes (not needed if Weblate follows your repo
# automatically)
wlc pull
# Unlock translations
wlc unlock

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

wlc lock foo/bar
wlc lock foo/baz
wlc lock foo/baj

Примітка

У прикладі використовується Клієнт Weblate, якому потрібна конфігурація (ключі API), щоб мати можливість віддалено керувати Weblate. Ви також можете досягти цього, використовуючи будь-який клієнт HTTP замість Клієнт Weblate, наприклад curl, див. Програмний інтерфейс REST Weblate.

Супровід репозиторію

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

Ці самі дії також можна запустити за допомогою Програмний інтерфейс REST Weblate або, для підтримуваної підмножини, Клієнт Weblate.

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

Дія

Що це робить

Типове застосування

Коміт

Записує зміни, що очікують на затвердження та зберігаються у Weblate, до локального репозиторію.

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

Push

Відправляє зміни, зафіксовані в локальному репозиторії, до налаштованого вищого репозиторію.

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

Оновлення

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

Синхронізуйте Weblate з основним репозиторієм за допомогою стандартної стратегії інтеграції.

Оновлення з об’єднанням

Завантажує зміни з вищих гілок та інтегрує їх за допомогою явного злиття.

Замінити стиль об’єднання за замовчуванням для одного оновлення.

Оновити з перебазуванням

Завантажує зміни з основного репозиторію та перебазує локальні коміти Weblate на основі цих змін.

Зберігайте лінійну структуру історії, якщо це відповідає вашому робочому процесу.

Оновлення з об’єднанням без переходу вперед

Завантажує зміни з сервера та створює явну коміт злиття, навіть якщо можливе виконання операції fast-forward.

Зберігайте коміти злиття для цілей аудиту або управління гілками.

Заблокувати / Розблокувати

Забороняє або дозволяє перекладачам вносити подальші зміни в Weblate.

Заблокувати зміни перекладу під час обслуговування репозиторію поза Weblate.

Скинути та видалити

Скидає локальний репозиторій Weblate до стану вихідного коду та відкидає зміни Weblate, що знаходяться на розгляді.

Використовуйте, коли джерело має замінити стан локального репозиторію Weblate.

Скинути налаштування та застосувати їх знову

Скидає локальний репозиторій Weblate до стану вихідного коду, зберігаючи при цьому переклади, що знаходяться в процесі обробки. Див. Скинути та повторно застосувати параметри відновлення.

Відновити дані з розбіжностей в історії, зберігши незавершені переклади Weblate.

Очищення

Видаляє файли, що не відстежуються, та застарілі гілки з локальної копії репозиторію.

Очистити залишки файлів або застарілі дані репозиторію у робочій копії Weblate.

Синхронізувати

Змушує Weblate записати всі відомі переклади назад у файли репозиторію.

Виправлення випадків, коли файли репозиторію втратили синхронізацію зі станом бази даних.

Повторне сканування

Знову завантажує файли перекладу з локального репозиторію в Weblate.

Імпортувати зміни у файлах після ручної роботи з репозиторієм або створення файлів.

Скинути та повторно застосувати параметри відновлення

Операція Скинути та застосувати знову зберігає переклади з Weblate, що знаходяться в черзі, та одночасно скидає стан локального репозиторію, щоб він відповідав стану вихідного коду.

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

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

Щоб уникнути конфліктів злиття, зосередившись на операціях Git

Навіть якщо Weblate є єдиним джерелом змін у файлах перекладу, можуть виникати конфлікти під час використання надбудови Сполучити Git подання, Стиль злиття налаштовано на Rebase, або ви стискаєте коміти за межами Weblate (наприклад, під час об’єднання запиту на отримання).

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

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

Існує декілька способів цього уникнути:

  • Не використовуйте ні Сполучити Git подання, ні об’єднання при злитті. Це коренева причина того, чому git не розпізнає зміни після об’єднання.

  • Дозвольте Weblate зафіксувати незавершені зміни перед об’єднанням. Це оновить запит на отримання з усіма його змінами, і обидва сховища будуть синхронізовані.

  • Використовуйте функції перегляду в Weblate (див. Процеси перекладу), щоб ви могли автоматично об’єднувати запити на отримання GitHub після проходження CI.

  • Користуйтеся блокуванням у Weblate, щоб уникнути внесенню змін, доки запит щодо об’єднання на GitHub перебуває на рецензуванні.

Дивись також

Клієнт Weblate

Code hosting notifications

Provider-specific app and webhook instructions for GitHub, GitLab, Bitbucket, Pagure, Azure Repos, Gitea, Forgejo, and Gitee are covered in Code hosting integrations.

Provider-specific notifications

These legacy anchors are kept for compatibility. Current provider-specific app and webhook setup is documented in Code hosting integrations.

Автоматичне щонічне оновлення сховищ

Weblate автоматично отримує вміст віддалених сховищ щодня для поліпшення швидкодії при наступному об’єднанні змін. Якщо хочете, можете перетворити це на щоденні об’єднання, увімкнувши AUTO_UPDATE.

Записування змін з Weblate

Each translation component can have a push URL set up (see Адреса для записування до сховища), and in that case Weblate will be able to push changes to the remote repository. Weblate can also be configured to automatically push changes on every commit, see Відправляти при поданні.

For the push options table and provider-specific pull, merge, and review request workflows, see Записування змін з Weblate.

Дивись також

Опис налаштовування ключів SSH можна знайти у розділі Доступ до сховищ. Дані щодо того, яким чином Weblate визначає потребу у внесенні змін, можна знайти у розділі «Ліниві» внески.

Захищені гілки

Якщо ви використовуєте Weblate для захищеної гілки, ви можете налаштувати його на використання запитів щодо об’єднання і увімкнути рецензування перекладів (може бути проблематичним для мов, яких ви не знаєте). Альтернативним підходом є відмова від цього обмеження для користувача Weblate, який записуватиме дані до сховища.

Наприклад, у GitHub це можна зробити у налаштуваннях сховища:

../_images/github-protected.png

Взаємодія із іншими

Weblate спрощує взаємодію із іншими учасниками проєкту за допомогою програмного інтерфейсу.

«Ліниві» внески

Weblate групує внески від одного автора так, щоб остаточний внесок був якомога більшим. Це значно зменшує кількість внесків, але призводить до того, що у вас може виникнути потреба явним чином ініціювати внески, якщо ви хочете підтримувати синхронізацію з сховищем системи керування версіями, наприклад, для злиття (таке злиття типово увімкнено для групи Managers, див. Список прав доступу).

Зміни у цьому режимі вносяться, щойно буде виконано будь-яку з таких умов:

  • Хтось інший вніс зміни до вже зміненого рядка.

  • Сталося злиття коду з основної гілки розробки.

  • Надіслано запит на явний внесок.

  • Надіслано запит щодо отримання файла.

  • Зміна є старішою за часовий проміжок, визначений як Вік змін для подання у Налаштовування складників.

Підказка

Внески створюються для кожного складника. Отже, якщо у вас багато складників, у вас буде багато внесків. Щоб зменшити кількість, ви можете скористатися додатком Сполучити Git подання.

Якщо ви хочете частіше вносити зміни без перевірки віку, ви можете запланувати регулярне завдання для виконання фіксації. Це можна зробити за допомогою Periodic Tasks в Адміністративний інтерфейс Django. Спочатку створіть потрібний Interval (наприклад, 120 секунд). Потім додайте нове періодичне завдання та виберіть weblate.trans.tasks.commit_pending як Task з {"hours": 0} як Keyword Arguments та потрібний інтервал.

Обробка сховища зі скриптами

Спосіб взаємодії Weblate з сховищем коду можна змінити за допомогою Додатки. Зверніться до розділу Виконання скриптів з додатка, щоб дізнатися про те, як виконувати зовнішні скрипти з додатків.

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

Якщо у вас декілька складників перекладу, у вас може виникнути потреба у тому, щоб однакові рядки мали однакові переклади. Досягти такої синхронізації можна на декількох рівнях.

Синхронізація перекладу

Якщо увімкнено Дозволити поширення перекладу (типова поведінка, див. Налаштовування складників), усі нові переклади автоматично виконуватимуться в усіх складниках із відповідними рядками. Авторство таких перекладів буде визначено належним чином — автором в усіх складниках вважатиметься той, хто здійснив переклад в одному із складників.

Передумови поширення:

  • Усі компоненти повинні знаходитися в одному проєкті (зв’язування компонентів недостатньо).

  • Увімкніть Дозволити поширення перекладу для автоматичного повторного використання перекладів для збігів рядків.

  • Поширення перекладів потребує використання однакового ключа для одномовних форматів перекладу. Це слід мати на увазі при створенні ключів перекладу.

  • Рядки поширюються під час перекладу, рядки, завантажені з репозиторію, не поширюються.

Порада

Ця функція наразі має обмеження, і ми хочемо зробити її більш універсальною. Будь ласка, поділіться своїми відгуками за адресою https://github.com/WeblateOrg/weblate/issues/3166.

Перевірка коректності

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

Автоматичний переклад

Автоматичний переклад на основі різних складових може бути використано як спосіб синхронізації перекладів у різних складниках. Ви можете увімкнути автоматичний переклад вручну (див. Автоматичний переклад) або налаштувати його автоматичне виконання при оновленні сховища за допомогою додатка (див. Автоматичний переклад).