Поддержка многоязычности
Модераторы: d-view, Моторокер, Avada, CaptainFlint, Nik
Поддержка многоязычности
Вопрос: пишу утилиту на Delphi для Total Commander. Планирую реализовать поддержку многоязычности через lng-файлы, но пока не знаю, как лучше, т.к. никогда этим не занимался. Подскажите, как лучше и быстрее это организовать
Может у кого-то есть готовые наработки/шаблоны для поддержки многоязычности?
Если можно по-подробнее. Я ведь сюда и обратился, чтобы не изобретать велосипедAthari писал(а):Если делаешь через LNG-файлы, то ничего гениального не придумаешь. Просто вместо константных строк читаешь строки из LNG...
InqSoft Translation ToolDmitry писал(а):Есть же, наверное, какие-нибудь компоненты для Delphi для автоматического создания lng-файлов по свойствам Caption, Text... элементов управления формы?
InqSoft Translation Tool - инструмент, при помощи которого осуществляется поддержка иностранных языков во всех проектах автора. Кроме утилиты AutoTranslator, способной автоматически генерировать LNG-файлы и программный код для подключения к тексту программы, в состав пакета входит пример модуль для Delphi 5-7 в исходных текстах, позволяющий легко добавить поддержку иностранных языков в Ваши программы, а также пример, демонстрирющий использование InqSoft Translation Tool.
Имхо, самый надежный способ - ручная загрузка строк из ini-файла. При написании, конечно, много геморроя, но зато скорость и гибкость - на высоте (проверено временем; я перепробовал десяток компонентов и от всех отказался)...
Для самых одаренных - пример:[/quote]
Для самых одаренных - пример:
Код: Выделить всё
procedure LoadLanguage(File: string);
begin
Button1.Caption:=GetIniString('main', 'Button1Caption', 'Отмена', File);
Я балдею от Вас ребята, ну чес слово. Даже не посмотрев, что там по ссылке (там же 200 килобайт всего), обо***ть то, что сделано качественно и с умом. Какие там на хрен компоненты? Человек написал программу, которая генерирует сама готовые к переводу lng-файлы. А пример кода загрузки этих lng-файлов в вашу программу прост как 5 копеек, но при этом оптимизирован чтобы работать быстро. В отличие от предлагаемой тут работы с ini-файлом, когда за один раз считывается по одной строке, чтение секциями ускоряет этот процесс в десятки раз, особенно на NT-шных системах.Nik писал(а):Имхо, самый надежный способ - ручная загрузка строк из ini-файла. При написании, конечно, много геморроя, но зато скорость и гибкость - на высоте (проверено временем; я перепробовал десяток компонентов и от всех отказался)...
Для самых одаренных - пример:Код: Выделить всё
procedure LoadLanguage(File: string); begin Button1.Caption:=GetIniString('main', 'Button1Caption', 'Отмена', File);
Вручную, может и надежнее, но не факт. Поискал я все-таки еще и вот, что нашел для Delphi 7:
DKLang Localization Package (~85Kb) freeware
http://www.torry.net/vcl/vcltools/multi ... ge-2.1.zip
Balmsoft Polyglot (~1Mb) freeware
http://www.torry.net/vcl/vcltools/multi ... lyglot.exe
MH Translation Package (~75Kb) freeware
http://www.torry.net/vcl/vcltools/multi ... pack70.zip
Здесь только то, что я проверил на работоспособность.
DKLang Localization Package (~85Kb) freeware
http://www.torry.net/vcl/vcltools/multi ... ge-2.1.zip
Balmsoft Polyglot (~1Mb) freeware
http://www.torry.net/vcl/vcltools/multi ... lyglot.exe
MH Translation Package (~75Kb) freeware
http://www.torry.net/vcl/vcltools/multi ... pack70.zip
Здесь только то, что я проверил на работоспособность.
Я вполне спокоен. Это мои личные наблюдения - когда ждать закрытия окна диалога нужно несколько секунд только потому что код производит запись в ини-файл, это не очень радует глаз и нервишки. Возможно, на очень быстром компе это и не заметно. Насколько мне известно дело тут в некоторых антивирусниках с их специфическими настройками проверки файлов. Ведь одно дело проверить файл однократно при чтении секции целиком и совсем иное дело проверять этот файл столько раз, сколько имеется в этой секции считываемых параметров.Parcan писал(а):Volniyя бы так не горячилсятение секциями ускоряет этот процесс в десятки раз
Если я и горячился, то только по поводу высказываний в стиле "Никогда этого не видел, но уж точно дерьмо." (с)
Volniy
Я пробовал все (!!!) упомянутые выши компоненты и утилиты. Ни одна из них не смогла обеспечить должную гибкость!
Что касается скорости, что здесь тоже все не так просто. Такие вот локализаторы считывают строки для каждого элемента интерфейса отдельно. А если в моей программе есть элементы, имеющие одинаковые имена? В моем AmpView, например, есть строки, которые используются по три-четыре раза! А если нужно делать составные строки? Вписывать в lng-файл локализаторы их все равно придется, но для них нужно объявлять константы, а это лишние строки
Моторокер
Я пробовал все (!!!) упомянутые выши компоненты и утилиты. Ни одна из них не смогла обеспечить должную гибкость!
Что касается скорости, что здесь тоже все не так просто. Такие вот локализаторы считывают строки для каждого элемента интерфейса отдельно. А если в моей программе есть элементы, имеющие одинаковые имена? В моем AmpView, например, есть строки, которые используются по три-четыре раза! А если нужно делать составные строки? Вписывать в lng-файл локализаторы их все равно придется, но для них нужно объявлять константы, а это лишние строки
Моторокер
Ничево подобного! Для каждой строки пишется своя команда. Да, это лишний код и приходится регулярно дописывать процедуру. Но зато ты точно знаешь, почему та или иная строка не переведена. А искать баги в чужом коде... Увольте...Button1.Caption:=GetIniString('main', 'Button1Caption', 'Отмена', File);
это же всё в цикле делается
Nik
Так что крайне не рекомендую использовать составные строки в проектах которые по крайней мере ВОЗМОЖНО будут локализовываться. Это черевато.
Иногда баги в сторонних компонентах даже приятно искать, это как спортивное состязние. Но опять же это на вкус и цвет...
Volniy
А 200 К это не так уж и мало.... IMO, если нет нужды особо не полезешь.
всем
А в общем, на вкус и цвет, товарища нет. Если компонент устраивает, значит его можно использовать, если нет, либо писать свой, либо код прямой загрузки. И не надо быть фанатиками, каждой проблеме свое решение. Только автор знает устраивает его это или нет, но альтернативы и уже наработанные возможности нужно озвучить, покрайней мере для того чтобы посмотреть на возможные способы решения.
Хотя я сам в своих проектах использую ini в качестве Lng, но рекомендации по локализации крайне не рекомендуют использование составных строк. И я исходя из собственного опыта с ними согласен. Это мои грабли которыми я получил шишку.А если нужно делать составные строки?
Так что крайне не рекомендую использовать составные строки в проектах которые по крайней мере ВОЗМОЖНО будут локализовываться. Это черевато.
Это высказывание зависит от принятого способа загрузки данных о переводе. Иногда способ приемлим, иногда нет.Но зато ты точно знаешь, почему та или иная строка не переведена.
Смотря как сделана и опубликована система тестирования...А искать баги в чужом коде... Увольте...
Иногда баги в сторонних компонентах даже приятно искать, это как спортивное состязние. Но опять же это на вкус и цвет...
Volniy
при всем уважении, но в данном вопросе, код который написан собствено ручно, обычно более отвечает потребностям, не факт что он лучшее чем решение которое нашел автор компонента. Если вы заявите автору ситуацию, которую он сможет воспроизвести и решить что это стоит потраченного на разбирательства времени, тогда обычно идет исправление ошибки/переоценка принятого решения.Я балдею от Вас ребята, ну чес слово. Даже не посмотрев, что там по ссылке (там же 200 килобайт всего),
А 200 К это не так уж и мало.... IMO, если нет нужды особо не полезешь.
всем
А в общем, на вкус и цвет, товарища нет. Если компонент устраивает, значит его можно использовать, если нет, либо писать свой, либо код прямой загрузки. И не надо быть фанатиками, каждой проблеме свое решение. Только автор знает устраивает его это или нет, но альтернативы и уже наработанные возможности нужно озвучить, покрайней мере для того чтобы посмотреть на возможные способы решения.