Вы разрабатываете приложение ASP.Net MVC? Другие ответы кажутся специфичными для настольных приложений. Позвольте мне захватить общие вещи:
Обнаружение локали
Очень важно, чтобы ваше приложение правильно определяло локаль пользователя. В настольном приложении CultureInfo.CurrentCulture содержит предпочтительный языковой стандарт форматирования (тот, который должен использоваться для форматирования чисел, дат, валют и т. Д.), Тогда как CultureInfo.CurrentUICulture содержит предпочтительный языковой стандарт пользовательского интерфейса (тот, который следует использовать для отображения локализованных сообщений). , Для веб-приложений вы должны установить обе культуры на автоматическое (для автоматического определения локали из заголовка AcceptLanguage), если вы не хотите реализовать какой-то причудливый рабочий процесс определения локали (т.е. хотите поддерживать изменение языка по требованию).
Внешние строки
Все строки должны исходить из ресурсов, то есть файлов Resx. В приложении Winforms это легко достижимо, если для свойства Localizable формы установить значение true. Вам также нужно будет (к сожалению) вручную выводить строки из ваших моделей. Это также относительно просто. В Asp.Net вам нужно было бы выводить все вручную ...
Макеты
Вам определенно нужно разрешить расширение строки. В мире Winforms это достижимо с помощью TableLayoutPanel, который следует использовать, чтобы убедиться, что макет будет корректироваться автоматически для размещения более длинного текста. В мире Интернета вам немного не повезло. Возможно, вам потребуется реализовать механизм локализации CSS - способ изменить (переопределить) определения CSS. Это позволило бы людям Localization изменять проблемы стиля по требованию. Убедитесь, что каждый элемент HTML на отображаемой странице имеет уникальный идентификатор - это позволит точно нацелить его.
Культурно-специфические проблемы
Избегайте использования графики, цветов и звуков, которые могут быть специфическими для западной культуры. Если вам это действительно нужно, предоставьте средства локализации. Избегайте чувствительной к направлению графики (так как это будет проблемой при локализации, скажем, на арабском или иврите). Кроме того, не думайте, что весь мир использует одни и те же цифры (то есть не относится к арабскому языку).
ToString () и Parse ()
Обязательно всегда передавайте CultureInfo при вызове ToString (), если это не поддерживается. Таким образом, вы комментируете свои намерения. Например: если вы используете какое-то число внутри себя и по какой-то причине необходимо преобразовать его в строковое использование:
int i = 42;
var s = i.ToString(CultureInfo.InvariantCulture);
Для номеров, которые будут отображаться для пользователя, используйте:
var s = i.ToString(CultureInfo.CurrentCulture); // formatting culture used
То же самое относится к Parse (), TryParse () и даже ParseExact () - некоторые неприятные ошибки могут быть внесены без правильного использования CultureInfo. Это потому, что какая-то бедная душа в Microsoft, полная благих намерений, решила, что было бы неплохо рассматривать CultureInfo.CurrentCulture как стандартную (она будет использоваться, если вы ничего не передадите) - в конце концов, когда кто-то использует ToString ( ) он / она хочет показать это пользователю, верно? Оказывается, это не всегда так - например, попытайтесь сохранить номер версии вашего приложения в базе данных, а затем преобразовать его в экземпляр класса Version. Удачи.
Даты и часовые пояса
Обязательно всегда храните и создайте экземпляр DateTime в UTC (используйте DateTime.UtcNow вместо DateTime.Now). Преобразуйте его в местное время в местном формате при отображении:
DateTime now = DateTime.UtcNow;
var s = now.ToLocalTime().ToString(CultureInfo.CurrentCulture);
Если вам нужно отправлять электронные письма с указанием времени в теле, обязательно включите информацию о часовом поясе, включая смещение UTC и список городов:
DateTime someDate; // i.e. from database
var formattedDate = String.Format("{0} {1}",
someDate.ToLocaleTime().ToString(CultureInfo.CurrentCulture),
TimeZoneInfo.Local.DisplayName);
Сложные сообщения
Вы уже были предупреждены, чтобы не объединять строки. Вместо этого вы, вероятно, будете использовать String.Format (), как показано выше. Однако я должен заявить, что вы должны минимизировать использование составных сообщений. Это просто потому, что целевые грамматические правила довольно часто различаются, поэтому переводчикам может потребоваться не только переупорядочить предложение (это можно решить с помощью заполнителей и String.Format ()), но и перевести все предложение другим способом на основе что будет подставлено. Позвольте привести несколько примеров:
// Multiple plural forms
English: 4 viruses found.
Polish: Znaleziono 4 wirusy. **OR** Znaleziono 5 wirusów.
// Conjugation
English: Program encountered incorrect character | Application encountered incorrect character.
Polish: Program napotkał nieznaną literę | Aplikacja napotkała nieznaną literę.
Другие проблемы конкатенации
Конкатенация не ограничивается строками. Старайтесь не расставлять элементы управления вместе, скажите:
Напомните мне еще раз в [текстовое поле с номером] дней.
Это должно быть изменено на что-то вроде: Напомнить мне снова через это количество дней: [текстовое поле].
Кодировка символов и шрифты
Всегда сохраняйте, переносите любой текст в Unicode (то есть в UTF-8). Не программируйте шрифты жестко - возможно, потребуется изменить их при локализации, и это отключит механизм возврата шрифтов по умолчанию (в случае Winforms). Не забудьте разрешить «странные» символы в большинстве полей (например, имя пользователя).
Контрольная работа
Возможно, вам потребуется реализовать так называемый псевдоперевод, то есть создать ресурсы для немецкой культуры и скопировать свои английские строки, добавив префикс и суффикс. Вы также можете обернуть заполнители, чтобы легко обнаружить составные строки. Целью псевдопереведения является обнаружение проблем локализуемости, таких как жестко запрограммированные строки, проблемы компоновки и чрезмерное использование составных сообщений.