+ к этому накрутить версионирование и когда появляется новая версия оригинального текста - можно создавать таску на перевод

У меня сейчас есть интересная дилемма по организации работы над переводом. Чтобы её объяснить, сначала расскажу про механику перевода.

Перевод устроен так: исходный текст нарезается на единицы перевода (translation units, TU). Заголовки, абзацы, пункты списков, ячейки в таблицах. Каждый юнит переводится целиком. Переводить куски текста большего размера — неэффективно, а если нарезать ещё меньше, то потеряется смысл.

Внутри системы переводы хранятся в структуре ключ-значение (ассоциативный массив, dictionary, map). Оригинальный текст — это ключ, а перевод — значение.

При сборке документации на переводном языке на место каждого юнита подставляется текст перевода. Но если перевода нет, остаётся оригинальный текст. Не нашли значение по ключу — используем сам ключ.

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

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

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

А ещё можно вычитывать оригинал до перевода. Тогда у переводчика меньше работы, но мы добавляем техписателям срочных задач, которые блокируют работу над переводом. И эти задачи конкурируют за время с другими, более важными задачами по документации.

Кажется, что оба варианта плохи, но второй — хуже. А можно как-то иначе? Отдать пруфрид переводчику или другому внештатному сотруднику? Что бы вы сделали?

У меня сейчас есть интересная дилемма по организации работы над переводом. Чтобы её объяснить, сначала расскажу про механику перевода.

Перевод устроен так: исходный текст нарезается на единицы перевода (translation units, TU). Заголовки, абзацы, пункты списков, ячейки в таблицах. Каждый юнит переводится целиком. Переводить куски текста большего размера — неэффективно, а если нарезать ещё меньше, то потеряется смысл.

Внутри системы переводы хранятся в структуре ключ-значение (ассоциативный массив, dictionary, map). Оригинальный текст — это ключ, а перевод — значение.

При сборке документации на переводном языке на место каждого юнита подставляется текст перевода. Но если перевода нет, остаётся оригинальный текст. Не нашли значение по ключу — используем сам ключ.

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

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

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

А ещё можно вычитывать оригинал до перевода. Тогда у переводчика меньше работы, но мы добавляем техписателям срочных задач, которые блокируют работу над переводом. И эти задачи конкурируют за время с другими, более важными задачами по документации.

Кажется, что оба варианта плохи, но второй — хуже. А можно как-то иначе? Отдать пруфрид переводчику или другому внештатному сотруднику? Что бы вы сделали?

Оригинальный текст как ключ это плохое решение. Представление о том, что в переводе фрагменты переведенного однозначно соответствуют фрагментам переводимого - неверно.

А через MT может до 100% догнать?

Пользуясь случаем, хочу поделиться системой перевода, в которой прям хорошо учтены отличия языков
https://www.projectfluent.org/

А можно, если кратко, в чём преимущества перед ICU, или ARB, скажем?

Ну, Гугл его продвигает как глобальный, но да, сейчас это Flutter в основном.

Посмотрел спецификации - референсы выглядят полезно, но привязывают переводы к общему контексту. Функции выглядят опасно. Собственный текстовый формат вместо JSON или YAML кажется избыточным решением - они подразумевают, что переводчик будет работать в блокноте вместо специализированного интерфейса?

Честно говоря, у меня из-за этого сразу скепсис возник(

Команда Flutter'а много странных вещей пытается сделать глобальными: Dart, Flutter for Web (Hummingbird)

А, я к чему про скепсис

Есть у кого-нибудь опыт использования использования ARB вне Flutter'а?

У меня сейчас есть интересная дилемма по организации работы над переводом. Чтобы её объяснить, сначала расскажу про механику перевода.

Перевод устроен так: исходный текст нарезается на единицы перевода (translation units, TU). Заголовки, абзацы, пункты списков, ячейки в таблицах. Каждый юнит переводится целиком. Переводить куски текста большего размера — неэффективно, а если нарезать ещё меньше, то потеряется смысл.

Внутри системы переводы хранятся в структуре ключ-значение (ассоциативный массив, dictionary, map). Оригинальный текст — это ключ, а перевод — значение.

При сборке документации на переводном языке на место каждого юнита подставляется текст перевода. Но если перевода нет, остаётся оригинальный текст. Не нашли значение по ключу — используем сам ключ.

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

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

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

А ещё можно вычитывать оригинал до перевода. Тогда у переводчика меньше работы, но мы добавляем техписателям срочных задач, которые блокируют работу над переводом. И эти задачи конкурируют за время с другими, более важными задачами по документации.

Кажется, что оба варианта плохи, но второй — хуже. А можно как-то иначе? Отдать пруфрид переводчику или другому внештатному сотруднику? Что бы вы сделали?

Если что, этот вопрос не про технологии, он про управление процессом разработки документации и её перевода.

Есть цель: хорошие доки на английском, проверенные на корректность и язык. Они полностью переведены на русский и перевод тоже проверен на корректность и язык.

Такая цель никогда не будет достигнута на 100%, потому что продукты постоянно развиваются и документация тоже должна идти вперёд. Поэтому цель на самом деле другая: непрерывно писать и переводить документацию по продуктам, делая самое важное с использованием ограниченных ресурсов, поддерживая установленный уровень качества и выполняя другие обязательства.

Есть ресурсы, которыми эта цель достигается: техписатели, переводчики, ревьюеры со стороны разработки. Есть производственный процесс и его этапы: исследование задачи, разработка документации, ревью, перевод, обновление.

Эти этапы можно выстроить по-разному. Дать больше работы тем или другим. Думаю, что нужно следовать теории ограничений: находить узкие места в критической цепи, разгружать и усиливать их. Но как это делать, когда есть несколько направлений работы? И можем ли мы рассматривать себя как изолированную систему и оптимизироваться без учета всей разработки продуктов? Наверное, не можем.

Всё это мне пока что очень непонятно, но очень интересно. Давайте соберемся и обсудим? Например, в эту пятницу, 19 марта, 16:00 Мск. Ссылку на созвон кину в чат незадолго до встречи.