Где переводы?

После объяснения того, что большая часть планеты не говорит по-английски, затем [объяснения того, как внести свой вклад в распространение Fedora] (2020-07-03-contribute-to-fedora.md), давайте посмотрим, где находятся переводы программного обеспечения.

Переводы являются неотъемлемой частью кода

Переводы — это файлы, являющиеся неотъемлемой частью исходного кода, необходимые для запуска программы. Формат файла, содержащего переводы, различается в зависимости от инструментов, используемых командой разработчиков. Чтобы получить представление об основных форматах файлов, интересен список форматов, поддерживаемых платформой перевода 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 показывает пример для подражания, всё подключено и автоматизировано. Изменений переводов много, а изменения, влияющие на переводы, легко найти.

Многие проекты используют Weblate, и это тот выбор, который вам следует сделать, независимо от вашего контекста. В экосистеме платформ перевода Weblate стал таким же очевидным и эффективным, как git для управления исходным кодом в разработке программного обеспечения.

Если ваш проект предоставляет эту платформу, то вы предоставляете возможность действия для языкового вклада, и, заботясь об отношениях с этим широким сообществом, у вас будут хорошие шансы получить инструмент, переведённый на многие языки.

Заключение

Взаимосвязь между технической жизнью проекта и переводами имеет решающее значение для эффективности процессов перевода.

Существуют инструменты, полные интересных функций и автоматизации, чтобы облегчить жизнь всем.

Остаётся только за командами разработчиков взять их на вооружение, чтобы программное обеспечение содержало всё больше переводов и поддерживало всё большее количество языков.

Но что происходит, когда проект не выпускает новые версии? Как компенсировать «спящий» проект? Это будет темой будущей статьи.