kIT Universal Presets

ApceH · Сообщение **ApceH** » Вт авг 09, 2011 01:32

Ап с предыдущей страницы.
Отдельно прошу совета по реализации механизма локализации (глава 3). Тут не мало людей с опытом создания мультиязычных плагинов и программ. Откликнитесь, пожалуйста, и дайте дельные советы.

Кстати, встретил ссылку на kIT UP тут. А как вы считаете, нужно, чтобы kIT UP поддерживал RedirectSection в ini-файлах? Я не уверен, ведь это не стандартная конструкция, а только TC-шная примочка.

Flasher писал(а):#1 Запуск пресета должен ко всему прочему выполняться из того TC, в котором будет совершена правка, а это не всегда удобно.
#2 Документация несомненно осваиваемая, но громоздкая, поэтому на её изучение всё равно требуется время.

1. Почему? Не обязательно же использовать в путях %COMMANDER_PATH%, можно абсолютно везде все пути задавать при желании.
2.

А я ж говорил, надо читать history.txt в первую очередь. Зачем читать о том, чего ещё нет?

Flasher

ApceH писал(а):А как вы считаете, нужно, чтобы kIT UP поддерживал RedirectSection в ini-файлах?

Смотря в чём эта поддержка может заключаться.

1. Ага, сел за другую машину, нажал кнопку с каким-то путём - и фигушки, нет такого. Это предварительно надо кучу пресетов создавать. А куда и по какому поводу ты с ним придёшь заведомо неизвестно.
2. Встречный вопрос - зачем писать и выкладывать? Чтобы было?

Maximus

Flasher писал(а):2. Встречный вопрос - зачем писать и выкладывать? Чтобы было?

Подозреваю, что для последующего публичного обсуждения, которое может привести к дальнейшему развитию документации в правильном ключе.

ApceH писал(а):Тут не мало людей с опытом создания мультиязычных плагинов и программ. Откликнитесь, пожалуйста, и дайте дельные советы.

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

Flasher

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

Я так же подозревал пока не увидел вопрос автора.

ApceH · Сообщение **ApceH** » Вт авг 09, 2011 14:39

Flasher писал(а):(RedirectSection...)Смотря в чём эта поддержка может заключаться.

Ну то есть должен ли kITUP быть способен автоматом отследить, что секция, куда вносится изменение вынесена через RedirectSection. Естественно, не по умолчанию.
По идее не слишком трудно поддержать... Не помешает наверно, подумаю, как дополнить синтаксис.

Maximus писал(а):
Flasher писал(а):2. Встречный вопрос - зачем писать и выкладывать? Чтобы было?
Подозреваю, что для последующего публичного обсуждения, которое может привести к дальнейшему развитию документации в правильном ключе.

Абсолютно точно! Только пока откликов нет((( Я понимаю, что не XML придумываю, но всё же мозг плавится, если одному всё придумывать. Я уж молчу про реализовывать...

Maximus писал(а):Почитал немного соответствующую главу и должен сказать, что хранение строк в виде "Строка на английском=Переведённая строка" не кажется мне красивым.

Именно поэтому я и выделил красным - ибо бред. Вот и спрашиваю совета. Хотя неправильно выразился. Реализую-то я сам, а надо определиться с синтаксисом и структурой файлов, связанных с переводами.
Сделать банально, как в ТС?
Да, и это же только про графический интерфейс говорим, а в самих пресетах нормально будет, как задумал, через точку? Например, автор пресета поляк:

Код: Выделить всё

...
Description=Cześć 
Description.1049=Привет
Description.1033=Hello
...

Flasher
Одно дело, когда обсуждают (упоминают) продукт, как готовый к применению и способный на конкретные вещи. А другое - обсуждение в узком кругу вопросов развития и исправления ошибок. Только эта тема для последнего, в остальных - только первое.

MVV · Сообщение **MVV** » Вт авг 09, 2011 15:19

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

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

А для диалога другой массив - с идентификаторами элементов диалога и с индексами строк локализации. После создания диалога один простой цикл меняет текст на всех элементах окна. В дельфе, конечно, так может не получиться - там идентификаторы элементов диалога не фиксированны, а создаются каждый раз от фонаря. Хотя, наверное, при создании формы можно один раз заполнить массив компонентов вручную, а потом опять же цикл по массиву с присваиваниями.

Flasher

ApceH писал(а):Одно дело, когда обсуждают (упоминают) продукт, как готовый к применению и способный на конкретные вещи. А другое - обсуждение в узком кругу вопросов развития и исправления ошибок. Только эта тема для последнего, в остальных - только первое.

Т.е. как готовый к применению продукт тут не обсуждался?

Maximus

ApceH писал(а):Сделать банально, как в ТС?

Можно и так, но мне это не очень удобно. Поэтому я группирую приблизительно так:

[Options]
0=Опции
0_1=Отображать расширение %0 у контактов
0_2=Экспортировать LABEL (свойство vCard)
1=Отображение
1_0=Изменить шрифт...
1_1=Последовательность составляющих имени...
2=Экспорт
2_0=Экспортировать vCard в кодировке UTF-8
3=Импорт
3_0=Имя контакта по содержимому vCard-полей

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

Добавлено спустя 3 минуты:

ApceH писал(а):а в самих пресетах нормально будет, как задумал, через точку?

Наверное. Я просто не совсем в теме того, что тут творится :)

ApceH · Сообщение **ApceH** » Вт авг 09, 2011 17:59

MVV, Maximus
Большое спасибо. Теперь ясно представил себе, как это сделать. Теперь надо будет набросать весь оставшийся графический интерфейс, выписать все встречающиеся строки... Посмотрю уже тогда, какой вариант лучше подойдет из предложенных.
MVV, я использую KOL. Надеюсь, там не от фонаря

Flasher
Да. И там такому упоминанию было самое место. А начали обсуждать уже применение пресетов вообще, какие-то пути относительные ТС и т.д....

Flasher

ApceH писал(а):А начали обсуждать уже применение пресетов вообще, какие-то пути относительные ТС и т.д....

Относительные пути кто начал обсуждать?

И как это относится к

ApceH писал(а):обсуждение в узком кругу вопросов развития и исправления ошибок

В общем-то, это больше риторические вопросы. Думаю, в обсуждении такой ерунды смысла нет.

ApceH писал(а):Ну то есть должен ли kITUP быть способен автоматом отследить, что секция, куда вносится изменение вынесена через RedirectSection.

А, ну, в принципе, по наличию ключа смотреть можно. Да, я не против.

ApceH · Сообщение **ApceH** » Вт авг 09, 2011 18:40

Flasher писал(а):Думаю, в обсуждении такой ерунды смысла нет.

Почаще бы такие заключения от вас слышать

MVV, Maximus
Вот ещё один непонятный мне вопрос. Я хочу, чтобы kIT UP состоял из одного файла kitup.exe, как это и есть сейчас. Я не хочу, чтобы и английский (который будет по умолчанию, когда сделаю) был в lng-файле. Хорошо, зашить в код английские названия не проблема. А как же будет переводчик переводить? Сделать типа template, который НЕ будет использоваться программой и распространять вообще отдельно, я думаю...
А вообще, мне по душе такой вариант lng-файлов, как, например, в VisualDirSize.wlx.

Flasher писал(а):
ApceH писал(а):Ну то есть должен ли kITUP быть способен автоматом отследить, что секция, куда вносится изменение вынесена через RedirectSection.
А, ну, в принципе, по наличию ключа смотреть можно. Да, я не против.

Нет, нельзя смотреть по наличию по умолчанию. То есть вот такой код:

Код: Выделить всё

[ir|wincmd.ini|DirMenu]
RedirectSection=some_dirmenu.ini

должен, конечно, же повлиять на САМ ключ RedirectSection.
А вот, чтобы учитывался RedirectSection, придётся обязательно расширить синтаксис.
Может просто, если буква [i будет в верхнем регистре, то учитывать RedirectSection?
Например:

Код: Выделить всё

[Ia|wincmd.ini|FileSystemPlugins]
Virtual Panel=%COMMANDER_PATH%\PLUGINS\wfx\VirtualPanel\VirtualPanel.wfx

будет работать в любом случае правильно.

MVV · Сообщение **MVV** » Вт авг 09, 2011 19:07

Английский пусть будет встроенный, плюс в отдельном файле - для тех, кто будет переводить.

Maximus

Я хочу, чтобы kIT UP состоял из одного файла kitup.exe, как это и есть сейчас.

Зачем зацикливаться на этом?

ApceH писал(а):Я не хочу, чтобы и английский (который будет по умолчанию, когда сделаю) был в lng-файле. Хорошо, зашить в код английские названия не проблема. А как же будет переводчик переводить?

Вожможно какойто пользователь захочет сам поправить пару строчек в английском. Так почему бы ему не предоставить такую возможность?
Хотя тот же Гислер придерживается другого мнения и не распространяет английский в дистрибутиве.

Avada · Сообщение **Avada** » Вт авг 09, 2011 19:22

Maximus писал(а):Хотя тот же Гислер придерживается другого мнения и не распространяет английский в дистрибутиве.

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

ApceH · Сообщение **ApceH** » Вт авг 09, 2011 20:11

Maximus писал(а):Возможно какойто пользователь захочет сам поправить пару строчек в английском. Так почему бы ему не предоставить такую возможность?

Хм... Ценная мысль! Получается, надо сделать встроенный английский, но ЕСЛИ имеется файл 1033.lng, то всё равно прочитать оттуда английские названия... Так будет максимально гибко. Так и сделаю.