Де переклади?

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

Переклади є невід’ємною частиною коду

Переклади — це файли, які є невід’ємною частиною початкового коду, необхідного для запуску програми. Формат файла, що містить переклади, залежить від інструментів, які використовує команда розробників. Щоб отримати уявлення про основні формати файлів, ознайомтеся зі списком форматів, підтримку яких передбачено на платформі перекладу Weblate. Загалом, найчастіше використовують формат Gettext для зібраного програмного забезпечення, а формати Json — для інтернет-програм. Кожен файл має свої переваги та недоліки, це стосується сфери інтернаціоналізації програмного забезпечення, часто скорочено i18n.

Вплив на перекладацьку роботу

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

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

Ось де починаються складнощі: існують принаймні тисячі проєктів безкоштовного програмного забезпечення, якщо не сотні тисяч. Є тисячі мов, чи можемо ми мати достатньо перекладачів на кожну мову, щоб стежити за всіма цими проєктами? Звичайно ні.

Процедура інтеграції перекладу

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

Придатний до перекладу… але архаїчний!

Jitsi Meet — це програмне забезпечення для онлайн-відеоконференцій, упочатковому коді якого тека lang містить один файл json для кожної мови.

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

За кілька хвилин я знайшов екстремальний випадок — цей запит, який чекав більше 8 місяців. Однак тим часом файл, що містить рядки для перекладу програмного забезпечення вже змінено 19 разів і вже випущено 8 версій без перекладу!

Ні у readme, ні у [настановах щодо участі]( https://jitsi .github.io/handbook/docs/dev-guide/dev-guide-contributing/) немає відомостей про те, як перекладати.

Мовні спільноти з великою кількістю людей можуть витратити необхідний час завдяки кількості учасників (і все одно…), усі інші залишаться осторонь, а програмне забезпечення пропонуватиме лише найновіші переклади мови, які вже і без того достатньо представлені. Щоб бути в курсі змін, можливо, вам потрібно буде підписатися на зміни проєкту github.

Ефективність такого способу роботи є сумнівною. Хоча можемо вітати зусилля, спрямовані на переклад програмного забезпечення, про відсутність уваги до такого типу внеску варто пошкодувати . Я не брав участі в обговоренні з командами Jitsi Meet, так було не завжди, платформа перекладу вже використовувалася в минулому.

Зрозуміло… але дуже специфічно для GNOME

Проєкт GNOME використовує подібну версію, але орієнтовану на потреби команд перекладачів. Щоб надіслати переклад у кінцеве програмне забезпечення, обов’язково використовується git. Однак є доступний інструмент для перекладачів, який дозволяє їм точно знати, що потрібно перекласти, і співпрацювати. Крім того, довгий список програмного забезпечення в екосистемі GNOME дотримується однакового темпу нових випусків і однакових робочих процесів. Таким чином, процес недосконалий і ручний, але інструменти дозволяють значно зменшити витрати на керування для учасників.

Ефективно… але дуже специфічно для Mozilla

Проєкт Mozilla вважає переклад ключовою темою своєї діяльності. Якщо ви хочете зробити свій внесок, ви можете перейти на платформу перекладу Pontoon (проєкт організований у команди перекладів).

Дізнатися, що можна перекладати, легко, і також легко знайти контакти, щоб відповісти на запитання.

Цей проєкт величезний, вам буде важко зрозуміти кроки між платформою перекладу та програмним забезпеченням, але чи це серйозно? Працює добре, дати випуску ПЗ відомі, пріоритети визначені. Ви втратите деякий час на створення команди перевірки та процесів, усі інструменти є специфічними для проектів Mozilla, але загалом це досить ефективно.

Автоматизована і загальна, сучасна свобода

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

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

Чудовий приклад: платформа перекладу Weblate є прикладом для наслідування, все підключено та автоматизовано. Є багато змін перекладу і [змін, що впливають на переклад](https://hosted.weblate.org/ changes/ browse/weblate/?action=13&action=30&user=&period=), які легко знайти.

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

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

Висновки

Взаємозв’язок між технічним життям проєкту та перекладами має вирішальне значення для ефективності процесів перекладу.

Є інструменти, наповнені цікавими функціями та засобами автоматизації, які спрощують життя кожного.

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

Але що відбувається, коли проєкт не випускає нових версій? Як відродити сплячий проєкт? Це буде темою майбутнього допису.