Память переводов за пятнадцать лет: как не остаться заложником программы

MAATRIX

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

Память переводов как отдельный профессиональный актив

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

Ценность этой базы не в объёме файла — TM-файлы это обычный текст в XML-разметке, и даже накопленные за много лет, они редко становятся по-настоящему тяжёлыми (ориентировочно — десятки, много сотен мегабайт, а не гигабайты). Ценность в том, что переделать эту работу заново нельзя. Можно заново перевести текст, но нельзя заново прожить пятнадцать лет согласований терминологии с тем же клиентом.

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

Как переводчик становится заложником программы: механизм и реальные сценарии

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

Сначала вы устанавливаете CAT-программу, потому что она нужна для работы с конкретным агентством. Заводите в ней проекты, программа создаёт TM в собственном внутреннем формате базы данных. Дальше вы включаете облачную синхронизацию — удобно работать с ноутбука и с рабочего компьютера. TM теперь физически лежит на серверах вендора, привязана к вашей учётной записи и вашей подписке.

Проходит несколько лет. TM разрастается, в ней уже терминология полутора десятков клиентов. И тут начинается реальный риск — не гипотетический, а вполне бытовой:

• Подписка прерывается. Забыли продлить, слетела привязанная карта, у вендора изменилась модель лицензирования и старый тариф больше не продаётся — а доступ к облачной синхронизации завязан именно на активную подписку.
• Учётную запись блокируют или ограничивают из-за спорного нарушения условий использования, а разбирательство с поддержкой растягивается на недели, в течение которых работать нечем.
• Компьютер выходит из строя, а TM хранилась только локально, без резервной копии — потому что «облако же есть», хотя на деле синхронизировался только рабочий проект, а не полный архив.
• Лицензию оформлял работодатель или агентство на своё юрлицо, и при завершении контракта доступ к инструменту закрывается вместе с накопленной в нём базой — даже если фактически базу нарастили лично вы.
• Функция полного экспорта базы урезана или платная в том тарифе, на котором вы сидите годами, и вы узнаёте об этом именно в тот момент, когда экспорт нужен срочно.

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

Открытые форматы TMX, XLIFF, TBX — общий язык вместо привязки к вендору

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

TMX (Translation Memory eXchange) — открытый XML-стандарт для хранения и обмена памятью переводов. Практически все CAT-программы, включая узкоспециализированные и корпоративные, умеют импортировать и экспортировать TM именно в TMX — потому что это отраслевой стандарт обмена, а не формат конкретного производителя.

XLIFF (XML Localization Interchange File Format) — открытый формат для двуязычных файлов перевода, тоже широко поддерживаемый индустрией.

TBX (TermBase eXchange) — открытый стандарт для терминологических баз, если вы ведёте отдельный глоссарий по клиенту или отрасли.

Смысл в том, что если ваша мастер-копия хранится в этих форматах — она читаема и переносима сама по себе, независимо от того, какой программой вы пользуетесь сейчас и будете пользоваться через пять лет. Внутренний формат TM конкретной CAT-программы может быть проприетарным и закрытым — но экспорт в TMX практически всегда есть, и именно этот экспорт нужно превратить в привычку, а не в разовую операцию на случай катастрофы.

Здесь важно честно оговорить ограничение: если TM создавалась и синхронизировалась годами исключительно внутри облачного аккаунта вендора, разовый экспорт — это снимок на конкретный момент, а не непрерывная синхронизация. Чтобы независимая копия оставалась актуальной, экспорт нужно делать регулярно, а не один раз «для галочки».

Свой сервер: независимая копия памяти переводов

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

Логика простая: рабочая CAT-программа остаётся какой была — вы продолжаете переводить в привычном инструменте. Но параллельно на арендованном сервере хранится мастер-копия TM/TB в открытых форматах, организованная так, чтобы в ней можно было ориентироваться без всякой CAT-программы вообще — обычным просмотром файлов.

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

/translation-memory/
├── client-a/
│   ├── en-ru/
│   │   ├── client-a-en-ru-2024.tmx
│   │   ├── client-a-en-ru-2025.tmx
│   │   └── glossary-client-a.tbx
│   └── de-ru/
├── client-b/
│   └── en-ru/
├── general/
│   └── legal-en-ru-accumulated.tmx
└── README.md

Файл README.md в корне — не формальность: через десять лет вы или тот, кто унаследует архив, должны понимать, что где лежит и по какому принципу собрано, без необходимости вспоминать логику пятилетней давности.

Доступ к серверу и синхронизацию можно организовать несколькими способами в зависимости от привычек:

• SFTP/rsync — самый простой вариант, если вы вручную или по расписанию выгружаете экспортированные TMX-файлы на сервер:

rsync -avz --progress ~/cat-exports/ user@your-server:/srv/translation-memory/

• WebDAV через Nextcloud, если хочется файлового интерфейса, доступного и с ноутбука, и с телефона, и синхронизации между несколькими рабочими машинами без ручных команд.
• Syncthing, если не хочется держать отдельный веб-сервис, а нужна прямая P2P-синхронизация папки между вашими устройствами и сервером как ещё одним узлом.

Отдельно стоит вопрос конфиденциальности: память переводов часто содержит фрагменты документов, на которые распространяется NDA с клиентом. Держать такие данные в общем облачном аккаунте, условия которого вы не контролируете, — само по себе риск. На собственном сервере вы задаёте правила сами: диск шифруется (LUKS на Linux — стандартный вариант), доступ только по SSH-ключу, передача файлов только по SFTP или через TLS, никаких общих ссылок «на всякий случай».

Версионирование и резервное копирование: чтобы годы работы не исчезли за один вечер

Перенести TM на свой сервер — только половина дела. Вторая половина — не потерять её уже там, потому что диск сервера тоже может выйти из строя, а случайно перезаписанный TMX-файл без истории версий не восстановить.

Поскольку TMX и XLIFF — это текстовые XML-файлы, они хорошо подходят для версионирования через Git: изменения диффятся построчно, можно откатиться к состоянию на любую дату, видно, когда и насколько выросла база по конкретному клиенту.

cd /srv/translation-memory
git init
git add .
git commit -m "Снимок памяти переводов на конец августа 2026"

Дальше — коммит после каждой значимой выгрузки, например по завершении крупного проекта. Единственная оговорка: если файлы TM крупные и меняются целиком (а не построчно), история Git может разрастаться быстрее, чем хотелось бы — тогда имеет смысл периодически делать git gc или ограничивать глубину истории для самых объёмных файлов.

Git закрывает вопрос осмысленных версий, но не закрывает вопрос катастрофы — сгоревшего диска, ошибки администрирования, случайного rm -rf не в той папке. Для этого нужен независимый бэкап за пределами самого сервера, желательно шифрованный и с дедупликацией, чтобы не платить за хранение одного и того же архива по кругу:

borgbackup init --encryption=repokey /mnt/backup-storage/tm-archive
borgbackup create /mnt/backup-storage/tm-archive::tm-{now:%Y-%m-%d} /srv/translation-memory

Разумная схема для переводчика-фрилансера, у которого нет выделенного системного администратора: автоматический бэкап по расписанию через cron раз в неделю, плюс ручной коммит в Git после каждого крупного проекта. Это не требует ежедневного внимания, но исключает сценарий «полтора года без бэкапа, потому что руки не дошли настроить».

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

Как перенести накопленную память переводов: пошаговый план

Перенос лучше делать не авральным вечером «пока не поздно», а спокойно, как плановую задачу.

1. Экспортируйте текущую TM в TMX. Функция экспорта в большинстве CAT-программ находится в разделе управления памятью переводов или обслуживания базы — конкретное расположение пункта меню отличается от программы к программе, но сама возможность экспорта в TMX есть практически везде, включая базовые тарифы.
2. Проверьте кодировку экспортированного файла. Она должна быть UTF-8 — это стандарт для TMX, и большинство современных программ экспортируют именно так, но при работе со старыми базами полезно перепроверить, чтобы не потерять диакритику или кириллицу при дальнейшей обработке.
3. Разложите файлы по структуре — клиент, языковая пара, год — как в примере выше. Не сваливайте всё в один файл: так сложнее будет и версионировать, и находить нужный фрагмент базы позже.
4. Загрузите на сервер через rsync, SFTP или синхронизирующий клиент — на ваш выбор из перечисленных выше вариантов.
5. Настройте регулярный экспорт вперёд, а не только разовый перенос накопленного архива. Раз в месяц (или после каждого крупного проекта) — экспорт свежей TM и синхронизация с сервером. Это может быть просто напоминание в календаре, если не хочется автоматизировать процесс скриптом.
6. Проверьте обратную совместимость. Импортируйте копию TMX с сервера обратно в CAT-программу (в тестовый, отдельный проект) и убедитесь, что сегменты подтягиваются корректно. Это единственный способ по-настоящему убедиться, что перенос сработал, а не просто создал файл, который никогда не откроется.
7. Включите шифрованный бэкап сервера целиком, как описано выше, — независимая копия важна, но и её саму нужно от чего-то защищать.

Если у вас ещё не настроен сервер под фриланс-задачи в целом, есть смысл смотреть на это шире — не только под TM, но и под остальную инфраструктуру переводчика: собственную почту, черновики, каталог клиентских глоссариев. О том, как выбрать и настроить VPS под самозанятого и фрилансера, стоит почитать отдельно, если сервера пока нет вообще.

Если параллельно с памятью переводов вы думаете и о том, как переводить документы без выгрузки в сторонние сервисы (актуально при работе с конфиденциальными материалами), тема разбирается в статье про перевод документов на своём сервере без облака — она хорошо дополняет то, что описано здесь: TM хранит накопленный опыт, а собственный контур перевода закрывает вопрос конфиденциальности текущей работы.

Частые вопросы