[void]

Всем привет. Хочу сделать свою прогу многоязыковой. Хотел, чтобы все хранилось в dll. Например, ru.dll, en.dll ... И чтобы допустим кинул в папку дллку с языком и прога нашла его. Может у кого-нибудь остались исходники?

[T-dayne]

как ты собираешь хранить языковые файлы(текст) в DLL, в виде переменных и констант чтоль? ИМХО, легче использовать XML, или INI

ЗЫ Профи, поправьте, если ошибаюсь.

[PhoeniX]

T-dayne, Resource, не? Я делал, хоть и через хитро закрученную ж*пу...

[lmikle]

Я не помню точно, сохранилась ли поддержка многоязычности через dll в версиях после 7, но в 7ой версии - это был такой кошмар, что, попробовав раз, я навсегда отказался от этой идеи. Сходи на torry.ru - там компонентов, обеспечивающих многоязыковую поддержку, в т.ч. и бесплатных, очень много. Ну и плюс стандартизация хранения ресурсов (через ActionList и т.д.) обеспечит тебе простоту и гибкость данного механизма.

[void]

2 DJ PhoeniX: Можно поподробнее?
2 Imikle: спасибо, будем искать

[roamer]

Когда-то была такая задача (в контексте мультиязычной библиотечной системы).
Тогда пришел к выводу, что проще всего рассматривать "перевод" контролов, как частный случай строкового значения какого-либо свойства какого-либо компонента на форме.
А "перевод" хранить в текстовом файле (в кодировке utf8, например) .
Где формат строк такой :

ИмяКомпонента.ИмяСвойства.Язык=Наименование

Например:
Label1.Caption.RUS=Привет
Label1.Caption.ENG=Hello

В этом случае все свелось к однотипным и простым операциям.
С использованием функций модуля TypInfo.

К сожалению, даже "вырванные" тексты соотв. функций занимают примерно 12 тыс. символов.
Поэтому привести их здесь не могу.
Но если кому-то интересно - могу где-нибудь разместить и кинуть сюда ссылку сегодня-завтра.

[Vocabulary]

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

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

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

Может показаться, что самый "длинный язык" это русский и по надписям на нем можно определить максимальную ширину нужного компонента.
Ан, нет. Бесспорно, он один из длинных, но из тех какие встречались немецкий немного "длиннее".
А для меток (Label's) есть еще одна засада. Переводы на разных языках предложений, которые бывают в метках на форме могут отличаться по длине и в два раза. Тоже надо учитывать.
"Механический" подход к реализации многоязыковой поддержки приведет к тому, что ваша программа будет выглядеть как будто пришла из прошлого века.

[roamer]

Если подходить "механически", то так и будет...
Кто же спорит ?
В этом случае - любой метод обречет программу на "как будто пришла из прошлого века".
:-)

И даже если Вы реализовали прекрасное техническое решение - этого не достаточно.
Нужен системный подход по КОРРЕКТНОМУ представлению сообщений интерфейсной части программы в контексте автматизируемой предметной области.
Даже если все это это представлено ТОЛЬКО на русском языке.
А уж о сложностях реализации корректной СИСТЕМЫ переводов для представления сообщений для ЭТОЙ же предметной области на другие языки - и говорить бессмысленно. Это очевидно.

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

Впрочем. вся эта проблема интересна.

Если бы Vocabulary открыл для этого вопроса отдельную тему и изложил свой опыт и рекомендации комплексно (и их можно было бы уточнить)...
Это было бы только хорошо.

Это возможно ?

[void]

2 roamer: Да тема с подводными камнями.... мне бы очень хотелось, чтобы Vocabulary и вы дали рекомендации.

[roamer]

Насчет "дали рекомендации" - это вряд ли.
Сколько людей - столько и мнений.
И "универсальная таблетка" вряд ли существует.

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

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