MUI

← →
Eraser © (2007-12-14 15:46) [40]

> DiamondShark © (14.12.07 13:36) [38]

доводы хорошие, только загнется это все, когда на десяток-другой языков перевести проект надо будет, малейшее изменение внешнего вида будет стоить огромных усилий.
не с проста шароварные/фриварные программки подход с lng файлами используют. та же Опера, qip, r-admin и т.п.
все зависит от специфики.. в большенстве случаев никакие ДевЭкспрессы точно не нужны. Мне в 90% случаев хватает стандартных компонент, если чего то нет, то есть в JVCL.
Три вью использую по-назначению - для отображения иерархии каких-то данных, заполняется в рантайме.
Обычно приложения с сотней формочек, в каждой из которых по два экзотических грида из ДевЭксперсса, разрабатывают на заказ для конкретного предприятия.. никакая локализация там не нужна.

Я прекрасно вижу приемущества встроенного средства, но касаясь конкретно моих задач, не могу его использовать хотя бы по той пречине, что третьим лицам исходники для перевода давать не собираюсь, а нанять 20 переводчиков с разных стран нет возможности, да и по 20 версий одной и той же формы уж очень не хочется править каждый раз )

← →
DiamondShark © (2007-12-14 16:17) [41]

> Eraser © (14.12.07 15:46) [40]

> Я прекрасно вижу приемущества встроенного средства, но касаясь
> конкретно моих задач, не могу его использовать

Хм... Начальная позиция была более радикальная:

> Eraser © (13.12.07 18:28) [9]
> встроенные средства - это зло, imho.

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

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

> не с проста шароварные/фриварные программки подход с lng
> файлами используют. та же Опера, qip, r-admin и т.п.

Потому что у них подход "нужен язык -- сам и сделай". У кого отношение к пользователю другое, у того и технологии другие. Неспроста же Микрософт разделяет код и ресурсы, и выпускает офисы и виндусы на сотне языков.

> Три вью использую по-назначению - для отображения иерархии
> каких-то данных, заполняется в рантайме.

ТриВью я привёл только как пример компонента, использующего DefineProperties, и с которым определённо возникают проблемы при использовании подходов с инишками.
На его месте может быть совершенно любой компонент.

← →
Eraser © (2007-12-14 16:38) [42]

> DiamondShark © (14.12.07 16:17) [41]

> Потому что у них подход "нужен язык -- сам и сделай".

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

> Просто у них ресурс простоты очень быстро заканчивается:
> первый неудобный компонент, и -- привет, напильник.

а на каждый язык свою формочку рисовать, это нормально? это можно позволить либо для проекта, в котором 2-3 языка, либо для очень маленького проекта, либо для проекта, в котором есть человек, который только и делает, что рисует интерфейсы и занимается локализацией.
поэтому советовать ITE начинающему я бы не стал. впрочем и не начинающему тоже.

> Это очень нехороший радикализм, особенно как рекомендация
> для первого опыта.

радикализм редко когда до добра доводит, согласен. но иногда требуется, чтобы соблазна не было.
а то, что набегут защитники ITE итак сразу понятно было )

← →
Anatoly Podgoretsky © (2007-12-14 16:46) [43]

> Eraser (14.12.2007 16:38:42) [42]

> а на каждый язык свою формочку рисовать, это нормально? это можно позволить либо для проекта, в котором 2-3 языка, либо для очень маленького проекта,

Это в первую очередь для крупных проектов, только зачем рисовать? Она сама нарисуется.

← →
Anatoly Podgoretsky © (2007-12-14 16:47) [44]

> Eraser (14.12.2007 16:38:42) [42]

> а то, что набегут защитники ITE итак сразу понятно было )

То есть это изначально была провокация?

← →
DVM © (2007-12-14 17:08) [45]

> DiamondShark © (14.12.07 13:36) [38]

До сего момента у меня НИ РАЗУ не возникало проблем с сохранением и восстановлением тех или иных свойств в СВОЕМ проекте в ini - подобном файле. Дело в том, что это самое сохранение и восстановление можно по-разному организовать. Я абсолютно не вижу никаких проблем в сохранении и восстановлении порядка элементов TreeView хотя бы потому, что всегда стараюсь заполнять все TreeView при запуске/по ходу программы. Да и сторонние компоненты если уж использую, то отнесусь внимательно к сохранению всех нужных мне свойств в файл.

> DiamondShark ©

А вообще непонятно, что ты мне пытаешься доказать. Я не хуже тебя знаю, поверь уж, о различных подходах к локализации приложений и многие из них испробовал и остановился на том, что мне лично показался удобнее, о чем я и заявил в [26].

Полностью поддерживаю Eraser"a в сием споре! В способе хранения языковых настроек (применительно к [8]) только один большой недостаток - невозможность перевода на языки, использующие Unicode (но вроде это проблема и самой Delphi. Честно говоря, с Unicod"ом практически не работал, но если доведется, то подумаю, как довести этот модуль до "китаезации"))). Возможности по локализации "сложных" (даже стандартных) компонентов ограничены. Например, заголовки TDBGrid заложенными мною средствами модуля перевести нет возможности. Однако в данном случае никаких проблем не возникало, т.к. достаточно просто добавить поля в ДатаСет, к которому привязан Grid, а у полей меняется что угодно. Проблемы с обновлением языка в TTreeView решить уже сложнее. Допустим были итемы (заголовки разделов), названные по русски - модуль такие весчи автоматически перевести на другой язык не сможет. Да и не должен, так как именно с TTreeView в каждом отдельно взятом случае необходимо учитывать специфику хранимых в нем данных. Еще в качестве мелкой недоработки отмечу, что невозможно изменить изображение иконок, набранных в ImageList - с свое время просто не въехал, как это можно сделать, (да и неоходимости в этом до сих пор не возникала). Ну а в остальном возможности теже, что и у встроенного средства: можно в ран-тайме путем вызова пары строк кода перевести приложение целиком, причем подвергнутся изменению практически все опубликованные свойства компонентов. В том, что можно изменить любые опубликованные свойства кроется, пожалуй, один из основных недостатков - пользователь может изуродовать приложение как ему угодно, повлиять на логику выполнения программы, дать доступ к функциям, которые именно для данной группы пользователей ограничены (включить Visible или Enabled) пункта меню. Если приложение серьезное, и вы выполняете его техподдержку, по пользователь может изуродовать языковой файл, а потом еще и претензии выставить в ваш адрес и подтвердить их "красивыми" скриншотами.
Так или иначе главное достоинства подхода в том, что любой энтузиаст может локализовать приложение на желаемый язык. На практике - загнал текст языкового файла в PROMT, посидел, поисправлял несколько часов - все, группа потенциальных пользователей резко увеличилась. По сравнению со встроенным средством локализации разница (особо для крупных проектов) весьма ощутима - над локализацией большого проекта придется сидеть на порядок дольше, а время - деньги! Подход [8] позволяет не заморачиваться над переводом опубликованных свойств компонентов, однако с переводом текстовых сообщений (а их в больших проектах десятки тысяч) будет большой гемморой (со встроенными средствами будет тоже самое - для всех текстовых сообщений придется набивать константы Resourcestring), поэтому о локализации нужно думать в самом начале разработки, иначе выйдет это непомерно дорого и долго. Но если о ней заботится в самом начале, то проблем не будет не с одним, не с другим подходом.
Лично бы я при разработке с нуля крупного многоязыкового проекта сделал бы ставку на [8] - совсем не долго времени уходит на работу с напильником, если вся огранка делается в процессе программирования (после огранку делать сложно, согласен), к тому же был бы толчок к развитию модуля. Вот только на разработку многоязыковых проектов в нашей фирме особо не заморачиваются, поэтому и развитие модуля не движется (

MUI Найти похожие ветки