|
#1
|
|||
|
|||
Языковые DLL
Всем привет. Хочу сделать свою прогу многоязыковой. Хотел, чтобы все хранилось в dll. Например, ru.dll, en.dll ... И чтобы допустим кинул в папку дллку с языком и прога нашла его. Может у кого-нибудь остались исходники?
|
#2
|
||||
|
||||
как ты собираешь хранить языковые файлы(текст) в DLL, в виде переменных и констант чтоль? ИМХО, легче использовать XML, или INI
ЗЫ Профи, поправьте, если ошибаюсь. |
#3
|
||||
|
||||
T-dayne, Resource, не? Я делал, хоть и через хитро закрученную ж*пу...
Оставайтесь хорошими людьми... VK id2634397, ds [at] phoenix [dot] dj |
#4
|
|||
|
|||
Я не помню точно, сохранилась ли поддержка многоязычности через dll в версиях после 7, но в 7ой версии - это был такой кошмар, что, попробовав раз, я навсегда отказался от этой идеи. Сходи на torry.ru - там компонентов, обеспечивающих многоязыковую поддержку, в т.ч. и бесплатных, очень много. Ну и плюс стандартизация хранения ресурсов (через ActionList и т.д.) обеспечит тебе простоту и гибкость данного механизма.
|
#5
|
|||
|
|||
2 DJ PhoeniX: Можно поподробнее?
2 Imikle: спасибо, будем искать |
#6
|
|||
|
|||
Когда-то была такая задача (в контексте мультиязычной библиотечной системы).
Тогда пришел к выводу, что проще всего рассматривать "перевод" контролов, как частный случай строкового значения какого-либо свойства какого-либо компонента на форме. А "перевод" хранить в текстовом файле (в кодировке utf8, например) . Где формат строк такой : ИмяКомпонента.ИмяСвойства.Язык=Наименование Например: Label1.Caption.RUS=Привет Label1.Caption.ENG=Hello В этом случае все свелось к однотипным и простым операциям. С использованием функций модуля TypInfo. К сожалению, даже "вырванные" тексты соотв. функций занимают примерно 12 тыс. символов. Поэтому привести их здесь не могу. Но если кому-то интересно - могу где-нибудь разместить и кинуть сюда ссылку сегодня-завтра. |
#7
|
|||
|
|||
Если бы проблема была только в том, где хранить и как доставать переводы при многоязыковой поддержки своего приложения.
Это то как раз и не проблема - способов придумано множество и легко найти наиболее для себя подходящий. Проблема в разной длине строк, которые занимают на форме переводы одного и того понятия. Что никогда не видели ламерские переводы ломаных программ (игрушек ли), где надписи не помещаются на форме, вылезают за границы кнопок, залезают друг на друга и т.п.? Да, конечно, приведенный roamer'ом пример прост и реализуется так же просто. Достаточно сделать ширину кнопки чтобы помещалась надпись на русском "Привет". Тогда и "Hello" тоже разместиться. Но, к сожалению, этот пример действительно прост и не может рассказать о других сложностях при размещении компонентов на форме. Хочу сказать, что многоязыковая поддержка должна решаться комплексно. С учетом максимальной длины надписей на разных языках. А это требует некоторой смелости и труда в пересмотре размещения компонентов. При условии, что вам не безразлично как будет выглядеть ваша прога на разных языках. Может показаться, что самый "длинный язык" это русский и по надписям на нем можно определить максимальную ширину нужного компонента. Ан, нет. Бесспорно, он один из длинных, но из тех какие встречались немецкий немного "длиннее". А для меток (Label's) есть еще одна засада. Переводы на разных языках предложений, которые бывают в метках на форме могут отличаться по длине и в два раза. Тоже надо учитывать. "Механический" подход к реализации многоязыковой поддержки приведет к тому, что ваша программа будет выглядеть как будто пришла из прошлого века. |
#8
|
|||
|
|||
Если подходить "механически", то так и будет...
Кто же спорит ? В этом случае - любой метод обречет программу на "как будто пришла из прошлого века". :-) И даже если Вы реализовали прекрасное техническое решение - этого не достаточно. Нужен системный подход по КОРРЕКТНОМУ представлению сообщений интерфейсной части программы в контексте автматизируемой предметной области. Даже если все это это представлено ТОЛЬКО на русском языке. А уж о сложностях реализации корректной СИСТЕМЫ переводов для представления сообщений для ЭТОЙ же предметной области на другие языки - и говорить бессмысленно. Это очевидно. Здесь же затронута, насколько я понял, только узкая техническая часть проблемы. Впрочем. вся эта проблема интересна. Если бы Vocabulary открыл для этого вопроса отдельную тему и изложил свой опыт и рекомендации комплексно (и их можно было бы уточнить)... Это было бы только хорошо. Это возможно ? Последний раз редактировалось roamer, 13.08.2010 в 10:30. |
#9
|
|||
|
|||
2 roamer: Да тема с подводными камнями.... мне бы очень хотелось, чтобы Vocabulary и вы дали рекомендации.
|
#10
|
|||
|
|||
Насчет "дали рекомендации" - это вряд ли.
Сколько людей - столько и мнений. И "универсальная таблетка" вряд ли существует. Если программа простая (поддерживается силами одного программиста), то все сводится, в основном, к выбору способа локализации (чисто технический момент). А если это сложный программный продукт (ориентированный на какую-то обширную предметную область), то успех в определяющей степени зависит уже не столько от программистов, сколько от спецов-предметников. И в НЕ малой степени - от "управленческих решений". Т.е., в этом случае, как правило, уже есть соотв. технические наработки (из прошлых проектов). И слово уже - за методистами (спецами в автоматизируемой области). Последний раз редактировалось roamer, 14.08.2010 в 11:24. |