MUI

← →
Dennis I. Komarov © (2007-12-13 17:16) [0]

Как правильнее организовать мультиязычность в своем проекте?

← →
Правильный_Вася (2007-12-13 17:28) [1]

посадить индусов и китайцев переводить?

← →
Dennis I. Komarov © (2007-12-13 17:31) [2]

Нет, в какой момент переводить все, в момент создания экземпляра формы сотреть значение флага и переводить ?

ЗЫ Или забить, и сделать разные EXE :)

← →
palva © (2007-12-13 17:35) [3]

Зависит от того, что понимать под мультиязычностью и под проектом.
Требуется ли разработать программу в нескольких вариантах для разных языков или вариант должен быть один один, но работать, например с мультиязычными данными.
Проект тоже понятие растяжимое. Если имеется в виду проект Delphi, то это одно. А если можно подобрать другую систему разработки, тогда другое.

← →
clickmaker © (2007-12-13 17:36) [4]

> [2] Dennis I. Komarov © (13.12.07 17:31)

инишки типа
[FormName]
ControlName=TextInSomeLanguage

либо вообще стринглист, если идентификация по имени сквозная по проекту

Второй вариант - воспользоваться встроенным дельфовым translation manager или самому грузить DLL с ресурсами

← →
Dennis I. Komarov © (2007-12-13 17:52) [5]

Проект ес-но дельфовый :)
программа одна, работает одинаково хотелось только разноязычные интерфейсы (Ru b Enu)
соответственно моджно сотворить разноязычные "окошечки" и вообще разные exe-шники
Или
импортировать данные и присваивать контролам значения при создании экземпляра
Или
Какие-то встроенные ср-ва Delphi

> [4] clickmaker © (13.12.07 17:36)

← →
clickmaker © (2007-12-13 18:01) [6]

> [5] Dennis I. Komarov © (13.12.07 17:52)

Если набор форм один, а ты только переводишь Caption, то есть вероятность, что при смене языка метка, например, наедет на Edit или уйдет за форму.
Поэтому, предпочтительней все-таки DLL со своим набором форм, где все уже подогнано

← →
Dennis I. Komarov © (2007-12-13 18:10) [7]

> [6] clickmaker © (13.12.07 18:01)

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

Буду думать...

← →
Eraser © (2007-12-13 18:26) [8]

> Dennis I. Komarov © (13.12.07 17:16)

http://matrix.kladovka.net.ru/index.php?page=downloads&categ=other&pagenum=1

см. multilang.zip
одновременно простая и весьма мощная весч.

← →
Eraser © (2007-12-13 18:28) [9]

> Dennis I. Komarov © (13.12.07 17:52) [5]

встроенные средства - это зло, imho.

> clickmaker © (13.12.07 18:01) [6]

> Если набор форм один, а ты только переводишь Caption, то
> есть вероятность, что при смене языка метка, например, наедет
> на Edit или уйдет за форму.

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

← →
DiamondShark © (2007-12-13 18:29) [10]

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

К ITE, наоборот, никаких претензий нет.

← →
Eraser © (2007-12-13 18:32) [11]

> DiamondShark © (13.12.07 18:29) [10]

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

← →
DiamondShark © (2007-12-13 18:34) [12]

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

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

Уж сколько раз твердили миру, что локализация -- это не перевод надписей, а ведь всё равно капшены в инишки пишут.

← →
Eraser © (2007-12-13 18:38) [13]

> DiamondShark © (13.12.07 18:34) [12]

а никто и не говорил просто про надписи, с пом. [8] локализуется все, вплоть до картинок. при этом прозрачно, как для разработчика, так и для пользователя. кинул в папочку lng файл и пользуйся, а с ITE перемудрили, с таким же успехом можно в отдельных папках разные версии проектов для разных языков хранить, не намного хуже получится )

← →
ANTPro © (2007-12-13 18:39) [14]

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

Тише, АП услышит :o)

← →
DiamondShark © (2007-12-13 18:41) [15]

> Eraser © (13.12.07 18:32) [11]
>
> > DiamondShark © (13.12.07 18:29) [10]
>
> пример хотя бы одного массового продукта, сделанного с использованием
> встроенного средства можно?

Можно. Моя последняя разработка на Дельфи. Программа для внутреннего использования на предприятии, поэтому ни сырцов ни бинарников не дам. На слово поверишь?
Ничего страшного в ITE нет.

> в теории то оно красиво.. но только не пользуется никто
> почему то )

Кулибины все.

А ты вообще много многоязыких приложений видал? И как они устроены? Неужто на инишках?

← →
DiamondShark © (2007-12-13 18:43) [16]

> Eraser © (13.12.07 18:38) [13]

Ты просто с ITE не разобрался.

> с пом. [8] локализуется все, вплоть до картинок

А размеры форм и расположение элементов?

← →
Eraser © (2007-12-13 18:47) [17]

> DiamondShark © (13.12.07 18:41) [15]

> Моя последняя разработка на Дельфи.

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

> А ты вообще много многоязыких приложений видал? И как они
> устроены? Неужто на инишках?

скажу так, навскидку процентов 80 устроены, можно сказать, на инишках, или их аналогах (xml, самописные форматы). Чаще всего языковые файлы обзывают lng ))
отсальные 15% предлагают различные exe-сборки для разных языков, там возможности поменять язык налету нету.

← →
Eraser © (2007-12-13 18:51) [18]

> DiamondShark © (13.12.07 18:43) [16]

> Ты просто с ITE не разобрался.

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

> А размеры форм и расположение элементов?

пожалуйста. любые published свойства, правда, если касаться именно этого модуля [8], мне пришлось, как говориться, напильником добавить поддержку коллекций.

← →
DiamondShark © (2007-12-13 19:03) [19]

> сама идеалогия ITE неправильная, опять же imho.

А что в ней неправильного? Не нравятся ресурсные ДЛЛ?

> любые published свойства, правда, если касаться именно этого
> модуля [8], мне пришлось, как говориться, напильником добавить
> поддержку коллекций.

Хочешь ещё одни грабли подскажу, не глядя даже в текст?
Ключевое слово: DefineProperties.

← →
Anatoly Podgoretsky © (2007-12-13 19:05) [20]

> Тише, АП услышит :o)

Я уже читаю тему.

← →
Anatoly Podgoretsky © (2007-12-13 19:13) [21]

> Ничего страшного в ITE нет.

Страшно только начинать и понять идеологию и принципы работы.
ITE это комплексное и очень удобное решение.
Работает с контролами, resourcestring, с формами позволяет создавать отдельные варианты форм для разных языков, даже набор контролов не обязан быть одинаковым. Поэтому нет проблем с шириной контрола.
После того как я его освоил, я стал очень доволен им. Борланду еще бы довести до ума смену языков, не так как у них сейчас сделано.

← →
clickmaker © (2007-12-13 19:17) [22]

> скажу так, навскидку процентов 80 устроены, можно сказать,
> на инишках, или их аналогах (xml, самописные форматы). Чаще
> всего языковые файлы обзывают lng ))
> отсальные 15% предлагают различные exe-сборки для разных
> языков, там возможности поменять язык налету нету

насчет 80 - не уверен. Многие на dll основаны.
Лично я писал с возможностью смены на лету, не на Дельфи, правда

← →
Eraser © (2007-12-13 20:53) [23]

> [19] DiamondShark © (13.12.07 19:03)

грабли где угодно найти можно. и обойти тоже любые грабли можно.

> Не нравятся ресурсные ДЛЛ?

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

← →
Anatoly Podgoretsky © (2007-12-13 22:40) [24]

> Eraser (13.12.2007 20:53:23) [23]

У тебя проблема с местом на диске?

← →
DVM © (2007-12-13 23:01) [25]

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

← →
DVM © (2007-12-13 23:03) [26]

способ с dll мне тоже не нравится, так как невозможно создание переводов программы силами энтузиастов, во-вторых маленькая программа становится монстром при нескольких языках, в-третьих смена языка на лету неудобна.

← →
ANTPro © (2007-12-13 23:09) [27]

> [24] Anatoly Podgoretsky © (13.12.07 22:40)

KOL жив ! :o)

← →
Anatoly Podgoretsky © (2007-12-13 23:10) [28]

> ANTPro (13.12.2007 23:09:27) [27]

И не только он.

← →
Джо © (2007-12-13 23:17) [29]

Хороший холиворчик, нетривиальный :)

Лично мне приходилось использовать оба обсуждаемых подхода, подход с ресурсными DLL мне кажется более конструктивным, что ли. Да и в «серьезных» продуктах он мне встречался чаще, из того, чем пользуюсь, MapInfo, к примеру и всякие массивные продукты. Хотя даже и в мелких — хоть вон IrfanView взять. Больше возможностей. Но для обеспечения удобства перевода третьими сторонами — текстовые форматы все-таки удобнее, ИМХО.

← →
ANTPro © (2007-12-13 23:39) [30]

> [29] Джо © (13.12.07 23:17)
> текстовые форматы все-таки удобнее

Для Promta :)

> [28] Anatoly Podgoretsky © (13.12.07 23:10)

Я попытался намекнуть на размер :)

ЗЫ У обоих способов есть свои + и  , и выбирать, стоит, только зная, что за проект собирается «мультиязицировать» автор.

← →
Джо © (2007-12-13 23:43) [31]

> [30] ANTPro © (13.12.07 23:39)
> > [29] Джо © (13.12.07 23:17)
> > текстовые форматы все-таки удобнее
>
> Для Promta :)
>

Почему же? В блокноте править текстовый файл всяко удобнее, чем в редакторе ресурсов. :)

← →
Anatoly Podgoretsky © (2007-12-14 00:02) [32]

> Джо (13.12.2007 23:43:31) [31]

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

← →
Джо © (2007-12-14 00:19) [33]

> [32] Anatoly Podgoretsky © (14.12.07 00:02)
> > Джо (13.12.2007 23:43:31) [31]
>
> А в блокноте удобно настраивать компоненты, их позиции,
> размеры, цвет, заголовки и так далее.
> А в блокноте тебе будет править японский, корейский, арабский?

А вы посмотрите мой самый первый пост в этой теме, [29].

> [30] ANTPro © (13.12.07 23:39)

Не маленький проект из нескольких приложений. Какой - уж извените не могу сказать. Язычность (RU и EN), другие пока не предвидятся.

> Джо © (13.12.07 23:17) [29]
> Хороший холиворчик, нетривиальный

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

> Eraser © (13.12.07 20:53) [23]
> > [19] DiamondShark © (13.12.07 19:03)
>
> грабли где угодно найти можно. и обойти тоже любые грабли
> можно.

Это махровая демагогия. Вроде: "-Почему ты куришь? Это же вредно! - Вред везде можно найти, даже в дистилированной водичке."

При обнаружении подобных "аргументов" дискуссионая ценность оппонента снижается до уровня где-то между детским садом и религиозным проповедником.

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

> > Не нравятся ресурсные ДЛЛ?
>
> не нравится, то что проект будет 10 метров весить, если
> 10 языков использовать... даже ест

Это враньё. Причём, прямое.
Даже для довольно навороченного проекта, ресурсная ДЛЛ не будет по метру на язык.

> при смене одной
> кнопки работы в 5 раз больше.

Больше по сравнению с чем?
Работы ровно столько, сколько языков. Какое-то средство позволяет делать меньше? Ха. Тогда оно снабжено телепатором.

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

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

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

> DVM © (13.12.07 23:01) [25]
> в том же Ini запросто можно хранить для каждого контрола
> размеры и положение вместе с надписью.

Ещё один.
Сохрани мне в ини то, что компонент пишет методом DefineProperties. А потом отредактируй в блокноте "командой энтузиастов".
Простейший пример: ТриВью, в котором в дизайнере нафигачена структура итемов.

> Простейший пример: ТриВью, в котором в дизайнере нафигачена
> структура итемов.

И что? Нафигачивание итемов надо производить сообразуясь с названиями из ini. Любые свойства можно сохранить в Ini файл. Да что тут собственно доказывать - достаточно глянуть dfm - тоже типа ini.

> DVM © (14.12.07 12:55) [37]

Вот-вот. Как раз тот случай: получил по лбу граблей -- схватился за напильник. Способность к абстракции = 0.0

> Нафигачивание итемов надо производить сообразуясь с названиями
> из ini.

А ты не обратил внимание на то, что итемы ТриВью -- это не только текст, но и взаимное расположение, структура?
Значит, берём напильник и вытачиваем механизм хранения в ини структурированных данных. А так как у каждого компонента может быть своя собственная, какая угодно навороченная структура, то напильник будет дымиться.
Ну, допустим, вытерли пот, отложили с довольным видом изрядно затупившийся на стандартных компонентах напильник. Ура? Фига. Тут приходит какая-нибудь монстроузная штука, вроде ДевЭкспреса. Или, ещё лучше, какой-нибудь ВасяПупкинКомпонентСьют. А Вася компоненты писал грамотно, у него в дизайнере всё что надо редактируется, и в ДФМ всё прекрасно пишется. Вот беда только: на изобретателей велосипедов Вася чихал.

> Да что тут собственно доказывать - достаточно глянуть dfm
> - тоже типа ini.

Спорим, что перед написанием этой фразы ты не потрудился посмотреть, что пишет в ДФМ ТриВью?

> DiamondShark (14.12.2007 13:36:38) [38]

И Вася использовал resourcestring

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> 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 Найти похожие ветки