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

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

Дивись також

У Інтеграція із Weblate описано базові способи інтеграції вашої розробки із Weblate.

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

Розробники змінюють код і записують його до сховища системи керування версіями.
Якщо потрібно, оновлюються файли перекладу, див. Додавання нових рядків.
Weblate отримує зміни з сховища системи керування версіями, обробляє файли перекладу та оновлює свою базу даних, див. Оновлення сховищ.
Перекладачі подають переклади за допомогою вебінтерфейсу Weblate або вивантажують зроблені поза інтернетом переклади.
Щойно переклад буде завершено, Weblate надсилає зміни до локального сховища (див. «Ліниві» внески).
Зміни буде записано до основного сховища (див. Записування змін з Weblate).

Підказка

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

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

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

Скористайтеся Обробники сповіщень для інтеграції із більшістю типових служб зберігання коду:
Щоб це спрацювало, слід також встановити Увімкнути обробники.
Увімкніть оновлення вручну або у керуванні сховищем, або за допомогою Програмний інтерфейс REST Weblate або Клієнт Weblate
Увімкніть AUTO_UPDATE для автоматичного оновлення всіх складників у вашому екземплярі Weblate
Виконайте updategit (із вибором проєкту або додаванням --all для оновлення усього)

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

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

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

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

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

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

Витяг генерує шаблон (наприклад, gettext POT генерується за допомогою xgettext).
Подальший процес об’єднує його у фактичні переклади (файли 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.

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

The Repository maintenance view shows repository status for a project, component, or translation and lets privileged users run maintenance operations from the user interface.

The same actions can also be triggered using Програмний інтерфейс REST Weblate or, for the supported subset, Клієнт Weblate.

Availability of individual actions depends on permissions, the configured version control system, whether pushing is configured, and whether the selected object can be locked.

Дія	What it does	Typical use
Commit	Commits pending changes stored in Weblate to the local repository.	Flush pending Weblate changes before doing repository work elsewhere.
Push	Pushes committed local repository changes to the configured upstream.	Send committed translations upstream when automatic push is disabled or delayed.
Update	Fetches upstream changes and integrates them using the component’s configured Стиль злиття.	Bring Weblate in sync with upstream using the default integration strategy.
Update with merge	Fetches upstream changes and integrates them with an explicit merge.	Override the default merge style for a single update.
Update with rebase	Fetches upstream changes and rebases local Weblate commits on top of upstream.	Keep history linear when that matches your workflow.
Update with merge without fast-forward	Fetches upstream changes and creates an explicit merge commit even when a fast-forward would be possible.	Preserve merge commits for auditing or branch-management reasons.
Lock / Unlock	Prevents or allows translators to make further changes in Weblate.	Freeze translation changes while doing repository maintenance outside Weblate.
Reset and discard	Resets Weblate’s local repository to upstream and discards pending Weblate changes.	Use when upstream should overwrite the local Weblate repository state.
Reset and reapply	Resets Weblate’s local repository to upstream while preserving pending translations. See Reset and reapply recovery behavior.	Recover from diverged history while keeping pending Weblate translations.
Cleanup	Removes untracked files and stale branches from the local repository checkout.	Clean up leftover files or stale repository state in Weblate’s checkout.
Synchronize	Forces Weblate to write all known translations back to the repository files.	Repair cases where repository files became out of sync with the database state.
Rescan	Re-reads translation files from the local repository into Weblate.	Import file changes after manual repository work or file creation.

Reset and reapply recovery behavior¶

The Reset and reapply operation keeps pending translations from Weblate while resetting the local repository state to match upstream.

The operation can restore pending translations only when the target language files still exist after the reset or when Weblate can create them for the component, for example using a valid Шаблон для нових перекладів.

If neither of these conditions is met, Weblate keeps the pending changes in its database and reports a recovery error instead of failing later with a generic parse error.

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

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

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

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

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

Не використовуйте ні Сполучити Git подання, ні об’єднання при злитті. Це коренева причина того, чому git не розпізнає зміни після об’єднання.
Дозвольте Weblate зафіксувати незавершені зміни перед об’єднанням. Це оновить запит на отримання з усіма його змінами, і обидва сховища будуть синхронізовані.
Використовуйте функції перегляду в Weblate (див. Процеси перекладу), щоб ви могли автоматично об’єднувати запити на отримання GitHub після проходження CI.
Користуйтеся блокуванням у Weblate, щоб уникнути внесенню змін, доки запит щодо об’єднання на GitHub перебуває на рецензуванні.

Дивись також

Клієнт Weblate

Автоматичне отримання змін з GitHub¶

Weblate постачається із вбудованою підтримкою GitHub.

If you are using Hosted Weblate, the recommended approach is to install the Weblate app. The app delivers GitHub notifications to Hosted Weblate, so you do not need to configure a separate Webhook in GitHub. It does not by itself grant Hosted Weblate write access to the repository, though. To push changes back, you still need to add the Hosted Weblate weblate GitHub user as a collaborator with write access, see Доступ до сховищ з Hosted Weblate.

If you are not using the app, add the Weblate Webhook in the repository settings (Webhooks) to receive notifications on every push to a GitHub repository, as shown on the image below:

Payload URL складається з вашої URL-адреси Weblate, яко передує /hooks/github/, наприклад, для служби Hosted Weblate — це https://hosted.weblate.org/hooks/github/.

Ви можете лишити типові значення для решти параметрів (Weblate може одночасно обробляти обидва типи даних і споживатиметься лише подію push).

Дивись також

Автоматичне отримання змін з Bitbucket¶

У Weblate передбачено підтримку вебскриптів Bitbucket. Додайте вебскрипт, який вмикає запис до сховища із адресою призначення /hooks/bitbucket/ у вашому встановленому Weblate (наприклад, https://hosted.weblate.org/hooks/bitbucket/).

Дивись також

Автоматичне отримання змін з GitLab¶

У Weblate передбачено підтримку скриптів GitLab. Додайте вебскрипт проєкту із адресою призначення /hooks/gitlab/ у встановленому вами Weblate (наприклад, https://hosted.weblate.org/hooks/gitlab/).

Вирішення проблем

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

Дивись також

Автоматичне отримання змін з Pagure¶

У Weblate передбачено підтримку скриптів Pagure. Додайте вебскрипт із адресою призначення /hooks/pagure/ у встановленому вами Weblate (наприклад, https://hosted.weblate.org/hooks/pagure/). Зробити це можна за допомогою пункту Activate Web-hooks у розділі Project options:

Дивись також

Автоматичне отримання змін зі сховищ Azure¶

У Weblate передбачено підтримку веб скриптів сховищ Azure. Додайте вебскрипт для події Code pushed із адресою призначення /hooks/azure/ у встановленому вами Weblate (наприклад, https://hosted.weblate.org/hooks/azure/). Зробити це можна за допомогою пункту Service hooks у розділі Project settings.

Дивись також

Автоматичне отримання змін зі сховищ Gitea¶

У Weblate передбачено підтримку вебскриптів Gitea. Додайте Gitea Webhook для події Push events із адресою призначення /hooks/gitea/ у встановленому вами Weblate (наприклад, https://hosted.weblate.org/hooks/gitea/). Зробити це можна за допомогою пункту Webhooks у розділі Settings сховища.

Дивись також

Automatically receiving changes from Forgejo Repos¶

Weblate has support for Forgejo webhooks, add a Forgejo Webhook for Push events event with destination to /hooks/forgejo/ URL on your Weblate installation (for example https://hosted.weblate.org/hooks/forgejo/). This can be done in Webhooks under repository Settings.

Дивись також

Автоматичне отримання змін зі сховищ Gitee¶

У Weblate передбачено підтримку вебскриптів Gitee. Додайте WebHook для події Push із адресою призначення /hooks/gitee/ у встановленому вами Weblate (наприклад, https://hosted.weblate.org/hooks/gitee/). Зробити це можна за допомогою пункту WebHooks у розділі Management сховища.

Дивись також

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

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

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

Для кожного складника перекладу може бути налаштовано адресу запису (див. Адреса для записування до сховища). Якщо таку назву налаштовано, Weblate зможе записувати зміни до віддаленого сховища. Крім того, Weblate можна налаштувати на автоматичне записування змін при кожному внеску (це типова поведінка, див. Відправляти при поданні). Якщо ви не хочете, щоб зміни записувалися автоматично, ви можете записувати їх вручну у розділі Супровід сховища або за допомогою програмного інтерфейсу: wlc push.

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

Якщо ви не хочете отримувати прямі надсилання змін від Weblate, існує підтримка для оглядів Запити щодо злиття GitHub, Запити щодо об’єднання GitLab, Запити щодо злиття Gitea, Запити щодо об’єднання Pagure, Запити щодо об’єднання Azure DevOps або Gerrit. Ви можете активувати їх, вибравши GitHub, GitLab, Gitea, Gerrit, Azure DevOps або Pagure як Система керування версіями у Налаштовування складників.

Загалом такі параметри доступні для Git, Mercurial, GitHub, GitLab, Gitea, Pagure, Azure DevOps, Bitbucket Data Center і Bitbucket Cloud:

Бажане налаштування	Система керування версіями	Адреса для записування до сховища	Гілка для запису
Без запису	Git	empty	empty
Записувати безпосередньо	Git	Адреса SSH	empty
Записувати до окремої гілки	Git	Адреса SSH	Назва гілки
Без запису	Mercurial	empty	empty
Записувати безпосередньо	Mercurial	Адреса SSH	empty
Записувати до окремої гілки	Mercurial	Адреса SSH	Назва гілки
Запит щодо об’єднання у GitHub з відгалуження	Запити щодо злиття GitHub	empty	empty
Запит щодо об’єднання у GitHub з гілки	Запити щодо злиття GitHub	SSH URL [1]	Назва гілки
Запит щодо злиття на GitLab з відгалуження	Запити щодо об’єднання GitLab	empty	empty
Запит щодо злиття на GitLab з гілки	Запити щодо об’єднання GitLab	SSH URL [1]	Назва гілки
Запит щодо злиття на Gitea з відгалуження	Запити щодо злиття Gitea	empty	empty
Запит щодо злиття на Gitea з гілки	Запити щодо злиття Gitea	SSH URL [1]	Назва гілки
Запит щодо злиття на Pagure з відгалуження	Запити щодо об’єднання Pagure	empty	empty
Запит щодо злиття на Pagure з гілки	Запити щодо об’єднання Pagure	SSH URL [1]	Назва гілки
Запит щодо об’єднання з відгалуження Azure DevOps	Запити щодо об’єднання Azure DevOps	empty	empty
Запит на злиття Azure DevOps з гілки	Запити щодо об’єднання Azure DevOps	SSH URL [1]	Назва гілки
Запит на отримання запиту Bitbucket Data Center із форка	Запити на вилучення Bitbucket Data Center	empty	empty
Запит на злиття з Bitbucket Data Center з гілки	Запити на вилучення Bitbucket Data Center	SSH URL [1]	Назва гілки
Запити щодо об’єднання Bitbucket Cloud з відгалуження	Запити щодо об’єднання Bitbucket Cloud	empty	empty
Запити щодо об’єднання Bitbucket Cloud з гілки	Запити щодо об’єднання Bitbucket Cloud	SSH URL [1]	Назва гілки

Примітка

Ви також можете увімкнути автоматичний запис змін після внесків Weblate. Зробити це можна у Відправляти при поданні.

Дивись також

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

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

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

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

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

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

Дивись також

Програмний інтерфейс REST 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.

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

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

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

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