Поширені питання та відповіді на них¶
Налаштування¶
Як створити автоматизовану процедуру?¶
Weblate може обробляти усі завдання, які пов’язано із перекладом, у напівавтоматичному режимі. Якщо ви надасте Weblate доступ до запису до вашого сховища, переклад відбуватиметься без вашого втручання, якщо не станеться якихось конфліктів об’єднання.
Налаштуйте свій репозиторій Git так, щоб він повідомляв Weblate про будь-які зміни, див. Обробники сповіщень для отримання інформації про те, як це зробити.
Установіть адресу запису у розділі Налаштовування складників у Weblate, це надасть змогу Weblate записувати зміни до вашого сховища.
Увімкніть Відправляти при поданні для вашого Налаштовування складників у Weblate, це змусить Weblate надсилати зміни до вашого репозиторію щоразу, коли вони відбуватимуться у Weblate.
Дивись також
Як отримувати доступ до сховища за допомогою SSH?¶
Будь ласка, ознайомтеся із розділом Доступ до сховищ, щоб дізнатися більше про налаштовування ключів SSH.
Як виправляти конфлікти об’єднання у перекладах?¶
Конфлікти злиття час від часу трапляються, коли файл перекладу змінюється одночасно як у Weblate, так і в репозиторії основної розробки. Зазвичай цього можна уникнути, об’єднавши переклади Weblate перед внесенням змін до файлів перекладів (наприклад, перед запуском msgmerge). Просто накажіть Weblate зафіксувати всі переклади, що очікують на розгляд (ви можете зробити це в Repository maintenance в меню Operations) та об’єднайте репозиторій (якщо автоматичне надсилання не ввімкнено).
Якщо ви вже маєте конфлікт об’єднання, найпростішим способом вирішити проблему є усування усіх конфліктів локально на вашій робочій станції — просто додайте Weblate як віддалене сховище, об’єднайте його із основною гілкою розробки і виправте усі конфлікти. Щойно ви запишете зміни до основного сховища, Weblate зможе використовувати об’єднану версію без будь-яких інших додаткових дій.
Примітка
Weblate за замовчуванням використовує поверхневі клони, щоб скоротити час клонування та зменшити використання дискового простору. З огляду на це, наведений нижче алгоритм роботи найкраще працює, якщо ви починаєте з актуальної версії вихідного репозиторію. Якщо ви клонуєте безпосередньо з експортованого репозиторію Weblate або якщо у вашій версії вихідного коду відсутні останні коміти, команда git remote update weblate може завершитися з помилками, такими як warning: no common commits, bad revision або відсутність об’єктів. Це не обов’язково означає, що Weblate та вихідний репозиторій мають конфліктні зміни. Адміністратори, які хочуть зробити цей робочий процес більш надійним, можуть налаштувати VCS_CLONE_DEPTH.
Примітка
Залежно від ваших налаштувань, доступ до репозиторію Weblate може вимагати автентифікації. Під час використання вбудованого Засіб експортування Git у Weblate ви автентифікуєтесь за допомогою свого імені користувача та ключа API.
Примітка
Weblate надає доступ до самого репозиторію Git, але не до об’єктів Git LFS. Для репозиторіїв, що використовують Git LFS, слід клонувати репозиторій з вихідного джерела та додати Weblate як ще один віддалений сервер. Якщо вам потрібні лише файли, що відстежуються Git, ви можете клонувати репозиторій з Weblate, вказавши параметр GIT_LFS_SKIP_SMUDGE=1, щоб пропустити завантаження об’єктів Git LFS.
Якщо ви починаєте з актуальної версії, витягнутої з основного репозиторію, робочий процес зазвичай виглядає так:
# Open an existing up-to-date checkout of the upstream repository or perform
# a fresh one:
git clone UPSTREAM_REPOSITORY_URL
cd REPO
# Commit all pending changes in Weblate, you can do this in the UI as well:
wlc commit
# Lock the translation in Weblate, again this can be done in the UI as well:
wlc lock
# Add Weblate as remote:
git remote add weblate https://hosted.weblate.org/git/project/component/
# You might need to include credentials in some cases:
git remote add weblate https://username:APIKEY@hosted.weblate.org/git/project/component/
# Update weblate remote:
git remote update weblate
# Merge Weblate changes:
git merge weblate/main
# Resolve conflicts:
edit …
git add …
…
git commit
# Rebase changes (if Weblate is configured to do rebases)
git rebase origin/main
# Push changes to upstream repository, Weblate will fetch merge from there:
git push
# Open Weblate for translation:
wlc unlock
Якщо ви використовуєте у Weblate кілька гілок, ви можете зробити те саме для кожної з них:
# Add and update Weblate remotes
git remote add weblate-one https://hosted.weblate.org/git/project/one/
git remote add weblate-second https://hosted.weblate.org/git/project/second/
git remote update weblate-one weblate-second
# Merge QA_4_7 branch:
git checkout QA_4_7
git merge weblate-one/QA_4_7
... # Resolve conflicts
git commit
# Merge main branch:
git checkout main
git merge weblates-second/main
... # Resolve conflicts
git commit
# Push changes to the upstream repository, Weblate will fetch the merge from there:
git push
У випадку файлів PO gettext існує спосіб розв’язувати усі конфлікти об’єднання у напівавтоматичному режимі:
Отримайте і збережіть локальний клон сховища Git Weblate. Також отримайте другий свіжий локальний клон основного сховища Git (тобто, вам знадобляться дві копії сховища Git: незмінена та робоча копії):
# Add remote:
git remote add weblate /path/to/weblate/snapshot/
# Update Weblate remote:
git remote update weblate
# Merge Weblate changes:
git merge weblate/main
# Resolve conflicts in the PO files:
for PO in `find . -name '*.po'` ; do
msgcat --use-first /path/to/weblate/snapshot/$PO\
/path/to/upstream/snapshot/$PO -o $PO.merge
msgmerge --previous --lang=${PO%.po} $PO.merge domain.pot -o $PO
rm $PO.merge
git add $PO
done
git commit
# Push changes to the upstream repository, Weblate will fetch merge from there:
git push
Як налаштувати одночасний переклад у декількох гілках розробки?¶
Weblate підтримує надсилання змін перекладу в межах одного Налаштування проєкту. Для кожного Налаштовування складників, у якому це ввімкнено (поведінка за замовчуванням), внесені зміни автоматично поширюються на інші. Таким чином, переклади синхронізуються, навіть якщо самі гілки вже значно розійшлися, і неможливо просто об’єднати зміни перекладу між ними.
Щойно зміни з Weblate буде об’єднано, ви можете, вам, ймовірно, слід об’єднати ці гілки (залежно від вашої типової процедури розробки), відкинувши різниці:
git merge -s ours origin/maintenance
Як налаштувати переклад багатоплатформових проєктів?¶
У Weblate передбачено підтримку широкого діапазону форматів файлів (див. Формати файлів локалізації), і найпростішим підходом є використання природного формату для кожної з платформ.
Після додавання всіх файлів перекладу для платформи як складників до одного проєкту (див. Додавання проєктів і складників перекладу) ви можете скористатися можливістю поширення перекладів (типово увімкнено, можна вимкнути на рівні Налаштовування складників) для перекладу рядків для всіх платформ одночасно.
Як експортувати сховище Git, який використовує Weblate?¶
У цьому сховищі немає нічого особливого — воно зберігається у каталозі DATA_DIR і має назву vcs/<проєкт>/<складник>/. Якщо ви маєте SSH-доступ до відповідного комп’ютера, ви можете використовувати сховище безпосередньо.
Для анонімного доступу вам варто запустити сервер Git і налаштувати його на обслуговування сховища для всіх інших користувачів.
Крім того, ви можете скористатися Засіб експортування Git у Weblate для автоматизації процесу.
Якими є варіанти надсилання змін назад до основного сховища?¶
Це значним чином залежить від ваших налаштувань — Weblate є доволі гнучким у цьому сенсі. Ось приклади деяких варіантів робочого процесу, яким можна скористатися у Weblate:
Weblate автоматично надсилає і об’єднує зміни (див. Як створити автоматизовану процедуру?).
Ви наказуєте Weblate надіслати зміни вручну (це потребує доступ до запису до основного сховища).
Хтось вручну об’єднує зміни з сховища git Weblate до основного сховища.
Хтось перезаписує журнал, який створюється Weblate (наприклад, шляхом вилучення внесків із об’єднанням), об’єднує зміни і повідомляє Weblate, що слід відновити початковий стан у основному сховищі.
Звичайно ж, ви можете використовувати будь-яке поєднання описаних вище варіантів.
Як обмежити доступ Weblate лише перекладами без надання системі доступу до початкового коду?¶
Ви можете скористатися командою git submodule для відокремлення перекладів від початкового коду, лишаючи їх під керуванням системи керування версіями.
Створіть сховище із вашими файлами перекладів.
Додайте його як підлеглий модуль до вашого коду:
git submodule add git@example.com:project-translations.git path/to/translations
Пов’яжіть Weblate із цим сховищем — йому більше не знадобиться доступ до сховища, яке містить ваш початковий код.
Ви можете оновлювати основне сховища додаванням перекладів з Weblate за допомогою такої команди:
git submodule update --remote path/to/translations
Щоб дізнатися більше, будь ласка, ознайомтеся із документацією до git submodule.
Як перевірити, чи правильно налаштовано мій Weblate?¶
До складу Weblate включено набір перевірок налаштувань, підсумки яких можна бачити у адміністративному інтерфейсі — достатньо перейти за посиланням Звіт щодо швидкодії у адміністративному інтерфейсі або відкрити адресу, яка завершуватиметься /manage/performance/, безпосередньо.
Дивись також
Чому усі внески підписано Weblate <noreply@weblate.org>?¶
Weblate використовує Weblate <noreply@weblate.org> як комітер за замовчуванням для всіх комітів, який налаштовується за допомогою DEFAULT_COMMITER_EMAIL та DEFAULT_COMMITER_NAME. Це технічний ідентифікатор, який показує, що коміт було оброблено через Weblate.
Однак, автор кожного коміту коректно записується як окремий користувач, який зробив переклад (під час використання Git). Це означає, що ви можете побачити, хто фактично переклав кожен рядок, перевіривши поле автора коміту. Те саме стосується Mercurial; тільки Subversion не має такої можливості.
Примітка
У Git існує різниця між комітером (той, хто створив об’єкт коміта) та автором (той, хто вніс зміни). Weblate виступає в ролі комітера, зберігаючи при цьому індивідуальне посилання на перекладачів як авторів.
Для комітів, авторство яких неможливо визначити (наприклад, автоматичні зміни з анонімних пропозицій або результати машинного перекладу), автором встановлюється анонімний користувач. Ви можете налаштувати ім’я та електронну пошту анонімного користувача в ANONYMOUS_USER_NAME.
Дивись також
Як пересунути файли у сховищі без втрати журналу у Weblate?¶
Щоб зберегти журнал, коментарі або знімки вікон, які пов’язано із рядками, після зміни розташування файлів, вам слід забезпечити неможливість вилучення рядків на Weblate. Такі вилучення можуть статися, якщо сховище Weblate оновлено, але налаштування складника все ще вказує на старі файли. У таких ситуаціях Weblate припускає, що слід вилучити всі переклади.
Рішення полягає у виконанні синхронної дії у Weblate:
Заблокуйте відповідний складник у Weblate.
Внесіть усі зміни з черги і об’єднайте їх зі змінами в основному сховищі.
Вимкнути отримання вебхуків у Налаштування проєкту; це запобігає негайному перегляду змін у репозиторії Weblate.
Внесіть усі потрібні вам зміни до сховища (наприклад, за допомогою git mv), запишіть їх до основного сховища.
Змініть Налаштовування складників відповідно до нових налаштувань; після зміни конфігурації Weblate отримає оновлений репозиторій та помітить змінені розташування, зберігаючи при цьому існуючі рядки.
Розблокуйте складник і повторно увімкніть скрипти у налаштуваннях проєкту.
Підказка
Перед такими руйнівними змінами може бути корисним виконання Резервне копіювання на рівні проєктів.
Користування¶
Як рецензувати переклади інших користувачів?¶
У Weblate передбачено підтримку кількох робочих процесів з рецензування, див. Процеси перекладу.
Ви можете підписатися на будь-які зміни, внесені в Сповіщення, а потім перевіряти внески інших, щойно вони надходять електронною поштою.
Передбачено особливий інструмент, панель його розташовано у нижній частині панелі перекладу. На цій панелі ви можете вибрати навігацію перекладами, які виконано іншими користувачами, починаючи з вказаної дати.
Дивись також
Як надавати відгуки щодо початкового рядка?¶
На контекстних вкладках під перекладом ви можете скористатися вкладкою Коментарі, щоб надати відгук щодо початкового рядка або обговорити його із іншими перекладачами.
Дивись також
Як скористатися наявними перекладами під час перекладу?¶
Усі переклади у межах Weblate можна використовувати завдяки спільній пам’яті перекладів.
Ви можете імпортувати до Weblate наявні файли пам’яті перекладів.
Скористайтеся функціональними можливостями з імпортування для завантаження компіляції перекладів, пропозицій або перекладів, які потребують рецензування. Це оптимальний підхід для одноразового перекладу на основі компіляції або подібної бази даних перекладів.
Ви можете налаштувати tmserver із усіма базами даних перекладів, які у вас є, і надати змогу Weblate користуватися ними. Це корисно, якщо ви хочете скористатися ними декілька разів під час перекладу.
Іншим варіантом є переклад усіх пов’язаних перекладів в одному екземплярі Weblate, що забезпечить автоматичне поширення перекладів з одного складника до інших.
Чи оновлює Weblate файли перекладів між перекладами?¶
Weblate намагається звести до мінімуму зміни у файлах перекладів. Для деяких форматів файлів це, на жаль, може призвести до переформатування файла. Якщо ви хочете зберегти бажане для вас форматування, будь ласка, скористайтеся для цього скриптом попередньої обробки даних.
Дивись також
Як об’єднати оновлений POT-файл з перекладами PO?¶
Див. Оновлення файлів мови перекладу для отримання інформації про оновлення PO-файлів у разі зміни шаблону POT.
Звідки беруться визначення мов і як можна додати власне визначення?¶
Базовий набір визначень мов включено у пакунки Weblate і Translate-toolkit. У цьому наборі є дані понад 150 мов разом із даними щодо форм множини та напрямку запису тексту.
Ви можете визначати власні мови за допомогою адміністративного інтерфейсу — вам достатньо вказати дані щодо цієї мови.
Дивись також
Чи може Weblate підсвічувати зміни у неточно перекладеному рядку?¶
У Weblate передбачено підтримку цієї можливості, але програмі потрібні дані для показу відмінностей.
Для файлів PO Gettext вам слід передати параметр --previous до команди msgmerge при оновленні файлів PO. Приклад:
msgmerge --previous -U po/cs.po po/phpmyadmin.pot
Для одномовних перекладів Weblate може знаходити попередній рядок за ідентифікатором, тому програма показує різниці автоматично.
Чому Weblate показує застарілі рядки перекладу, хоча шаблон перекладу було оновлено?¶
Weblate не виконує ніяких дій із файлами перекладу, окрім надання перекладачам можливості перекладати ці файли. Тому файли перекладів не буде оновлено, якщо буде оновлено шаблон або початковий код, на основі якого формується шаблон. Вам просто слід зробити це вручну і записати зміни до сховища, Weblate підхопить зміни автоматично.
Примітка
Зазвичай, варто об’єднувати зміни, які було внесено у Weblate до оновлення файлів перекладу, інакше, зазвичай, виникатимуть конфлікти, які доведеться усувати.
Як перейменовувати файли перекладів?¶
При перейменуванні файлів у сховищі Weblate може зареєструвати це як вилучення та додавання файлів. Це може призвести до втрати журналу зміни рядків, коментарів та пропозицій.
Щоб уникнути цього, виконайте перейменування у такий спосіб:
Заблокуйте складник перекладу у Керування локальним сховищем керування версіями.
Запишіть зміни з черги до Керування локальним сховищем керування версіями.
Злийте зміни у Weblate до сховища основного коду.
Вимкніть отримання оновлень за допомогою скриптів, скориставшись Увімкнути обробники.
Виконайте перейменування файлів у сховищі.
Оновіть налаштування складника, щоб вони відповідали новим назвам файлів.
Увімкніть скрипти оновлення і розблокуйте складник.
Підказка
Перед такими руйнівними змінами може бути корисним виконання Резервне копіювання на рівні проєктів.
Вирішення проблем¶
Іноді запити не виконуються із повідомленням про помилку «відкрито забагато файлів»¶
Таке трапляється, якщо ваш сховище Git розростається й у вас стає забагато файлів. Стискання сховища Git має усунути проблему.
Найпростішим способом зробити це є така команда:
# Go to DATA_DIR directory
cd data/vcs
# Compress all Git repositories
for d in */* ; do
pushd $d
git gc
popd
done
Дивись також
При спробі доступу до сайта браузер показує повідомлення про помилку «Bad Request (400)»¶
Найімовірнішою причиною є помилкове значення змінної ALLOWED_HOSTS. У цій змінній має містити список усіх назв вузлів, яким ви хочете дозволити доступ до вашого Weblate. Приклад:
ALLOWED_HOSTS = ["weblate.example.com", "weblate", "localhost"]
Дивись також
Що означає повідомлення «Знайдено кілька файлів для однієї мови (en)»?¶
Таке типово трапляється, якщо у вас є файл перекладу початковою мовою. Weblate стежить за початковими рядками і резервує для цього каталог початкової мови. Додатковий файл початковою мовою не обробляється.
Якщо потрібен переклад мовою оригіналу, будь ласка, змініть Початкова мова у налаштуваннях компонента. Ви можете використовувати English (Developer) як мову оригіналу або скористатися Шлюз якості для початкових рядків.
Якщо файл перекладу для початкової мови є непотрібним, будь ласка вилучіть його з сховища.
Якщо файл перекладу для початкової мови є бажаним, але Weblate має його ігнорувати, будь ласка, скоригуйте Фільтр мов, щоб виключити його.
Підказка
Ви можете отримати подібне повідомлення про помилку і для інших мов. У такому випадку найімовірнішою причиною є те, що з однією мовою у Weblate пов’язано кілька файлів.
Це може бути наслідком того, що паралельно використано застарілі і нові коди мов (ja і jp для японської) або паралельно вжито код мови із кодом країни і загальний код (fr і fr_FR). Докладніше про це у розділі Обробка кодів мов.
Можливості¶
Чи передбачено у Weblate підтримку інших систем керування версіями, окрім Git і Mercurial?¶
Weblate currently does not have native support for anything other than Git (with extended support for Запити щодо злиття GitHub, Gerrit review requests, and Subversion) and Mercurial, but it is possible to write backends for other VCSes.
Крім того, у Weblate передбачено підтримку дій без системи керування версіями, див. Локальні файли.
Примітка
Для вбудованої підтримки інших систем керування версіями Weblate потрібне використання розподіленої системи керування версіями. Ймовірно, Weblate може працювати із будь-чим, окрім Git та Mercurial, але хтось має реалізувати підтримку відповідної системи керування версіями.
Дивись також
Як Weblate зберігає авторство перекладів?¶
Усі зміни, які внесено на Weblate, надсилаються до системи керування версіями від імені перекладачів. У такий спосіб забезпечується належне авторство кожної окремої зміни. Ви можете стежити за змінами за допомогою стандартних інструментів вашої системи керування версіями точно так само, як ви це робите з кодом.
Крім того, якщо таку підтримку передбачено у форматі файлів перекладу, буде оновлено заголовки файла — до них буде включено ім’я перекладача.
Дивись також
Чому Weblate примусово показує усі файли PO у одній ієрархії?¶
Weblate було розроблено із припущенням, що кожен файл PO представлено у системі окремим складником. Це зручно для перекладачів — вони знають, що саме перекладають.
Змінено в версії 4.2: Перекладачі можуть перекласти всі складники проєкту певною мовою в цілому.
Чому Weblate використовує дивні коди мов, зокрема sr_Latn та zh_Hant?¶
Ці коди мови визначено RFC 5646 для удосконалення індикації різних мов. Раніше для цього помилково використовувалися модифікатори (для варіантів @latin) або коди країн (для китайської).
Weblate може працювати із застарілими кодами мов і пов’язувати їх із кодами поточної версії. Наприклад, sr@latin буде оброблено як sr_Latn, а zh@CN як zh_Hans.
Примітка
Типово, Weblate використовує коди мов у стилі POSIX, із підкреслюваннями. Див. Визначення мов, щоб дізнатися більше.
Дивись також