Интеграция перевода фраз с помощью String.Format - PullRequest
1 голос
/ 15 января 2010

У меня есть фраза на английском языке, которая выглядит так: «У меня есть {0} собак и {1} кошек». В коде я предоставляю данные в виде String.Format:

String.Format("I have {0} dogs and {1} cats", 1, 2)

Итак, вывод такой: «У меня 1 собака и 2 кошки».

Проблема, которую я пытаюсь решить, заключается в том, что фразу «У меня есть {0} собак и {1} кошек» »необходимо перевести на другие языки.

В этом примере перевода на испанский язык английская фраза «У меня есть {0} собак и {1} кошек» и переведенная фраза «Tengo {0} perros y gatos {1}» хранятся в базе данных.

Если пользователь изменит "Tengo {0} perros y gatos {1}" на "Tengo {0} perros y gatos {3}", то при вызове String.Format ("будет вызвано исключение System.FormatException Tengo {0} perros y gatos {3} ", 1, 2).

На данный момент я перехватываю исключение формата, и оно кажется неправильным. Я ищу идеи для лучшего решения.

Ответы [ 6 ]

4 голосов
/ 15 января 2010

Перед сохранением в базу данных, почему бы не посмотреть, если вы бросаете String.Format? Если так - не позволяйте пользователю сохранять.

Просто простая идея, которая может решить проблему ...

1 голос
/ 15 января 2010

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

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

1 голос
/ 15 января 2010

Я бы сравнил переведенную фразу с сохраненной исходной фразой, чтобы проверить, равны ли число и типы заполнителей.

Разобрать оригинальную английскую фразу и проверить заполнители, например, используя регулярное выражение: /\{\d+\}/ (если вы используете только заполнители и не форматируете). Проверьте совпадения и сравните их во время редактирования с переведенной строкой. Это гарантирует, что приложение не будет работать в тот момент, когда пользователь все еще сможет его исправить.

1 голос
/ 15 января 2010

Вы можете сделать две вещи:

  1. Убедитесь, что этого не происходит, когда переводчик сохраняет новый перевод, т. Е. Вы можете найти {XX} и посмотреть, отличается ли максимальное число от исходного перевода. Если это так, не сохраняйте новый.
  2. При отображении, если есть такая ошибка, перехватите исключение и вернитесь к языку по умолчанию, который, как вы знаете, является правильным.
1 голос
/ 15 января 2010

Что ж, я думаю, что ваши пользователи не смогут изменить строку перевода, если они не знают, что делают. Обычно переводчикам следует сообщить, что {0}, {1} представляют собой заменяемые параметры и не должны изменяться. Все остальные люди, кроме переводчиков, не должны иметь доступа к этим строкам, ИМХО.

0 голосов
/ 15 января 2010

Ночные юнит-тесты могут решить эту проблему.

Другая идея:

Дайте этому пользователю инструмент проверки, который пользователь сможет запустить после внесения изменений.

...