Недоработки механизма локализации (???)

Автор Тема: Недоработки механизма локализации (???)  (Прочитано 28530 раз)

0 Пользователей и 1 Гость просматривают эту тему.

Оффлайн Андрей БушманАвтор темы

  • ADN Club
  • *****
  • Сообщений: 2000
  • Карма: 163
  • Пишу программки...
    • Блог
  • Skype: Compositum78
Доброго времени суток.

- AutoCAD 2009 SP3 Enu
- AutoCAD 2014 SP1 Enu

Одна из перегруженных версий конструктора CommandMethod имеет следующую сигнатуру:
Код - C# [Выбрать]
  1. public CommandMethodAttribute(string groupName, string globalName, string localizedNameId, CommandFlags flags, Type contextMenuExtensionType, string helpFileName, string helpTopic);

Третий параметр (localizedNameId) задаётся строкой, выступающей в качестве идентификатора для поиска соответствующей записи в локализованном словаре ресурса текущего класса. Однако параметры helpFileName и helpTopic жёстко задаются строковыми значениями. В результате, не зависимо от того, какая локализация используется, справочная система вызывается всегда одна и та же, а не её локализованный вариант. Это неправильно. Механизм обработки выше обозначенных мною двух параметров должен быть тем же, который обрабатывает параметр localizedNameId, т. е. имя файла справки и имя нужного раздела справки так же должны читаться из файла локализованных ресурсов, а не жёстко прописываться в коде.

Причём желательно, чтобы в локализованных ресурсах имя фала справочной системы можно было бы указывать в т. ч. и в относительной форме, чтобы полный путь вычислялся относительно каталога, в котором находится данная сборка, т. к. справка может находится в некотором подкаталоге (у каждой локализации свой). Т. е. возможны, как минимум два варианта хранения локализованной справки:

Первый вариант (имя справки одинаково, но файлы хранятся в разных местах):

- ..\help\Ru-ru\myHelpFile.chm
- ..\help\En-us\myHelpFile.chm

Второй вариант (файлы хранятся в одном месте, но имеют разные имена):

- ..\help\myHelpFile.Ru-ru.chm
- ..\help\myHelpFile.En-us.chm

Откровенно говоря, обозначенную в этой теме проблему я считаю багом.

P.S. Точно не помню, возможно я уже и сообщал о проблеме в ADN пару-тройку лет назад, но на всякий случай обозначаю её в этой ветке форума.
« Последнее редактирование: 27-12-2013, 12:33:32 от Андрей Бушман »

Оффлайн Дима_

  • ADN Club
  • ****
  • Сообщений: 473
  • Карма: 66
Для чего в локализованную версию устанавливать нелоколизованную справку (и наоборот, зачем  в базовой версии сваливать все локализации)?? Класть "правильную" справку нужно во время установки...

Оффлайн Андрей БушманАвтор темы

  • ADN Club
  • *****
  • Сообщений: 2000
  • Карма: 163
  • Пишу программки...
    • Блог
  • Skype: Compositum78
Для чего в локализованную версию устанавливать нелоколизованную справку (и наоборот, зачем  в базовой версии сваливать все локализации)??
А для чего в программах имеется возможность переключение между локализациями? Или Вы и это считаете "сваливанием всех локализаций"? Или же по-Вашему это нормально, когда юзер указывает удобную ему локализацию, а справка остаётся от прежней локализации (именно это и получится, если следовать Вашим рекомендациям)?

В самом .NET заложен механизм, отделяющий код от локализаций и позволяющий выбирать нужную из имеющегося перечня. Локализованные ресурсы представлены в виде отдельных dll файлов. Добавление\удаление локализации сводится к банальному добавлению\удалению такой dll. И это правильное решение. Аналогично грамотным решением является и предоставление локализованных версий справочной системы, соответствующих тем локализациям, которые добавлены в программу, дабы когда юзер переключит локализацию, справка соответствовала ей.

Класть "правильную" справку нужно во время установки...
Получается, что решение о том, какая локализация справки является "правильной" решаете Вы, а не пользователь, переключающий локализацию приложения. Это неправильно. 99% моих .NET-плагинов под AutoCAD - это обычные zip архивы, а не MSI, которые в данном контексте считаю ненужными.
« Последнее редактирование: 26-12-2013, 13:00:51 от Андрей Бушман »

Оффлайн Александр Ривилис

  • Administrator
  • *****
  • Сообщений: 13829
  • Карма: 1784
  • Рыцарь ObjectARX
  • Skype: rivilis
Выскажу своё предположение из-за чего имеет место ограничение в локализации справки.
Всё завязано на то, что AutoCAD .NET API в основном обертки для ObjectARX. В данном случае речь идет об обертке функции acedSetFunHelp, у которой есть такие параметры:
Код - C++ [Выбрать]
  1. int acedSetFunHelp(
  2.     const ACHAR* pszFunctionName, // Имя команды
  3.     const ACHAR* pszHelpfile, // Имя файла помощи
  4.     const ACHAR* pszTopic, // Имя раздела файла помощи
  5.     int iCmd // неиспользуемый параметр
  6. );
Т.е. локализацией в этой функции не пахнет. С другой стороны можно проверить текущую локализацию и запустить эту функцию с нужными параметрами в зависимости от локализации. Кстати, и в .NET через P/Invoke это сделать достаточно просто.
« Последнее редактирование: 07-10-2015, 13:14:04 от Александр Ривилис »
Не забывайте про правильное Форматирование кода на форуме
Создание и добавление Autodesk Screencast видео в сообщение на форуме
Если Вы задали вопрос и на форуме появился правильный ответ, то не забудьте про кнопку Решение

Оффлайн Дима_

  • ADN Club
  • ****
  • Сообщений: 473
  • Карма: 66
Может я подотстал от последних версих - а где Вы видели в автокаде переключение локализаций на лету (как это действительно есть во многих других программах). Да есть соответствующие механизмы (и не только в .Net) для выбора соответствующих библиотек, но к автокаду-то это не относится. По моему, то что формат хранения Ваших плагинов на данном этапе "не дружит" с локализацией (то есть, дружит, но с тем вариантом который есть в .Net, но отсутствует в Автокад) - это Ваш баг, а не автодеска. Реализовывать или нет соответствующие "навороты" системы решать им - мне вот тоже не нравится то, что объектная модель не поддерживает асинхронные операции - и что - почему это баг?? Не забывайте, что автокад (пока) написан не на .Net и все что видно из него - это только обертка - я уверен, что если делать с нуля, то на .Net автокад будет дешевле (в програмисточасах) и менее глючней, но поди напиши все по новой за год (а маркетинг того требует).

Оффлайн Андрей БушманАвтор темы

  • ADN Club
  • *****
  • Сообщений: 2000
  • Карма: 163
  • Пишу программки...
    • Блог
  • Skype: Compositum78
@Александр Ривилис
Не путайте белое с пушистым! В данном случае речь о .NET, а не о ARX. Обратите внимание на то,  что в управляемой обёртке, написанной Autodesk, параметр localizedNameId извлекает именно локализованное значение, обращаясь для этого к ресурсам класса. И, как видим, функция acedSetFunHelp никак не помешала этой реализации... Кроме того, вы не путайте файл справки AutoCAD с файлом справки плагина - менять локализацию плагина можно на лету, чего нельзя сделать с AutoCAD.

Так что же помешало по аналогии с localizedNameId сделать это и для параметров helpFileName, helpTopic? Реализация занимает  всего пару строк кода (если нужно, могу показать их).
Цитата: Александр Ривилис
Т.е. локализацией в этой функции не пахнет. С другой стороны можно проверить текущую локализацию и запустить эту функцию с нужными параметрами в зависимости от локализации. Кстати, и в .NET через P/Invoke это сделать достаточно просто.
Я не спрашивал о том, как проверять текущую локализацию или менять её - это я прекрасно умею делать (причём без всяких P/Invoke). Мой вопрос был совсем о другом.

Цитата: Дима_
а где Вы видели в автокаде переключение локализаций на лету (как это действительно есть во многих других программах).
А я и не писал о переключений локализаций на лету для самого AutoCAD... Я писал о смене локализаций применительно к плагинам. Такое переключение делается достаточно просто и время от времени в своих .net плагинах я это делаю (когда не ленюсь). Значение желаемой локализации  (её имя) хранится в файле настроек плагина. Если указанная не найдена, то используется та, что Default. Если найдена - то на момент работы команды текущей устанавливается та, что указана (локализация интерфейса) и по завершению работы возвращается прежняя. Если в файле настроек указать др. локализацию, то следующий вызов команды плагина применит эту локализацию (перезагрузка не требуется). Но по умолчанию происходит считывание той локализации, которую имеет AutoCAD. Поэтому, если AutoCAD английский, то и локализация в плагине будет искать прежде всего английскую, а если AutoCAD русский - то русскую. Если пользователь захочет для плагина принудительно указать иную (например, русскую в английском автокаде), то может сделать это в настройках. И заметьте: этот механизм не я придумал - это родной механизм, реализованный в .NET, а я всего лишь пользуюсь им (как и AutoCAD, применительно к localizedNameId).

Цитата: Дима_
Да есть соответствующие механизмы (и не только в .Net) для выбора соответствующих библиотек, но к автокаду-то это не относится. По моему, то что формат хранения Ваших плагинов на данном этапе "не дружит" с локализацией (то есть, дружит, но с тем вариантом который есть в .Net, но отсутствует в Автокад) - это Ваш баг, а не автодеска.
Прочитайте внимательней ещё раз первое сообщение данной темы... AutoCAD как раз таки использует механизм, реализованный в .NET - ещё раз смотрите на параметр localizedNameId. Но разработчики реализовали это так, что используют его только для одного параметра, хотя по хорошему следовало сделать это для трёх. Это недоработка обёртки!

Цитата: Дима_
Реализовывать или нет соответствующие "навороты" системы решать им
Это не "навороты", а недоделка, исправление которой укладывается в две строки кода. Я бы не задавал такого вопроса, если бы и localizedNameId не обращался к локализованным ресурсам. Но если уж начали делать, то доделывайте до конца (имхо).

Цитата: Дима_
Не забывайте, что автокад (пока) написан не на .Net и все что видно из него - это только обертка
Я пишу не об абстрактном сферическом коне в вакууме, а о конкретной ситуации. Кроме того, как я уже писал выше - исправление занимает всего две строки кода.

Оффлайн Александр Ривилис

  • Administrator
  • *****
  • Сообщений: 13829
  • Карма: 1784
  • Рыцарь ObjectARX
  • Skype: rivilis
Андрей. Ты видимо не понял, что localizedNameId появилось лишь (!!!) потому, что у AcEdCommandStack::addCommand из ObjectARX есть аналогичный параметр. Всё это сделано не для того, чтобы ты мог локализовывать свои плагины, а для единообразия локализации команд в AutoCAD'е, которые имеют глобальное и локализованное имя. Причем локализованное имя команды зависит только от локализации самого AutoCAD. Если же тебе нужно расширить возможности локализации своего плагина (например, переключать локализацию налету) - тут тебе придется поработать самому.
Не забывайте про правильное Форматирование кода на форуме
Создание и добавление Autodesk Screencast видео в сообщение на форуме
Если Вы задали вопрос и на форуме появился правильный ответ, то не забудьте про кнопку Решение

Оффлайн Дима_

  • ADN Club
  • ****
  • Сообщений: 473
  • Карма: 66
Вы вчера добавляли свойство количества вершин в полилинию (родного такого нет) - причем которое будет работать естественно только из под .Net - это тоже баг по Вашему?? Наделать "свистелок" на 2-5002 строки можно бесконечное множество. Есть родной функционал, он развивается (и может через 3 версии добавится и тот, о чем Вы сейчас говорите), но это никак не баг - не умеет она этого, и не обязана, несмотря на то что .Net такое поддерживает, и автокад подобное реализует - но в другом месте. Я могу взять ЛЮБОЙ ваш плагин и найти там таких (чего он не умеет, а добавь 2 строчки - сможет) "багов" вагон (да и уверен, что юзеры Вас постоянно просят - а можно чтоб еще...).
з.ы. лично мне тоже много чего в автокаде не хватает (и даже раздражает), но вариантов-то нет...

Оффлайн Александр Ривилис

  • Administrator
  • *****
  • Сообщений: 13829
  • Карма: 1784
  • Рыцарь ObjectARX
  • Skype: rivilis
В данном случае чтобы реализовать то, что нужно Андрею, следует в методе IExtensionApplication.Initialize проверить локализацию и вызвать acedSetFunHelp с параметрами, зависящими от локализации. В этом случае нажатие F1 в AutoCAD для данной команды (команд) должно приводит к вызову соответствующей справки.
Фактически acedSetFunHelp занимается тем, что заносит во внутреннюю таблицу AutoCAD тройку строк имя команды-имя файла помощи-имя раздела помощи. При нажатии F1 AutoCAD проверяет эту таблицу и вызывает нужный раздел нужной справки.
Не забывайте про правильное Форматирование кода на форуме
Создание и добавление Autodesk Screencast видео в сообщение на форуме
Если Вы задали вопрос и на форуме появился правильный ответ, то не забудьте про кнопку Решение

Оффлайн Андрей БушманАвтор темы

  • ADN Club
  • *****
  • Сообщений: 2000
  • Карма: 163
  • Пишу программки...
    • Блог
  • Skype: Compositum78
@Дима_
0. А я разве где-то писал, что отсутствие количества точек в полилинии - это баг? Не нужно коверкать меня. Хотя, несомненно, реализовать это свойство было бы несложно и оно было бы достаточно восстребованным.

1. Я никогда не ставил (и не ставлю) свой код в качестве образца - ошибок в нём хватает, как собственно и в Вашем. При чём здесь мой код? По Вашей логике получается, что Autodesk на любое замечание\пожелание может отвечать: "да на свой код посмотрите, нефиг на наш смотреть" и по Вашему это будет считаться исчерпывающим ответом (раз Вы сейчас переключаетесь в этот режим)...

2. На моём старом сайте зачастую код не самой последней версии (если уж на то пошло).

3. В теме я обозначил конкретную проблему и обозначил способ её решения, который достаточно просто реализуется (см. код ниже).

Код - C# [Выбрать]
  1. // Это у них уже должно иметься, поскольку через менеджер ресурсов AutoCAD
  2. // получает локализованное значение для localizedNameId
  3. ResourceManager resMng = new ResourceManager(GetType());
  4.  
  5. // здесь код Autodesk...
  6.  
  7. // А добавить нужно всего лишь это (только вместо строк имена переменных):
  8. String helpFileName = resMng.GetString("helpFileName");
  9. String helpTopic = resMng.GetString("helpTopic");
  10.  


Цитата: Джон Роббинс
Баг, это всё что угодно, что заставляет пользователя страдать:
- аварии и зависания
- низкая производительность и масштабируемость
- неверные результаты
- нарушения безопасности
- противоречивые пользовательские интерфейсы
- неудовлетворённые ожидания

В данном случае, видя в плагине русский интерфейс, он ожидает увидеть русскую справка, а при виде английского - английскую.

Оффлайн Александр Ривилис

  • Administrator
  • *****
  • Сообщений: 13829
  • Карма: 1784
  • Рыцарь ObjectARX
  • Skype: rivilis
Re: Недоработка механизма локализации
« Ответ #10 : 26-12-2013, 16:10:22 »
4. В теме я обозначил конкретную проблему и обозначил способ её решения, который достаточно просто реализуется (см. код ниже).
Решение этой проблемы породит кучу проблем для них самих - а именно переработку массы собственных и сторонних команд, которые используют тот же конструктор. Единственный вариант, это создание еще одного конструктора.
Не забывайте про правильное Форматирование кода на форуме
Создание и добавление Autodesk Screencast видео в сообщение на форуме
Если Вы задали вопрос и на форуме появился правильный ответ, то не забудьте про кнопку Решение

Оффлайн Андрей БушманАвтор темы

  • ADN Club
  • *****
  • Сообщений: 2000
  • Карма: 163
  • Пишу программки...
    • Блог
  • Skype: Compositum78
Re: Недоработка механизма локализации
« Ответ #11 : 26-12-2013, 16:14:52 »
Причем локализованное имя команды зависит только от локализации самого AutoCAD.
Да это всё понятно...
Если же тебе нужно расширить возможности локализации своего плагина (например, переключать локализацию налету) - тут тебе придется поработать самому.
Эту работу я без проблем делаю одной единственной строкой кода. Да услышьте же Вы меня на конец: у меня нет проблем с переключением локализаций своего плагина!!! Проблема в том, что когда пользователь набирает в консоли AutoCAD имя моей команды и, не нажимая Enter, жмёт клавишу F1, то открываться будет всегда один и тот же файл справки, не зависимо от локализации как плагина так и AutoCAD. Это неправильно!

Цитата: Александр Ривилис
Единственный вариант, это создание еще одного конструктора.
Ну или так... Важен результат, а не цвет "фенечек".

Оффлайн Александр Ривилис

  • Administrator
  • *****
  • Сообщений: 13829
  • Карма: 1784
  • Рыцарь ObjectARX
  • Skype: rivilis
Re: Недоработка механизма локализации
« Ответ #12 : 26-12-2013, 16:15:58 »
В данном случае, видя в плагине русский интерфейс, он ожидает увидеть русскую справка, а при виде английского - английскую.
Повторюсь. Логика работы AutoCAD во все времена: "язык плагина" == "язык AutoCAD". Соответственно и справка должна быть на том языке, на котором AutoCAD. Например, в IExtensionApplication.Initialize ты копируешь в нужное место соответствующий языку локализации файл. И тогда AutoCAD будет использовать именно его.
Не забывайте про правильное Форматирование кода на форуме
Создание и добавление Autodesk Screencast видео в сообщение на форуме
Если Вы задали вопрос и на форуме появился правильный ответ, то не забудьте про кнопку Решение

Оффлайн Александр Ривилис

  • Administrator
  • *****
  • Сообщений: 13829
  • Карма: 1784
  • Рыцарь ObjectARX
  • Skype: rivilis
Re: Недоработка механизма локализации
« Ответ #13 : 26-12-2013, 16:17:03 »
Проблема в том, что когда пользователь набирает в консоли AutoCAD имя моей команды и, не нажимая Enter, жмёт клавишу F1, то открываться будет всегда один и тот же файл справки, не зависимо от локализации как плагина так и AutoCAD. Это неправильно!
Андрей. Ты это попробовал: http://adn-cis.org/forum/index.php?topic=417.msg1109#msg1109 ?
Не забывайте про правильное Форматирование кода на форуме
Создание и добавление Autodesk Screencast видео в сообщение на форуме
Если Вы задали вопрос и на форуме появился правильный ответ, то не забудьте про кнопку Решение

Оффлайн Дима_

  • ADN Club
  • ****
  • Сообщений: 473
  • Карма: 66
Re: Недоработка механизма локализации
« Ответ #14 : 26-12-2013, 16:24:59 »
То Андрей:
Я не про ошибки в кодах, а про то что в любой програмный продукт можно еще чего-то добавить, что обязательно кому-нибудь понадобиться (не предеться делать самому). Да есть вещи которые "производителю" решить объективно проще.
То Александр - да перегрузку-то с еще какой-нибудь коомбинацией типов придумать-то можно, технически это действительно не проблемма, просто надо очерчивать границы функционала - у нас и так в системе классов (перегрузок методов) которые НИ РАЗУ не были и не будут запущенны.