К вопросу о локализованных интерфейсах и все такое

Навеяло Илюхиным постом, да простит он мне такую фамильярность. Решил расширить и углубить.

Я совершенно согласен с Ильей в том, что использовать локализованные интерфейсы в серверных продуктах – жуткое зло. Простой пример: отсортируйте список служб на сервере Exchange с английским и русским интерфейсом и посмотрите на результат. В англоязычной версии вы получите все службы рядышком с префиксом Microsoft Exchange. В русскоязычной версии сотрете палец о колесо мыши, пытаясь отыскать нужный сервис. Чем думают т.н. «надмозги» (сленговое название горе-переводчиков, уходит корнями в перевод слова overmind в одном из эпизодов StarTrek, как «надмозг», хотя, конечно же, было бы правильнее назвать это «сверхразумом») до конца понять нет никакой возможности. Потому, чтобы не гадать – лучше этим и не пользоваться. От версии к версии терминология, в принципе, не должна скакать. Т.к. Microsoft все-таки компания серьезная, следовательно, у них все стандартизовано. Есть Language Portal, где вы можете посмотреть, как тот или иной термин перевели на русский (да и на любой другой) язык. Так же словарь терминов можно скачать и использовать offline. Так же есть стандартизованные наборы переводов элементов интерфейса продуктов Microsoft. Но все равно – не надо пользоваться локализованной версией серверного ПО. Это вредно для здоровья.

Единственное место, среди серверных продуктов, разумеется, где UI может (и должен) быть локализованным – это терминальные серверы. Но и тут есть нюансы… UI Language – это настройка, которая хранится в реестре пользовательской ветки (HKCU). И, следовательно, она отлично управляется с помощью GPO. Вы можете всем обычным пользователям настроить локализованный UI, администраторам – англоязычный для удобства администрирования.

На этом с User Interface Language мы закончили и у Ильи все отлично расписано про это J Но это еще не все.

Теперь пойдем дальше и поговорим о региональных настройках, location и System Locale (с этим термином у администраторов чаще всего возникают трудности, т.к. они путают System Locale с Display language).

Начнем с Location.

Обычно при установке свежей копии Windows Server в ручном режиме администратор зачастую выбирает в качестве Location страну, где он находится. В нашем случае Russia. Windows Setup тут же понимает сигнал по-своему и настраивает Time and Currency Format и, что немаловажно, Number Format в соответствии с расположением. Это имеет свои минусы, о чем будет ниже. Что еще дает Location? Доступность некоторых КЛИЕНТСКИХ фич, например, многострадальной Cortana или Groove Music. С точки зрения сервера я не вижу ничего, что бы давало какие-то преимущества. Поэтому с недавнего времени я использую дефолтное расположение United States.

Теперь о Time and Currency Format.

В Exchange Server лично для меня хит-парад глюков возглавляет ошибка при запросе Get-MessageTrackingLog с параметрами –Start и –End. Именно эти параметры принимают ТОЛЬКО нелокализованное значение dateTime, а именно M/dd/yyyy HH:MM:SS. По умолчанию же, с Time and Currency Format отличным от дефолтного вы получите ошибку, что командлет не смог привести значение к System.DateTime. В Exchange 2010 была шикарная штука – можно было в GUI задать все параметры поиска, а потом скопировать получившийся командлет со всеми нужными параметрами. Так вот даже там время для Start\End писалось локализованным. И вставляя скопированную неизмененную команду в EMS вы все равно получали эту досадную ошибку. Более того, если вы использовали не абсолютные значения, а получали время через Get-Date и использовали метод Add(), вы все равно получали ошибку. Вот такой отличный глюк. В этом году ему ровно 10 лет. Я задавал этот вопрос команде разработки, Product Manager’ам на MEC 2014, получил расплывчатое «Мы работаем над этим», но воз и поныне там. Смените Time and Currency Format на en-us и все работает, как часы. А зачем вам локализованное время на сервере? Пользователь получает все тайм-стампы в абсолютных значениях, а клиент их конвертирует на лету в соответствии с UI Culture. Т.е. бесполезная настройка, осложняющая жизнь. Не используйте без необходимости ее. Опять же, в случае с терминальными серверами эту настройку можно изменить для отдельного пользователя, т.к. настройка тоже хранится в HKCU.

Про Number Format.

В свое время еще в OpsMgr 2007 я наталкивался на проблему, когда при мониторинге Active Directory счетчики процессора, собираемые пакетом управления, сходили с ума только потому, что десятичный разделитель был не такой, каким он является в дефолтном en-us. Да и в System Center 2012 этот вопрос продолжает доставлять радости. Следовательно, если у вас сервер не используется для расчетов, когда формат чисел важен – я тоже рекомендую оставлять его в дефолтном значении.

Ну и про «локаль».

System Locale – это кодовая страница, которую Windows использует для отображения Non-Unicode Symbols и к языку UI не имеет практически никакого отношения. Вот тут мое мнение обратное J Здесь как раз надо использовать Русский. Почему? Попробуйте получить с контроллера домена без поддержки «русской локали» (System Locale = Russian, помним, да?) объект пользователя по его Display Name. Или на сервере Exchange список пользователей так же по Display Name (ну или по First\Last, без разницы). Уверяю, вас ждет сюрприз в виде «?????? ???? ???????????». А еще, например, при настройке интеграции HP iLO с Active Directory оно не работает, если у вас кириллические First Name, Last name и Display Name и нет русской локали на том контроллере домена, куда лезет iLO.

Теперь закрепим материал:

Display Languageen-us для администраторов, локальный для пользователей (в случае с терминальниками, на других серверах рядовому пользователю делать нечего)

Time and Currency Formaten-us

Number Formaten-us

Location – я использую United States и не испытываю дискомфорта, но в принципе использовать ваше реальное местоположение тоже можно, особо это ни на что не влияет.

System Locale (Non-Unicode Codepage)локальная.

Вот такие дела J Всем спасибо за внимание.

Реклама
К вопросу о локализованных интерфейсах и все такое

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход /  Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход /  Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход /  Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход /  Изменить )

w

Connecting to %s