текущий язык интерфейса AutoCAD

[Николай Горлов]

"C:\Program Files\Autodesk\AutoCAD 2015\acad.exe" /product ACAD /language "ru-RU" - это запускает 2015 автокад с русским языковым пакетом.
"C:\Program Files\Autodesk\AutoCAD 2015\acad.exe" /product ACAD /language "en-US" - запускает 2015 автокад с английским пакетом.

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

[Андрей Бушман]

Попробуй GetThreadLocale. А если нужно не просто LCID, но имя локали, то затем LCIDToLocaleName.

[Николай Горлов]

увы, но ЭТО работает так же как и системная переменная акада LOCALE. при загрузке и русской и английской локализации я получаю "ru-RU" в случае использования LCIDToLocaleName, и "RUS" в случае использования системной переменной. просто оно всё берет данные в переменных виндузов, что никак не поможет понять какой язык у меня именно в автокаде. если, например, виндуза болгарские, а автокад китайский, то на возврат придет код болгарии )))

[Андрей Бушман]

Как вариант, ты можешь из C++ получить значение свойства Thread.CurrentThread.CurrentUICulture. Я манипулировал им на C#, динамически меняя локализацию интерфейса своих плагинов и вызываемых справок в акаде (тынц).

[Андрей Бушман]

А вот и "родной" способ: GetThreadUILanguage. А если нужно менять, то SetThreadUILanguage.

[Александр Ривилис]

Или acrxProductLCID(); или AcDbHostApplicationServices::getRegistryProductLCID();
Первую функцию я использую в моём приложении GeomProps, в котором в зависимости от языка локализации строки в Панели свойств на русском или на английском.
В AutoCAD 2017 вместо acrxProductLCID() используйте acrxProductLocale();

P.S.: В AutoCAD .NET API это Autodesk.AutoCAD.Runtime.SystemObjects.DynamicLinker.ProductLcid

[Андрей Бушман]

Или acrxProductLCID(); или AcDbHostApplicationServices::getRegistryProductLCID();

Указанные мною выше варианты вроде тоже должны работать... Проверить не могу, т.к. для моих кадов установлена только одна локаль (en-US).

[Александр Ривилис]

Указанные мною выше варианты вроде тоже должны работать...

Сейчас попробую, но думаю что не работают.

[Андрей Бушман]

но думаю что не работают

На чём основано предположение? Ведь в конечном счёте мы все играем по правилам, установленным WinAPI и ежели я в C# манипулировал этим свойством через Thread.CurrentThread.CurrentUICulture, то логично предположить, что и в C++ должно получиться через  GetThreadUILanguage и SetThreadUILanguage...

[Николай Горлов]

воспользовался acrxProductLCID(). помогло. уж думал придется в реестр лезть и анализировать переменную LastLaunchedLanguage для текущей версии автокада ))). всем спасибо, вопрос решен

[Александр Ривилис]

Код:

Код - C++ [Выбрать]

1. static void GetLCIDGetLCID ()
2. {
3.     acutPrintf(_T("\nacrxProductLCID()=%d"),acrxProductLCID());
4.     acutPrintf(_T("\nAcDbHostApplicationServices::getRegistryProductLCID()=%d"),
5.       acdbHostApplicationServices()->getRegistryProductLCID());
6.     acutPrintf(_T("\nGetThreadUILanguage()=%d"), GetThreadUILanguage());
7. }

Результаты проверки.
AutoCAD 2015 English:

Command: GETLCID
acrxProductLCID()=1033
AcDbHostApplicationServices::getRegistryProductLCID()=1033
GetThreadUILanguage()=1049

AutoCAD 2015 Russian:

Команда: GETLCID
acrxProductLCID()=1049
AcDbHostApplicationServices::getRegistryProductLCID()=1049
GetThreadUILanguage()=1049

Так что GetThreadUILanguage() в AutoCAD возвращает LCID не AutoCAD, а Windows

[Александр Ривилис]

воспользовался acrxProductLCID(). помогло. уж думал придется в реестр лезть и анализировать переменную LastLaunchedLanguage для текущей версии автокада ))). всем спасибо, вопрос решен

Главное, что этот метод работает начиная как минимум с AutoCAD 2006 и не требует переделок...

[Николай Горлов]

Главное, что этот метод работает начиная как минимум с AutoCAD 2006 и не требует переделок...

это замечательно ))).
просто пришло распоряжение свыше ))) запихнуть что-нибудь в ExchangeApps на пробу. Полазил, посмотрел, пока есть непонятные места, но решил начать именно с распознавания языка, чтоб при загрузке приложения человек сразу попадал в русский или английский интерфейс команды, в зависимости от языка автокада. так что лёд тронулся )))

[Андрей Бушман]

чтоб при загрузке приложения человек сразу попадал в русский или английский интерфейс команды, в зависимости от языка автокада.

У нас официально утверждена к использованию именно английская локализация. Юзеры привыкли использовать в консоли английские варианты команд и их псевдонимов (aliases from acad.pgp file).

Однако тексты сообщений, выводимые плагинами в консоль, а так же содержимое их диалоговых окон, предпочитают видеть всё же на русском, если такая возможность присутствует. Именно поэтому в своих реализациях я даю возможность юзерам указать в общих настройках, какие локализации  и где они хотят иметь в процессе работы:

• Какую локаль использовать при консольном выводе информации, а так же в открываемых плагином диалоговых окошках
• Какую локаль использовать для справочной системы плагина (файл справки, открываемой нажатием F1)

Поскольку далеко не все сильны в английском...

[Николай Горлов]

этот подход хорош для больших программных пакетов, где при первом запуске спрашивается, на каком языке предпочтительней получать информацию и общаться с программой. в данном случае - одна команда, где работа идет через командную строку (правда, в качестве опции, есть возможность зайти в окно "Настройки"). Ну и по логике вещей, если у человека стоит английский автокад, а по умолчанию всё на китайском, то до окна настроек он может и не добраться, чтоб переключить язык ))).
тем более, в ExchangeApps, если я правильно понял их требования, файлы на рассмотрение нужно отправлять в архиве, а не в собственном навороченном инсталляторе (в котором из наворотов для одной команды будет аж выбор языка "по умолчанию"). так что, сугубо моё мнение, для одной команды нет смысла заморачиваться с переключением языка во время её работы.

[Андрей Бушман]

так что, сугубо моё мнение, для одной команды нет смысла заморачиваться с переключением языка во время её работы.

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

[Александр Ривилис]

Я вижу три варианта:
1) Приложение одноязычное и не зависит от языка AutoCAD.
2) Приложение многоязычное и подстраивается под язык AutoCAD (не обязательно под все).
3) Приложение многоязычное и его язык настраивается независимо от языка AutoCAD.
В App Exchange есть приложения как минимум первого и второго типов.

[Николай Горлов]

Я вижу три варианта:
1) Приложение одноязычное и не зависит от языка AutoCAD.
2) Приложение многоязычное и подстраивается под язык AutoCAD (не обязательно под все).
3) Приложение многоязычное и его язык настраивается независимо от языка AutoCAD.
В App Exchange есть приложения как минимум первого и второго типов.

так оно и есть. а теперь с точки зрения денежки.
первый тип - теряется часть потенциальных клиентов. ну и "достоинства" можно дальше не рассматривать
второй тип - это то что я и делаю. собственно с локализацией минут 15 назад закончил ))). всё держится на текстовых файлах. подгрузка языковой карты проходит из одного из них во время загрузки ARX. легко добавить неограниченное количество языков или перевести текст в языковом файле на то, что тебе лично нравится (да хоть с ненормативной лексикой )))).
третий тип - это по сути расширенный второй, но т.к. размер приложения невелик, то заморачиваться особо нет смысла.
так что варианты 2 и 3 дают максимальный охват аудитории. а для маленьких проектов вариант 2 можно превратить в вариант 3 просто поменяв имена у файлов локализации, если на английском автокаде хочется видеть русский текст в моей команде.

[Александр Ривилис]

первый тип - теряется часть потенциальных клиентов.

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

[Андрей Бушман]

Сколько людей, столько и мнений. Я, как уже сообщал, за 3-й вариант.

По поводу локализованных ресурсов приложения, вынесенных в отдельные текстовые файлы - мне такой вариант не нравится по той причине, что обезьяны могут их повредить или умышленно | непреднамеренно исказить содержимое. Использовать для этого родные механизмы WinAPI или .NET Framework - для меня более предпочительный вариант хотя бы по той причине, что это "стандартный", обкатанный способ, с которым знакомы все (ну или почти все) программеры. Я не хочу, чтобы мои ресурсные файлы правили обезьянки или вредоносный | написанный через зад код. Замучаешься потом доказывать, что это не ты так написал...

да хоть с ненормативной лексикой )))

ну, это явно не мои клиенты... Такая аудитория мне не интересна.

а для маленьких проектов вариант 2 можно превратить в вариант 3 просто поменяв имена у файлов локализации, если на английском автокаде хочется видеть русский текст в моей команде.

Переименовывать имена файлов из ru в en для того, чтобы получить эффект варианта 3 считаю грязным способом аля "на это не смотри, здесь нужно читать справа налево, а вот в это я вообще рыбу заворачивал...". Тем более, что для реализации варианта 3 не требуется никаких особых усилий.

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

Формирование отдельных локализованных версий с последующей их продажей по разным ценам несомненно имеет целесообразность с точки зрения зарабатывания денег. Всё зависит от приоритетов: либо деньги, либо универсальность конечного ПО, поставляемого клиенту.

[avc]

Если я что-то в чем-то понимаю, то функции acrxProductLCID и ::getRegistryProductLCID исчезли в ObjectARX 2017. Так? Хотя в документации есть. А в rxregsvc.h нет. Есть правда acrxProductLocale, но он хитрый тип возвращает.

[Александр Ривилис]

Код - C++ [Выбрать]

1. unsigned long lcid = 0;
2. // AutoCAD 2017 и новее
3. #if !defined(ACADR21)
4.           lcid = acrxProductLCID();
5. #else
6.           lcid = acrxProductLocale();
7. #endif

[Александр Ривилис]

Есть правда acrxProductLocale, но он хитрый тип возвращает.

Этот хитрый тип (AcLocale) автоматически преобразуется в long, если принудительно не установлен AC_ALLOW_CROSSPLATFORM_ONLY.
Так что при портировании в ObjectARX 2017 из предыдущих версий обычно достаточно заменить acrxProductLCID на acrxProductLocale.

[Debalance]

"C:\Program Files\Autodesk\AutoCAD 2015\acad.exe" /product ACAD /language "ru-RU" - это запускает 2015 автокад с русским языковым пакетом.
"C:\Program Files\Autodesk\AutoCAD 2015\acad.exe" /product ACAD /language "en-US" - запускает 2015 автокад с английским пакетом.

Я решил тоже поиграться с локализацией. На свой англоязычный ACAD-2016 поставил русскоязычный пакет:
1. Запускаю "C:\Program Files\Autodesk\AutoCAD 2016\acad.exe" /product ACAD /language "ru-RU" - стартует русскоязычный интерфейс.
2. Запускаю "C:\Program Files\Autodesk\AutoCAD 2016\acad.exe" /product ACAD /language "en-EN" - стартует по-прежнему русскоязычный интерфейс.
Объясните, чтобы сменить язык интерфейса - надо всё время переустанавливать языковой пакет?

[Андрей Бушман]

Объясните, чтобы сменить язык интерфейса - надо всё время переустанавливать языковой пакет?

нет.

[Андрей Бушман]

"en-EN"

не "en-EN", но "en-US". Внимательней будь.

[Николай Горлов]

в дополнение к теме. начиная с 2014 автокада и по сей день, есть системная переменная "UILOCALE". так что если нет поддержки ранних версий, то можно и не городить огород, а пользоватся этой переменной

[Debalance]

нет.

+1 к карме за всеобемлющую лаконичность в объяснении сути.

в дополнение к теме. начиная с 2014 автокада и по сей день, есть системная переменная "UILOCALE".

Я всё-таки придерживаюсь решения обведённого в зелёную рамочку - оно универсально и в духе ObjectARX, за что очередное спасибо Александру Ривилису.

И в заключение (чтобы не создавать тему в соседнем разделе), интересно на сколько универсален .NET метод (Autodesk.AutoCAD.Runtime.SystemObjects.DynamicLinker.ProductLcid)? Ответ интересует в диапазоне ACAD2007-2017.

[Александр Ривилис]

И в заключение (чтобы не создавать тему в соседнем разделе), интересно на сколько универсален .NET метод (Autodesk.AutoCAD.Runtime.SystemObjects.DynamicLinker.ProductLcid)? Ответ интересует в диапазоне ACAD2007-2017.

Документация говорит, что во всей этой линейке этот метод есть, но работоспособность во всей линейке не проверял.