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

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

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

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

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

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

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

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

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

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

volatile primary key? месье знают толк в извращениях!

он же на то и primary, чтобы быть неизменным

Обычно с этим помогают CAT tools. Типа Smartcat

(но я ненастоящий сварщик, не работал с CAT-ами и не знаю их теории и фундаментальных ограничений)

Вроде бы логичное и понятное поведение. У меня sphinx c .po файлами аналогичным образом работает. Если изменения небольшие, gettext умеет находить похожие переводы и отмечать их как fuzzy (https://www.gnu.org/software/gettext/manual/html_node/Fuzzy-Entries.html). Здесь, насколько я понимаю, используется какое-то самописное решение, поэтому поиск похожих записей придётся прикручивать самостоятельно.
Далее возникает чисто организационная задача: мониторинг непереведённых юнитов и обнаруженных fuzzy-переводов.

Могу привести аналогию из Django (babel)

Каждому кусочку текста присваивается уникальный id, например «welcome text screen 1», а дальше тексты на всех языках ссылаются на этот id

Или это immutable translation unit? 😄
Т.е. относимся к изменённому исходному тексту как к совершенно новому объекту

когда-то я писал десктопные приложения на .NET, там точно так же было

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

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

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

ахаха, опубликовался отложенный пост, который был не готов к публикации

люблю такое

пойду что ли доведу его до ума )

Используем, там есть память переводов, но она не делает всю работу за нас. В параграфе могло поменяться true на false, изменение небольшое, но нельзя же его вслепую применить и жить с этим.

Да-да, у нас именно Sphinx. Fuzzy он находит через расстояние Левенштейна, но то же самое есть в CAT (мы используем Crowdin). Но это только помощь переводчику. Строки всё равно временно слетают.

Мониторинг есть, мы точно знаем, где и что не переведено. Вот прямо сейчас переведено 60% документации, 170 000 слов из 283 000. Работа переводчика улучшает этот показатель, работа писателей ухудшает.

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

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

Sphinx/Gettext умеет генерировать UUID, впрочем. Может быть, это помогло бы с технической стороны.