Почему? Можно XSLT ведь динамически генерировать?

Я делал локализацию для форума на яве. Мне вариант с ХМЛ очень понравился. Ставим в заголовке время жизни файла на бесконечность и клиент его подгрузит один раз в жизни. Трафф и рессурсы экономятся весьма. В таком случае нам по большому счёту пофиг на кодировку и можем(те) делать спокойно УТФ-8, не беспокоясь за трафф. (это естесственно не относится к файлам сгенеренным на сервере, но таких случаев будет ничтожно мало.)


Я в своём варианте просто упростил это. Существует фаил core.xsl, который содержит все необходимые функции и подгружается ко всем xslям (кстати механизм подгрузки я там тоже разработал  и не забываем, что этот файл тоже кэшируется!) вот примерно как будет переводится слово:



А сам словарь грузится так:

Для этого естественно в сгенеренном  xml передаётся переменная- название файла для перевода остальное скрипт сам сделает.


ПС:
Вообще, я когда им занимался, много интересных вещей сделал. Жалко, что времени сейчас нет 

Добавлено @ 23:57 
Сам файл - словарь


Позже напишу, как в ХМЛ вставлять переменную, чтобы правйный словарь грузить

Добавлено @ 00:01 

sergej.z, одна проблема - это тот же gettext, но в XML. Благодаря xInclude можно инцлюдить необходимые строки, но это по прежнему статика. А как сделать:

Для строки в окошке с новыми сообшениями?

Сделал переводчик, умеет форматировать выражения, началось как нечто универсальное, но в итоге для выражений использую PHP. На входе XML, который компилиться в PHP (сохраняеться в кеше пока исходник не измениться), работает шустро, но идеологически не "совершенство". Пример date.ru.xlp:



Писал ещё в прошлом году, будет время доработаю. В идеале языковой пакет должен быть кратким, менее "имеративным" и заточенным именно под форматирование (я не лингвист, ориентируюсь на русский/английский/голландский).

А так делать не надо  Вполне можно обойтись: "Непрочитанных писем: 0(1, 2....)". И так имхо всегда - можно найти замену. Зачем себя нагружать на пустом месте? 

Вот, состряпал статический вариант. Распаковываем, открываем index.xml  и пляшем оттуда. Работает только страница логина. Какие данные введёте - пофиг. Главное - поиграйте со страницей, посмотрите исходники . Мне лично очень понравилось, как получилось. Особенно обратите внимание на размер файлов ХМЛ  (Например для страницы с логином)


Там в  afterlogin.xml Попробуй поменять в нём параметр  mails. Думаю, без проблем разберёшься, а ро я там тонкостей уже не помню. Полгода прошло.. На крайняк для первых 10 значений для всех языков дифференциировать..

Добавлено @ 01:10 

В принципе согласен, но ведь нет предела совершенству )))

Присоединённый файл ( Кол-во скачиваний: 9 )
 localisation_static.zip 44,10 Kb

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

Продукт отличаеться от хорошего продукта мелочами 


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



С одной стороны не реюзабельно, положить подобное в отдельный языковой пакет позволит держать некую либу форматирования, например для дат и не зависить от системной локали. Также можно будет делать общий .xsl шаблон для всех языков (единая шкурка), что ИМХО удобно. С другой стороны если скзать честно, почти все мои остальные языковые пакеты содержат только статику...    а когда оно в шаблоне, то выглядит логично, сам шаблон разбиваем по модулям, но получиться отдельный скин для каждого языка, а добавление языка будет сложным, нужно отследить все строки...

sergej.z, ещё не переубедил, но смутил 

Я против хранения шаблонов на разных языках - представить боюсь что будет если понадобиться что-то поменять в шаблоне!!! Этож нужно будет их все переделывать   

Да, я тоже против! 

С ХМЛ одна траблочка. Гр%$&анная Опера не подгружает ХМЛ с помощью document(). (возможно в новых версиях они исправили, не смотрел).
В этом случае предлагаю словарь грузить в главный ХМЛ. В принципе будет не намного страшнее, хотя и не так красиво. Если контент гзипится, то на трафф нагрузка всё равно будет в разы меньше, чем в ХТМЛ.

ПС: Кстати в моём примере автоматически поддерживаются несколько скинов. В ХМЛе просто стоят параметры, откуда брать картинки, css итд. Короче говоря там почти всё (или всё  ) в плане фрэймворка готово. Новые страницы очень легко пишуться. 

А еще Firefox не знает что такое disable-output-escaping у xsl:value-of. Но это мелочи. Для оперы можно парсить все на стороне сервера. Благо оперой пользуются не так много человек (надеюсь   ). В случае с Firefox беспокоиться не стоит если все документы будут валидным XML/XHTML'ем.

На счет стандарта шаблонов: если кто хочет описать свою идею (некий стандарт построения), давайте в отдельный топик. Разумеется с учетом мультидоменности - чтобы были общие шаблоны для всех, приватные для отдельных сайтов и т.п.

http://forum.vingrad.ru/index.php?showtopi...st&p=847773

Ребята, я залил на SVN папку sys_admin. В ней находится написанная мною утилита для создания языковых файлов в любом формате(там шаблонная система). На ней я уже много проектов сделал. Вполне удобно.

Если у кого-то есть варинты лучше - то пишите. Иначе же прошу всех ознакомиться с моей утилитой и начать ее использовать как можно быстрее. Обязательно прочтите в этой папке файл readme.txt. Там инструкции по установке.


P.S. На php код внутри - особо не смотрите. Я писал давно, когда еще многого не знал  Но работает все хорошо.