(Куда-то мой комментарий пропал. Попробую ещё раз.)

Конечно, иметь единую точку для доступа к сообщениям на разных языках - очень полезно. Но, к сожалению, нынешний API имеет серьёзный идеологический недостаток, значительно снижающий его ценность. Сейчас в качестве критерия при выборе сообщения из многоязычного файла система использует его номер и кодовую страницу. И всё!

Нам, пользователям CP866, сразу не понятно, в чём тут подвох. Но подумайте о европейцах, у которых на практически все их языки одна кодовая страница - CP850. В результате - как программа может объяснить системе, что сообщение ей нужно на немецком языке, а не на французском?

В общем, совершенно очевидно, что функции извлечения сообщений из файла должны учитывать, что:

а) для разных языков может использоваться одна и та же кодовая таблица;

б) в одной стране может использоваться несколько разных языков;

в) один и тот же язык в разных странах может быть разным (вспомните о десятке диалектов английского);

г) для одного и того же языка могжет использоваться несколько разных кодовых страниц.

Так что необходимость в новом API сомнений не вызывает. И в этих новых функциях программа должна иметь возможность указывать страну и язык, для которых извлекается сообщение. Думаю, что для этого следует использовать не числа, а текстовую строку (как в переменной окружения LANG).

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

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

Существующий двоичный формат файла:

1. Разбирается только с помощью DOS API,

2. Хранит все числа в "little-endian".

Чтобы читать сообщения в Java-апплетах (например), более подходит как раз XML и запись строк в UTF-8.

Так что все верно.

2Юрий Ну, я не уверен в том, что текущий формат использует только номер сообщения и кодовую страницу. Правда, опыта сделать такую проверку небыло.

Давать программе возможность указывать язык и страну. Я вообще против того, чтобы программа сама это выбирала. В противном случае мы опять получаем кучу различных механизмов поддержки многоязычности. Причем каждая реализация со своими недостатками. По поводу использования текстовой строки типа EN_us. Согласен, что пользователю лучше оперировать именно такой строкой. А вот система все-равно должна оперировать кодами страны и языка.

По поводу кодировки тоже согласен. Можно смело хранить в Unicode, а потом преобразовывать. Правда, все это усложняет первоначально простой механизм. Однако, в принципе, все это имеет смысл.

В качестве вывода по всему этому:

1. Двоичный файл сообщений лучше всего подходит для функций API, т.к. см. коментарии Сергея

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

Т.е. большинство операций по обработке этих двух уровней должно упасть на компилятор файлов сообщений.

2Сергей

А также XML в UTF-8 может неплохо послужить исходным текстовым файлом сообщений. А вот двоичный оставить почти тем же.

2Всем: В принципе, эти заметки были накиданы года 2 назад, просто попались под руку. Вообще, меня просто перестало устраивать то, что начали плодится "новые API" которые кроме проблем никаких преимуществ не дают, при этом забывая, что уже есть нужные штатные API.

Вообще, я хочу привести в порядок и немного расширить текущий API файлов сообщений, дабы он стал штатным и достаточно удобным как для переводчика. так и для программиста.

>Ну, я не уверен в том, что текущий формат использует только номер сообщения и кодовую страницу. Правда, опыта сделать такую проверку небыло.

Я проверял (правда, для сообщений, засунутых внутрь EXE, но это ничего не меняет) - система тупо использует первый блок, в котором найдётся нужная кодовая страница. Косвенным подтверждением этого является также и то, что коды языков и диалектов для MKMSGF не имеют ничего общего с кодами стран для строки COUNTRY. Второе подтверждение - документация от IBM:

"When an application requests the message retriever for text associated with a message number, a test is made to determine if there is a bound message segment with this executable file. If true, each bound message segment is searched for a match with the current session's code-page number.

If a match is made, then the message number is searched for. If it is found, the message will be returned to the caller.

Otherwise, the search of remaining bound message segments will continue."

Как видишь, сравнение идёт только по номеру CP.

>Давать программе возможность указывать язык и страну. Я вообще против того, чтобы программа сама это выбирала.

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

>В противном случае мы опять получаем кучу различных механизмов поддержки многоязычности.

Какую же кучу? Сейчас у нас есть всего один механизм - обсуждаемый в статье. Как мы видим, он нас не устраивает. Я предложил его развитие, причем максимально совместимое с имеющимся. Совместимое настолько, что даже MSG-файлы переделывать не нужно: старые будут совместимы с новым API, а новые - со старым. Собственно, всё, что я предложил - при выборе сообщения использовать информацию о языке и диалекте, которые и сейчас есть в файлах, но игнорируются системой.

>По поводу использования текстовой строки типа EN_us. Согласен, что пользователю лучше оперировать именно такой строкой. А вот система все-равно должна оперировать кодами страны и языка.

Проблема в том, что сейчас официально никаких кодов языка не существует вообще. Что делать? Вводить эти коды? А зачем, если у нас уже есть стандартное обозначение, которое буквенное, а поэтому легче запоминается? К тому же таким образом мы реализуем совместимость ещё с одним существующим системным механизмом. Давай подумаем, что делать в случае, когда программа хочет не задавать явно язык, а использовать системные умолчания. В таком случае при использовании числовых кодов мы передадим 0, а в случае использования строки - пустую строку. Получив их, функция API должна где-то посмотреть, что есть умолчания. И вот тут нам пора вспомнить о последней страничке блокнота программных объектов. Той, которая называется "Язык". Там ведь пользователю тоже даётся возможность выбрать язык для программы. А знаешь, что для программы меняется тем выпадающим списком? Правильно, переменная LANG в её окружении.

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

>По поводу кодировки тоже согласен. Можно смело хранить в Unicode, а потом преобразовывать. Правда, все это усложняет первоначально простой механизм.

Понимаешь, всё, что я хотел - упростить механизм преобразования. Чтобы программисту не нужно было самому заниматься перекодировками, а достаточно было заказать системе вернуть текст в нужной кодировке. Поскольку информация о кодовой странице текста всё равно хранится в файле, то не имеет особого значения, из чего пребразовывать. Просто Unicode - более универсально. И к тому же позволит PM-ным программам выводить многоязычные сообщения.

>1. Двоичный файл сообщений лучше всего подходит для функций API

Правильно. Формат файла мы не меняем.

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

Совершенно верно. В предлагаемом тобой синтаксисе есть строчка <language id="en" codepage="850" countrycode="1" countrysubcode="1"/>. Я предлагаю изменить её на <language id="en" codepage="850" family="en" country="US"/>, а преобразование family и country в числовые коды (формат файла ведь не меняем!) возложить на компилятор. При этом текст в MSG-файл либо заносить в той кодировке, в которой он написан в исходном файле, либо преобразовывать в уникод. Можно даже приделать к компилятору ключик соответствующий, чтобы программист мог выбирать.

>Т.е. большинство операций по обработке этих двух уровней должно упасть на компилятор файлов сообщений.

Вот, вот.

Хотя это, конечно, элементарно, но, честно говоря, для полноты ощущений не хватает явного указания того:

1. что, если значение поля, названного Offset16bit, равно 1, то используется 16-битная таблица смещений, а если равно 0, то 32-битная;

2. что таблица смещений == таблица индексирования;

3. какова структура структура блока сообщения, на который ссылается элемент таблицы смещений:

struct {

UCHAR msgType; //"I", "H", "E", "W", "P", "?"

BYTE bytes[1]; // тело сообщения

};

Может тогда уже и исходники декомпилятора выложить? "Для полноты ощущений"? ;-)

Статья-то не об этом.

Ок. Только причешу их и могу отдвть в пользование.

Ты не понял. Я как раз в противоложном смысле высказался. Всё-таки статья об использовании MSG для нужд NLS и о путях возможного развития, а не о внутреннем строении файлов. Оно что пользователям, что прикладным программистам должно быть малоинтересно.

Как это статья не о внутреннем строении файлов? А название о чём говорит? И почему это малоинтересно программистам?

IMHO полуосевое решение NLS как раз страдает из-за своей фрагментарности, когда разные команды разрабатывали разные решения одной и той же проблемы, например, есть сообщения и есть ресурсы. Почему бы вообще не отказаться от MSG, сразу перейдя к ресурсам (тип STRINGTABLE)? И если уж хранить сообщения в уникоде, то отчего же их не перекодировать внутри функций API, воспользовавшись локалью?

2Юрий Как раз о внутренней структуре, а уж потом о недостатках текушего API.

2VicTor Имено. Именно то, что каждый разработчик начинает изобретать свой велосипед и есть плохо. Однако, твое предложение хранить все в ресурсах не есть гут. Смысл-то как раз в том, чтобы можно было

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

2. Дать возможность легкого и простого перевода.

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

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

2. Текстовые файлы сообщений - за легкость в добавлении переводов.

Поэтому хотелось бы иметь:

1. Обратную совместимость с принятыми в OS/2 подходами (т.е. поддержку текущего API). Посему и разбирался со структурой файлов сообщений.

2. Удобство в локализации (с точки зрения разработчика) на уровне GetText.

3. Удобство в локализации (с точки зрения переводчика) на уровне редактирования текстового файла.

А уж выбором кодировки и прочего пусть занимается система.

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

Но ведь статья называется "Внутренности NLS", а отнюди не "Внутренности MSG". И рассказывается в ней о многом: и о том, что это вообще такое и для чего, и как этим пользоваться, и как готовить исходники, и как их компилировать. Формату файлов MSG посвящён всего лишь один малюсенький раздел. (Да и то, как я уже сказал, информация эта не нужна ни пользователям, ни разработчикам. Так, просто любопытствующим).

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

2 Юрий: статья всё-таки называется по другому, если мои глаза меня не обманывают :)

2 Yuri: Вы всё правильно пишете, но я предлагаю взглянуть на проблему шире.

Давайте попробуем отделить цели от средств и реализаций. По моему мнению, правильным будет такое деление:

1. цель NLS - дать приложению возможность ввода/вывода информации в необходимом пользователю языковом и культурологическом формате. Поскольку мы рассматриваем только отображаемую текстовую информацию, то забудем про форматы даты, времени и прочее. Для текстовой информации нам важны страна, язык и набор используемых им символов (который может предоставляться различными кодовыми таблицами).

2. средством достижения этой цели предлагается считать изоляцию кода от языкозависимой информации.

3. а вот реализаций этого хозяйства, которые более-менее внятно доносят информацию хотя бы о кодовой таблице и стране, в полуоси две, по крайней мере. Это файлы сообщений и ресурсы.

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

С другой стороны, поскольку мы рассматриваем новое расширение API, то почему бы не реализовать его таким образом, чтобы оно могло получать сообщения как из бинарных файлов ресурсов (назовём это новым форматом), так и из бинарных файлов сообщений (назовём это старым форматом) для обеспечения совместимости.

В этом случае отпадает необходимость в таком средстве разработки как MKMSGF. Нужен будет только компилятор ресурсов (а он и так понадобится).

Т.е. надо внутри "DosGetMessage()" вызывать "WinLoadString()", если задано имя файла "*.dll", выбирая строку по номеру.

Вот когда IBM откроет исходные тексты... :-)

Я, например, против каких-либо бинарных файлов. Разве что только автокомпиляция (по типу REXX). Т.е. ресурсы и прочее мне совсем не нравится. А еще больше всего не нравится необходимость наличия вообще каких-либо утилит для компиляции файлов сообщений. Хочу все прозрачно ;)

можно хранить языковые ресурсы в .zip файле myprogram.dat в xml, как описано выше. такие ресурсы легко редактировать. они занимают мало места. для считывания в программу достаточно встроить unzip и xml-парсер.

2Eugene Это о-о-о-очень медленноё

Не пойдетё

Блин. Выговор тому, кто поставил по умолчанию левую кодировку (я даже знаю кому)

2 Sergey: отнюдь. ;-) DosLoadModule() и DosGetResource(). Тут, кстати, сразу же всплывает любопытная деталь - dll-то грузится в shared арену, а, следовательно, и все ресурсы, приклееные к ней, тоже разделяются всеми нуждающимися в них приложениями. А вот как это дело обстоит с MSG, мне не понятно, хотя, например, в OSO001.MSG собраны сообщения практически всех системных программ, включая инсталляцию.

2 Yuri: ну это, мне кажется, перегиб :) Бинарники не столь плохи, чтобы от них отказываться совсем. Лишь бы были нормальные средства компиляции / декомпиляции...

2VicTor По-моему, самым таким компромисом является метод, используемый в REXX. Т.е. у нас есть текстовой файл, который в расширенных атрибутах держит бинарные данные. Просто и со вкусом. Проверяем дату, если все нормально, то читаем бинарные данные, если нет, вызывает компилятор, а потом читаем бинарные данные.

По поводу загрузки MSG. MSG файлы не грузятся в память. Совсем. И поменять я их могу на лету. Подменил файлик и все. В случае ресурсов и dll-ей всегда головняк с тем, что файлик занят уже другим процессом. И это бесит. Особенно, когда переводишь, и нет четкой уверенности, что же ты там перевел и надо посмотреть. В случае MSG все тривиально..

2 Yuri: Rexx-овый метод безусловно хорош. Но применим ли он здесь? Код может содержать ошибки, а вот исходные данные - нет. А сообщения и ресурсы как раз и есть исходные данные для системы.

С точки зрения многозадачной системы, то что файлы MSG каждый раз открываются, считываются и закрываются, наверное, не есть гут. Хотя, конечно, всё это нивелируется за счёт буферизации... А головная боль нынче лечится с помощью SET LIBPATHSTRICT=T :)))

2VicTor А почему он неприменим??? Никто ведь не требует стирать бынарные атрибуты до компиляции. Кроме того, компиляция работает _только_ при работе переводчика. И вывода взамен требуемого сообщения сообщения об ошибка (как это сейчас делается, если сообщение или файл сообщений не найден) вполне достаточно. Это не приведет ни к каким проблемам. И практически никак не отличается от текущей логики работы. В случае ресурсов также могут быть проблемы с отсутствием нужной строки или самой dll.

А кроме того, для компиляции ресурсов нужен stub DLL исходный код и коспилятор ресурсов. Который тоже может оказаться несовместим со своими более другими версиями. ;)

Я в этом практичиски ничего не понимаю :( ... Но желал би узнать больше ... ПИШИТЕ !!!!!