Локализация данных, которые генерируются динамически

Question

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

Фон

Около четырех лет назад нам пришлось перевести наше приложение asp.net для наших клиентов в Мексике. Расширяемость и масштабируемость не были такой большой проблемой в то время (о да, я только что сказал эти ужасные слова), потому что у нас есть только американские и мексиканские клиенты.

Вместо того, чтобы использовать файлы ресурсов, мы заменили каждый фрагмент статического текста в нашем приложении некоторым типом серверного элемента управления (например, метка asp.net). Мы храним каждое английское слово в базе данных SQL. Мы добавили возможность переводить английский текст на другой язык, а также можем добавлять культурные изменения. Например, привет можно перевести на ¡hola! на одном языке и переопределить на ¡bueno! в другой культуре. Бизнес имеет полный контроль над этими переводами, потому что построит утилиты управления для них, чтобы контролировать все. Перевод включается, когда мы обнаруживаем, что у пользователя есть культура браузера, отличная от en-us. Каждая форма происходит от базовой формы, которая проходит через каждый серверный элемент управления и выполняет перевод (данные перевода хранятся в виде данных в переменной приложения для культуры). Я до сих пор поражаюсь, насколько быстро выполняется итерация управления.

Проблема

Бизнес очень доволен тем, как работают переводы. В дополнение к статическому контенту, о котором я упоминал выше, теперь компания хочет также переводить определенные данные. Системные заметки являются хорошим примером перевода, который они хотят. Пример « Отправленное письмо № XXXX клиенту» - компания хочет, чтобы текст «Отправленное письмо клиенту» был переведен в соответствии с культурой браузера.

Я прочитал пару других постов на SO, в которых говорится о локализации, но они не решают мою проблему. Как вы переводите фразу, которая генерируется динамически? Я мог бы легко прочитать текст на английском языке и перевести «Отправлено», «Письмо», «Кому» и «Клиент», но я гарантирую, что это будет выглядеть глупо для конечного пользователя, потому что это фраза. Динамическая часть сгенерированной системой заметки испортила бы любой поиск, который мы выполняем для фразы, если мы сохранили фразу на английском языке, за исключением динамического текста.

Одна мысль у меня была ... У нас нет таблицы сгенерированных системой типов нот. Я предполагаю, что мы могли бы создать тот, который имел бы заполнители для динамических данных, и механизм перевода игнорировал бы маркеры заполнителей. Проблема с этим подходом состоит в том, что наша база данных SQL-сервера является репликацией старой базы данных выбора, и мы на самом деле не знаем всех типов сгенерированных системой фраз (они глубоко в базе кода pic, в подпрограммах, управляющих файлах и т. Д. .). Такие вещи, как заметки, сообщения и причины отклонения платежей, хранятся по-разному. Попытка нормализовать эти данные оказалась трудной. Было бы огромным усилием вернуться назад, идентифицировать и изменить каждую программу выбора, которая генерировала сообщение.

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

Есть идеи?

Answer 1

Отсутствие «узкого места» - то, что вы называете (отсутствующим) «центральным механизмом генерации» - это архитектурная проблема в этой ситуации. В идеале лучше всего реструктурировать, чтобы создать такое узкое место (так что вы можете продолжать использовать свой общий подход с базой данных, соответствующей культуре, для передачи сообщений, просто с "заполнителями", например, для #XXXX в вашем примере). *

Если это просто невыполнимо, вы можете поместить «узкое место» на другом конце канала - когда будет готово сообщение. В этот момент, или несколько моментов, вам нужно попытаться сопоставить (английскую) строку, которая должна быть выдана, с серией правильно составленных регулярных выражений (с "заполнителями", как правило, типа (.*?) ...), и таким образом определить соответствующий ключ для поиска в БД. Да, все же - это много работы, но, по крайней мере, это должно быть выполнимо без проблем, о которых вы упомянули со старым переведенным кодом выбора.

Answer 2

Мы используем предложенную вами технику с точками вставки.

«Отправленное письмо № {0: номер письма} клиенту {1: полное имя клиента}»

Что может быть (скажем, в обратной латыни):

"Ustomercay {1: полное имя клиента} asway entsay etterlay # {0: Letter Num}"

Обратите внимание, что это обрабатывает случаи, когда конкретный целевой язык меняет порядок вставки и т. Д. Он не обрабатывает тонкости, такие как first, second и т. Д., Которые должны обрабатываться логикой приложения / несколькими фразами:

"Это ваше {0: первое, второе, третье} предупреждение"

Answer 3

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

Сохранение переводов на более поздний срок обеспечивает как точку сбора данных для построения каталога сообщений, так и грубый (если иногда * смехотворно wonky ) динамически создаваемый начальный набор переводов. После того, как вы начнете процесс, проследите, какие переводы были просмотрены и как часто каждый был поражен. После этого часто просматриваемые машинные переводы могут быть просмотрены и уточнены.

Answer 4

Динамический машинный перевод не подходит для продукта, за который вы действительно ожидаете, что люди будут платить деньги. Единственный способ сделать это - использовать статические шаблоны, содержащие точки вставки (как показал Cade Roux в своем ответе).

Тщательный рефакторинг вашего кода не обходится без этой возможности. Альтернатива состоит в том, чтобы ничего не делать с этими фразами (что вы делаете сейчас, и у вас все хорошо, правда?). Обычно нет перевода лучше, чем смущающий плохой перевод.