Есть предложение радикально поменять формат описания элемента (conf), а именно - использовать XML.

Рассмотрим для примера новую запись конфигурации элемента Button.ini (автор - Dilma, версия - 1.10):
code_16792.txt

Пояснения, если надо, дам позже.

Вот опупеть его редактировать потом. Так я вручную редактирую и создаю, а в твоем случае, на это ПО надо, вручную запаришься редактировать. Но может Dilme и понравиться. И еще перевод писать придется, ссовсем здорово, а если я не силен в английских оборотах, это для меня совсем не русский

iarspider, а где замер скорости разбора такого конфига супротив существующего? я что-то сомневаюсь в сравнимой скорости обработки файла, где нет практически ничего лишнего, и файла, где более 50% информации является мусором.

Мне бы тоже хотелось остаться в рамках ini
Просто надо продумать способ введения многоязычности

[off]Button.ini - Определяет кнопку по-умолчанию[/off]

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

Поддерживаю

Поддерживаю

в таком исполнении существует только единственный вариант поддержки многоязычности: таже методика, что и в библиотеках QT. Поясню - есть исходная(прошитая) строка в конфиге элемента, например, "Определяет кнопку по-умолчанию". Есть № наборов трансляций на № языков, состоящих из пар вида:
Определяет кнопку по-умолчанию=Defined default button

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

Некоторые программы для подобных целей используют дублирующиеся ключи.
hint = ...
hint_en = ...
есть ключ с маркером языка - используем, нет - используем дефолтный

Но методика с *.lng файлами наверно более отработана

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

А не слишком ли это медленно Вот в тотале, да и во многих других, я встречал именно языковые файлы с нумерацией

С ручными правками вот будет не очень удобно, в двух местах придётся править.
Есть ещё способы нумерованного сопоставления переводов, но тогда мы опять потеряем читабельность.
или можно как в HiasmInt u - en завести дубли папки conf - conf_lng
[offtop]Почему пропорционально? Да, мы потеряем время на считывание названий ключей пропорционально их количеству, но уже потом мы проверяем наличие языкового ключа и дефолтный при его отсутствии, а не все ключи заново. Я не очень хорошо знаю алгоритмику поиска ключа в ini, но не думаю, что тормоза при подобной реализации должны быть так заметны[/offtop]

Просто хочется рассмотреть максимум вариантов, вдруг, самому в будущем пригодится.

[offtop] lev, для офтопа есть ссответсвующий тег offtop[/offtop]

[offtop]Однако бурная реакция получилась...[/offtop]


Создавать - через ECreator, редактировать не так уж и сложно (мелкие правки вручную, большие - через тот же ECreator). Перевод: если не владеешь - не делай, это не обязательный узел.


Замер не проводил. Думаю, разница, если и будет, то незначительная.

---

Синтаксис XML-файла строился с прицелом на human readability: вместо +@* перед именем метода/свойства - атрибут узла, вместо числовых идентификаторов типов - названия, и т.п.

Можно будет создать связи между свойствами и методами - привет nesco и его StringTableMT / MStrTbl!

Используя тег <link> можно будет сделать быстрое редактирование связанных свойств. Например, можно будет "визуально" привязать к событию onClick у ListBox-а св-во DataType (в области с описанием события текст DataType будет ссылкой, по нажатию на которую откроется редактор св-ва

По поводу формирования строк для перевода: я предложил лишь один из возможных вариантов. Другой вариант:
в фале элемента

В глобальном "словаре":

В словаре для "button":

Такие словари можно точно так же выкладывать для всеобщего редактирования.

---

Господа nesco и lev: вот объясните мне, чем редактирование (замечу - созданием должен ECreator заниматься) xml-файла так уж сложнее, чем ini-файла?

iarspider, а ты не заметил, что, пока, большинство против такого решения
Да и вообще, мы когда-нибудь остановимся с глобальными новшествами, ставящими все с ного на голову

nesco, так что, сразу лапки к верху? Не-е, я ещё побарахтаюсь - авось придём к консенсусу...