Исходный код не английский; какой (естественный) язык отобразить пользователю? - PullRequest
0 голосов
/ 03 декабря 2009

Я создаю перевод на английский язык для программы, написанной на немецком языке (то есть все строки в tr ("...") являются немецкими). Пользователи, которые не на английском языке, не на немецком языке, вероятно, захотят увидеть перевод на английский, но с программой, как сейчас, они увидят немецкий.

Есть несколько способов решить эту проблему:

  • Проверьте, если это немецкий язык, и в противном случае введите английский.
  • Предоставление опции пользователю.
  • Заставить программистов изменить свой исходный код на английский.

Что считается наилучшей практикой для интернационализации, когда исходный код не на английском языке?

Ответы [ 3 ]

2 голосов
/ 04 декабря 2009

Это два отдельных вопроса.

Лучше всего не использовать какие-либо жестко закодированные строки в источниках. Строки должны храниться во внешних файлах и загружаться по идентификатору.

Но то, что у вас там, не похоже на лучшую практику. Может быть, слишком много работы, чтобы получить его там.

То, что вы описываете (tr ("...")) звучит как gettext (или что-то подобное). Этот подход для gettext (и аналогичных библиотек) заключается в том, что «материал в исходных кодах - это абсолютный запасной вариант», используемый, если отсутствуют строки для нужного языка.

В этом случае я бы выбрал «Подарить опцию пользователю». Вы не можете предположить, что пользователь знает английский.

Реальный пример: в Швейцарии официальными языками являются итальянский, немецкий, французский и романский. Если я спрашиваю о французском, а его нет, то следующим лучшим вариантом, вероятно, будет немецкий, а не английский. В Канаде официальными языками являются французский и английский, поэтому, если я не говорю о французском и не доступен, следующим лучшим вариантом, вероятно, будет английский.

0 голосов
/ 14 декабря 2009

ОК, так что, думаю, есть три варианта:

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

Получите ресурсы для строк и автоматически проверьте, какой язык интерфейса загружен.
Здесь строки заменяются на GetResource("key") или аналогичные. При загрузке программа автоматически переводит на культуру пользователя. Это может сработать, но я знаю много немецкоговорящих людей, у которых на компьютерах установлена ​​англоязычная культура, но в некоторых местах они предпочли бы программы на немецком языке.

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

Кстати, обратите внимание, что перевод не является локализацией. Например: форматы чисел в Германии сильно отличаются (например, 1,233,44) от английского (например, 1233,44). Иконы и тому подобное часто имеют национальные особенности.

0 голосов
/ 03 декабря 2009

Я думаю, что лучший вариант спрашивает пользователя (во время установки, вероятно).

Изменить исходный текст на английский слишком дорого и не стоит. Я живу в Бразилии, у нас тонны кодов на португальском языке, и перевод на английский не нужен один раз (мы делаем программное обеспечение для носителей английского языка) Если у вас нет клиента, который требует от вас этого (обычно, когда вы также продаете источник).

Надеюсь, это поможет

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...