Ви розробляєте додаток ASP.Net MVC, чи не так? Інші відповіді здаються специфічними для настільних програм. Дозвольте мені зробити звичайні речі:
Виявлення локалів
Досить важливо, щоб ваша програма правильно виявляла локальну інформацію користувача. У настільних додатках CultureInfo.CurrentCulture має кращу локалізацію форматування (ту, яку слід використовувати для форматування чисел, дат, валют тощо), тоді як CultureInfo.CurrentUICulture має кращий локальний інтерфейс користувача (той, який слід використовувати для відображення локалізованих повідомлень) . Для веб-додатків слід встановити обидві культури для автоматичного (для автоматичного виявлення локалі з заголовка AcceptLanguage), якщо ви не хочете реалізувати певний робочий процес виявлення локалів (тобто хочете підтримати зміну мови на вимогу).
Екстерналізація рядків
Усі рядки повинні надходити з ресурсів, тобто файлів Resx. У програмі Winforms це легко досягти, встановивши для властивості форми Localizable значення true. Вам також знадобиться вручну (на жаль) екстерналізувати рядки, що надходять з ваших моделей. Це також відносно просто. У Asp.Net вам знадобиться зовнішнє все вручну ...
Макети
Вам обов'язково потрібно дозволити розширення рядків. У світі Winforms це можна досягти за допомогою TableLayoutPanel, який слід використовувати, щоб переконатися, що макет автоматично налаштується для розміщення більш тривалого тексту. У веб-світі вам трохи не пощастило. Можливо, вам потрібно буде застосувати механізм локалізації CSS - спосіб змінити (замінити) визначення CSS. Це дозволить людям з локалізації змінювати проблеми стилю на вимогу. Переконайтеся, що кожен елемент HTML на наданій сторінці має унікальний ідентифікатор - це дозволить точно націлити його.
Проблеми культури
Уникайте використання графіки, кольорів та звуків, які можуть бути специфічними для західної культури. Якщо вам це справді потрібно, будь ласка, надайте засоби локалізації. Уникайте графіки, орієнтованої на напрямок (оскільки це буде проблемою, коли ви намагаєтесь локалізувати, щоб сказати арабську чи іврит). Крім того, не припускайте, що весь світ використовує однакові цифри (тобто не відповідає арабській мові).
ToString () та Аналіз ()
Обов’язково завжди передайте 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). Не забудьте дозволити "дивні" символи в більшості полів (тобто ім'я користувача).
Тест
Ймовірно, вам потрібно буде реалізувати так званий псевдопереклад, тобто створити ресурси для німецької культури і скопіювати англійські рядки, додавши префікс і суфікс. Ви також можете обернути заповнювачі, щоб легко виявити складені рядки. Мета псевдоперекладу - виявити проблеми локалізації, такі як жорстко закодовані рядки, проблеми з компонуванням та надмірне використання складних повідомлень.