Справочник функций

Ваш аккаунт

Войти через: 
Забыли пароль?
Регистрация
Информацию о новых материалах можно получать и без регистрации:

Почтовая рассылка

Подписчиков: -1
Последний выпуск: 19.06.2015

Локализация

6
19 сентября 2008 года
George
4.1K / / 05.01.2007
Каким образом лучше реализовать сабж? Озаботился этим вопросом, так как нужно сделать поддержку несколких языков. Как вариант - хранить все строки в БД и выгружать их по мере надобности. Для каждого языка - своя таблица скажем. Или есть другие более оптимальные варианты?
14
19 сентября 2008 года
Phodopus
3.3K / / 19.06.2008
Воспользоваться бесплатными локализаторами (если экзешник локализовывать надо)
DkLang, DelLok. Второй, кстати, писал мой коллега.
286
19 сентября 2008 года
misha_turist
572 / / 28.11.2005
Стандартный Resourse DLL Wizard, он и на несколько языков переводит и группы проектов понимает.
Создать -> Остальные -> Новое.
6
22 сентября 2008 года
George
4.1K / / 05.01.2007
Цитата: Phodopus
Воспользоваться бесплатными локализаторами (если экзешник локализовывать надо)
DkLang, DelLok. Второй, кстати, писал мой коллега.


мне пакеты надо.

Цитата: misha_turist
Стандартный Resourse DLL Wizard, он и на несколько языков переводит и группы проектов понимает.
Создать -> Остальные -> Новое.


насколько я помню (пробовал я это когдато) вариант не катит, так как мне надо, чтобы пользователь мог сам выбирать язык.
Все таки страна у нас двуязычная, придется прогу "казахицировать". :)
И пользователь могет говорить как на казахском так и на русском. Поэтому надо дать возможность выбора.

303
22 сентября 2008 года
makbeth
1.0K / / 25.11.2004
ИМХО, проще всего хранить локализацию в простых текстовых файлах (или XML, на любителя), а в программе реализовать движок локализации, который бы сам подгружал нужный файл в зависимости от настроек языка. В БД хранить строки локализации не имеет смысла, т.к. это постоянные данные (которые не измняются с течением времени) да и добавление нового языка намного геморнее, чем простой файл.
286
22 сентября 2008 года
misha_turist
572 / / 28.11.2005
Цитата: makbeth
ИМХО, проще всего хранить локализацию в простых текстовых файлах (или XML, на любителя), а в программе реализовать движок локализации, который бы сам подгружал нужный файл в зависимости от настроек языка. В БД хранить строки локализации не имеет смысла, т.к. это постоянные данные (которые не измняются с течением времени) да и добавление нового языка намного геморнее, чем простой файл.


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

288
22 сентября 2008 года
nikitozz
1.2K / / 09.03.2007
Цитата: misha_turist
А как быть с зарытыми в глубине строками? (сообщения, предупреждения, текст кнопок, подписей и т.д.)



А в чем проблема с ними?

286
22 сентября 2008 года
misha_turist
572 / / 28.11.2005
Цитата: nikitozz
А в чем проблема с ними?


Как до них добратся самописным локализатором?
К примеру есть СТОРОННИЙ компонент, у него есть некий диолог. Как в нём надписи кнопок и подписей поменять?

6
22 сентября 2008 года
George
4.1K / / 05.01.2007
не, я сторонние компоненты стараюсь не юзать, так что вариант makbeth самый годящийся. Интересен такой момент - каким образом стоит осуществлять подгрузку файла? В onCreate формы?
14
22 сентября 2008 года
Phodopus
3.3K / / 19.06.2008
Цитата: Washington
не, я сторонние компоненты стараюсь не юзать


почему? этож не дельфиный подход получается! :)

Цитата: Washington

каким образом стоит осуществлять подгрузку файла? В onCreate формы?


Если уж через файлы - то в спец. функции, которую можно вызывать как при загрузке приложения, так и во время работы, для перевода "на лету"

288
22 сентября 2008 года
nikitozz
1.2K / / 09.03.2007
Цитата: misha_turist
Как до них добратся самописным локализатором?
К примеру есть СТОРОННИЙ компонент, у него есть некий диолог. Как в нём надписи кнопок и подписей поменять?



Это уже видимо придется решать на конкретной задаче по разному. Наверное вплоть до отказа от таких компонентов. Хотя, по-моему, большинство компонентов позволяют настраивать свои надписи.
Но вот упоминание о компонентах и тексте на них навели меня на размышления о другой проблеме. Далеко не каждый как сторонний так и стандартный компонент поддерживает Unicode. А вот это уже может вызвать гораздо большие затруднения, если приложение должно поддерживать какой-нибудь язык с Unicode-символами.

6
22 сентября 2008 года
George
4.1K / / 05.01.2007
да уж, в Delphi 2009 обещают unicode по полной.
14
22 сентября 2008 года
Phodopus
3.3K / / 19.06.2008
Цитата: Washington
да уж, в Delphi 2009 обещают unicode по полной.



Почему обещают, уже есть, испробовано! :)

303
22 сентября 2008 года
makbeth
1.0K / / 25.11.2004
По поводу компонентов - предпочитаю пользоваться только теми, для которых доступен исходный код (иначе получается "черный ящик" без возможности заточки под свои нужды). Соответственно, проблем с локализацией не должно возникнуть.
Подгрузку строк можно осуществлять сразу (при запуске приложения или смене языка локализации), либо по мере необходимости (например перед загрузкой какой-либо формы).
Можно вообще залезть в стандартный функционал загрузки ресурсов формы (dfm) и скармливать для свойств типа Caption, Text и т.д. нужные строки.
В общем, здесь есть где разгуляться буйной фантазии. Былоб желание, да время :)
6
06 октября 2008 года
George
4.1K / / 05.01.2007
начал писать прогу. суть такова - парсит дфм файл, те строки, которые нужны для перевод кидает в xml файл, оформленный должным образом. Затем спец. юнит по меткам в приложении грузит этот самый файл. Хочу сделать эту прогу опен сурс - так что если надо будет, поделюсь. :) Улучшите - скажу спасибо. Но есть вопрос - какой вариант лучше - INI или XML?
303
06 октября 2008 года
makbeth
1.0K / / 25.11.2004
Цитата: Washington
есть вопрос - какой вариант лучше - INI или XML?


А почему бы оба варианта не реализовать? На выбор, так сказать, пользователя? ;)

6
06 октября 2008 года
George
4.1K / / 05.01.2007
ну в будущем можно, но сейчас хоть с одним бы справиться. эта прога - побочный эффект работы надо бОльшим проектом. И очень сильно заморачиваться неохота, но все же надо сделать по уму.
303
06 октября 2008 года
makbeth
1.0K / / 25.11.2004
Ну как раз таки по уму будет парсер отдельно, загрузчик отдельно. Между ними - класс(ы), работающие с хранилищем (xml, txt, ini, БД).
По идее, парсер должен сказать "сохрани вот это..." классу, отвечающему за хранение, а формат его абсолютно не должен волновать. Аналогично и загрузчик: "загрузи мне вот это...". :)
А уж сами классы, отвечающие за хранение строк, каждый сам реализует так, как ему необходимо.
6
07 октября 2008 года
George
4.1K / / 05.01.2007
угу. пожалуй так и замучу. создам класс, который будет формировать xml файл. если кому нужен будет ини, при создании класса наследника это можно будет реализовать.
6
07 октября 2008 года
George
4.1K / / 05.01.2007
DFM парсер готов.
6
07 октября 2008 года
George
4.1K / / 05.01.2007
Правда парсит пока только Text и Caprion. А Items, Strings и пр. подобную лабуду присобачу позже. наверно
6
07 октября 2008 года
George
4.1K / / 05.01.2007
Прогу сделал. Осталось написать класс для загрузки ини файла куда надо :) напишу и выложу
6
09 октября 2008 года
George
4.1K / / 05.01.2007
усе сделал. вотЪ:
http://sources.codenet.ru/download/2180/Localizator_7z.html
если код сильно быдловатый, то не обессудьте. Но желание улучшить есть, если добавите поддержку например XML-файла или других свойств, то скиньте исходнеги. и жду мнений.

P.S. что планирую добавить:
1. Поддержку свойств Items и Lines
2. Перевод строковых констант, используемых например для StatusBar или для диалоговых окон.
6
05 ноября 2008 года
George
4.1K / / 05.01.2007
а кто-нибудь слышал про систему GetText? Я вот работаю с ней в CMS Drupal, так вроде эту систему и в дельфи встроить можно, в смысле не в среду, а в проекты на дельфи.
Реклама на сайте | Обмен ссылками | Ссылки | Экспорт (RSS) | Контакты
Добавить статью | Добавить исходник | Добавить хостинг-провайдера | Добавить сайт в каталог