а если документацию хотят не  только на сайте?

в хелпе и саппорте?

вскорее "встроенная справка" ака хелп

Ваши разработчики уже что-то используют для управления содержимым. Это с большой вероятностью GitHub, GitLab или Bitbucket. Учитесь работе с гитом у разработчиков, они уже нашли и внедрили для себя кучу удобных вещей.

DITA :D

типичная проблема коммуникации, надо поговорить и договориться, как всем удобно будет

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

Расскажите, как вы раньше переводили?

Мы выгружаем переводы в формат Gettext (.po) и его отправляем Crowdin, там очень подробные отчеты есть.

Говорю же. Раньше  небыло гита. раньше была "своя база", в которой для каждого описания был идентификатор и признаки. можно было описание точно определить по его идентификатору (и еще коду в базе) и состояние понять, по признакам (требует когда описания, когда снова требует перевод, когда требуется перенос в след. версию) + хранились основания изменений, и например по номеру задачи можно было понятЬ,что изменилось по ней.. А по признакам можно было получить оперативную информацию (что надо переводиь, что надо переносить, что надо еще документировать). такого рода. Из этой базы у нас можно выгрузить во все "нужные на момент форматы" - во встроенную справку, да хоть html, хоть даже word). не могу сказать, что база была идеальной (при параллельной разработки версий иногда даже не спасало наличие этих самых кодов), но всё ещё можно было  определить, как описания объектами соотносятся между версиями продукта

но новая команда разработки решила, что markdown + git это модно стильно молодежно, а как этим всем управлять (когда процесс уже поставлен) посоны благополучно забили.

"своя база" с признаками из этого описания мне кажется максимально непонятной хтонью. может только мне )

как вариант - встретиться с разрабами и объяснить какие процессы нужны

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

Если всё-таки вам нужны какие-то идеи, а не просто эмоциональная поддержка, я бы тоже посоветовала пообщаться с вашими коллегами.
Узнать у них, почему они решили делать иначе, как это поможет компании, какую проблему решает переход на гит и т.д. Рассказать им о текущем процессе, о ваших целях и потребностях, что вам важно и почему (например, важно получать отчёты для перевода, потому что ...). Поделиться своей болью, как их решение ломает ваш процесс. И попробовать совместно найти общее решение, которое устраивало бы всех. Возможно, они знают, как помочь вам, просто не понимают, что такая помощь нужна, потому что никто им об этом не сказал.

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

Спасиб, сегодня как раз будем разговаривать с разрабами.

Но вот на десерт вопрос - куча текста в маркдауне. Как можно оценить его объем, например, чтобы прикинуть время на вычитку?

число знаков?

а раньше как прикидывали? два текста одинаковой длины бывает нужно читать разное время

Удачи вам! Желаю найти решение, которое бы вас всех удовлетворяло. 😉