NovМиграция данных должна проверять пары RU и EN после переноса
Почему успешное копирование записей ещё не означает успешную миграцию двуязычного каталога и какие смысловые связи важно проверить после переноса.
Материал отражает практическую позицию указанного эксперта. Как готовятся и проверяются публикации — в редакционной политике NovAsia.
Миграция редко выглядит опасной в момент, когда счётчик показывает: все записи перенесены. Опасность появляется позже, когда человек открывает конкретный объект, переключает язык и обнаруживает, что русская версия относится к одной записи, английская — к другой, либо одна из них сохранила старый статус. Формально база заполнена. Пользовательская сущность при этом раскололась.
В двуязычном каталоге я бы считал единицей проверки не отдельную страницу, а пару представлений одного объекта. Тексты могут отличаться по композиции и языку, но материальная идентичность должна пережить перенос: объект остаётся тем же объектом, проект — тем же проектом, а существенные поля продолжают описывать одну реальность.
Переносить нужно сущность, а не набор независимых страниц
Представим условную миграцию, в которой каждая языковая запись копируется отдельно. Русская карточка получает новый внутренний идентификатор и корректно связывается с проектом. Английская тоже переносится, но её связь остаётся на старой записи. Обе страницы открываются, заголовки выглядят нормально, ссылки не ломаются. Обычная проверка «все ли адреса доступны» может пройти успешно.
Ошибка проявится только через пользовательское действие: переключение языка, сравнение, сохранение или открытие связанного документа. В этот момент человек может попасть на другую фазу проекта, увидеть устаревшее состояние либо потерять ранее сохранённый контекст.
Поэтому перед миграцией полезно определить, что именно является устойчивой сущностью. Для платформы недвижимости это может быть проект, корпус, конкретная квартира, застройщик, источник, документ или другой объект данных. Я не хочу назначать техническую схему без знания конкретной архитектуры. Смысловой принцип проще: языковые версии не должны становиться двумя независимыми объектами только потому, что у них разные тексты и адреса.
Особенно легко ошибиться там, где у сущности есть история. Название могло измениться, старый маршрут — сохраниться, статус — обновиться, а изображения — получить новые подписи. Миграция должна перенести не только видимые строки, но и отношения, которые позволяют человеку продолжить пользоваться той же записью после изменений.
После переноса сверяются не все слова, а инварианты
Русская и английская статьи или описания не обязаны совпадать предложениями. Более того, для хорошего двуязычного продукта это часто было бы признаком механического перевода. Проверять нужно другое: поля и отношения, которые не имеют права расходиться из-за языка.
Я начал бы с идентичности сущности и её жизненного состояния. Далее — материальные числовые поля, валюта, площадь и единицы, если они являются общими данными. Потом — связи: к какому проекту относится запись, какие документы и изображения принадлежат ей, какой источник лежит под существенным утверждением, какая дата относится к данным. Набор зависит от продукта, но логика одна: текст можно локализовать, факт нельзя случайно раздвоить.
Условный пример хорошо показывает границу. В русской версии проект описан как строящийся и содержит свежую дату проверки. В английской после миграции осталась старая запись «готов». Это не редакционное различие и не свобода локализации. Одна из версий вводит пользователя в заблуждение или как минимум требует выяснения. Проверка пары должна поднять такой конфликт независимо от того, обе ли страницы открываются без ошибок.
Есть поля, которые могут честно различаться. Например, метаописание, структура авторского текста или пояснение термина под аудиторию. Нельзя превращать проверку паритета в требование полного зеркала. Иначе технический контроль начнёт уничтожать самостоятельность языковых редакций. Нужна заранее понятная граница между общими данными и локальным представлением.
Самый полезный тест начинается после «успешной» миграции
Я проверял бы миграцию не только из административной панели, но и по реальным переходам пользователя. Открыть объект на русском, сохранить его, перейти в сравнение, переключить язык, вернуться на страницу, открыть связанный материал. Затем повторить путь с другой стороны. Это не универсальный тестовый сценарий для любой системы, а способ проверить саму идею пары.
Такая проверка ловит не только отсутствующую ссылку между языками. Она показывает потерю состояния, смешение сущностей и несовпадение материала, которое появляется на границе компонентов. Именно поэтому миграция данных — это не задача «скопировать строки», а задача сохранить смысловые связи.
После переноса полезен и выборочный контроль сложных случаев: проекты с переименованием, несколькими фазами, архивным статусом, разными источниками или историей исправлений. Простые записи часто переживают миграцию хорошо. Ошибки прячутся там, где связь важнее самого текста.
Закрывать миграцию по одному числу «перенесено сто процентов записей» мне кажется слишком слабым критерием. Он подтверждает объём операции, но не пользовательскую целостность. Готовность наступает тогда, когда пары остаются парами, существенные факты согласованы, переход между языками ведёт к той же сущности, а различия там, где они есть, объясняются редакцией, а не потерянной связью.