У меня есть предложение ко всем - ввести разработку скриптов в UTF-8 и вообще все данные и в базе и везде хранить в UTF-8


Конечно, если система будет использоваться на каком-то русскоязычном сайте, то русские символы будут по два байта занимать, вместо 1-го байта в windows-1251, но зато мы навсегда решим все проблемы с кодировками. Я очень хочу, чтобы система была очень хорошо локазирована.


НО, все же, если взять наш форум в пример, то конвертация его базы в UTF-8, имхо было бы большой глупостью.

Что означает настоящая мультиязычность в CMS?

Настоящая мультиязычность, это когда на CMS можно построить сайт:
1. На любом языке
2. На нескольких языках сразу


С первым проблем у нас не будет, а вот со вторым могут быть. Т.к. сайты имеющие информацию на разных языках иногда имеют также разную структуру страниц. Я предлагаю, чтобы каждую создаваемую через CMS страницу, можно было бы создавать на нескольких языках. Пример вызова страницы:
domain.ru/?page=o_vingrade&lang=ru
domain.ru/?page=o_vingrade&lang=de

lang=ru - имеет смысл записывать наверное в сессию, чтобы не передавать с каждой ссылкой.

Wowa а как тогда будем хранить к примеру текст новостей на разных языках?
Тут проблема в этом. К тому же если пользователь захочет добавить язык, то придется еще столбец в БД записывать.

Цитата(Mal @ 17.6.2005, 16:52)

Wowa а как тогда будем хранить к примеру текст новостей на разных языках?

в UTF-8

Цитата(Mal @ 17.6.2005, 16:52)

Тут проблема в этом. К тому же если пользователь захочет добавить язык, то придется еще столбец в БД записывать.

Ну, это не проблема. Впрочем, я не уверен все равно, что это нужно в доп. столбце делать. Может быть отдельную запись создавать и как-то связывать.....

Цитата(Wowa @ 17.6.2005, 19:14)

Ну, это не проблема. Впрочем, я не уверен все равно, что это нужно в доп. столбце делать. Может быть отдельную запись создавать и как-то связывать.....

Вот меня этот вопрос существенно интересует. Сколько я не искал выходов, так и не нашел рациональлных.
Можно, конечно, делать для каждого модуля еще одну таблицу, куда псать
Модуль | ID записи в основной таблице |параметр (Название статьи) | Язык | текст на языке.
Как думаешь?

Цитата(Mal @ 17.6.2005, 17:24)

Как думаешь?

я считаю неплохим - вариант с доп. столбцом

по-моему следует сделать так:
для каждого модуля завести по две таблицы:
одна на данные которые переводить не нужно
вторая - для данных которые нужно переводить
структура второй таблицы:
id - внешний ключ - ссылка на первичный ключ первой таблицы
lang - внешний ключ - ссылка на певичный ключ таблицы языков
др. поля.

языки также будут храниться в двух аналогично построенных таблицах

по моему Mal Hack предложил оптимальный вариант

Ну да, тут особо вариантов нету.. добавлять lang к таблице, и выводить только у выбранных. Было бы неплохо систему как на php.net - язык выбирается автоматически, в то же время есть возможность выставить язык самому.

Так, а что думаете насчет UTF-8 ?

Wowa
а в чем проблема с cp1251? не сталкивался - не знаю, обоснуй?

Это сообщение отредактировал(а) Opik - 18.6.2005, 14:31

Цитата(Opik @ 18.6.2005, 15:31)

cp1251

А для японцев тоже cp1251?

Добавлено @ 15:11

Цитата(Opik @ 18.6.2005, 13:31)

а в чем проблема с cp1251? не сталкивался - не знаю, обоснуй?

В разных языках - разные алфавиты. В немецком языке есть буквы с умляутам, во франц. яз. - другие спец. буквы есть, литовский, латвийский, польский - там тоже отличия.
Добавлено @ 15:35
Кодировка, которая включает в себя символы всех нац. алфавитов - это UTF-8.

Wowa
понял

Цитата(Wowa @ 17.6.2005, 14:34)

Настоящая мультиязычность, это когда на CMS можно построить сайт: 1. На любом языке 2. На нескольких языках сразу

Только во втором пункте подребуеться UTF-x, а таких проектов очень мало, когда люди говорящие на разных языках постят контент друг другу. Увидел ли я китайские иероглифы или вопросики, по барабану, понять я это не смогу Отсюда сталкивамся с выбором, а стоит ли увеличивать размеры контента в 1.7 раз.

Если места много, то конечно надо писать в UTF-8, мало ли что в будущем всплывёт

Sardar Под вторым пунктом я подразумевал необязательный вывод контента на нескольких языках сразу. Это может быть таблица с контентом и столбцами для разных языков. А вывод будет осуществляться на том языке, на котором нужно. Но даже в этом случае нам нужен UTF-8, чтобы хранить эти разные языки в одной таблице.

А если для каждого языка свою кодировку?
ru - windows-1251
en - ещё какую нить и т.д.

Цитата(Opik @ 20.6.2005, 17:32)

А если для каждого языка свою кодировку? ru - windows-1251 en - ещё какую нить и т.д.

В принципе, НОВЫЕ версии MySQL поддерживают задание кодировок даже для столбцов http://dev.mysql.com/doc/mysql/en/charset-column.html

Но, как это работает на практике, не замедляет ли работу и не возникает ли проблем с поиском по базе - предстоит выяснить.


В качестве недостатка использования разных кодировок для разных языков - это невозможность написания нормальным способом на одной странице текста на разных языках. Это можно будет сделать только, если хтмльный уникод юзать. Но мне не нравится этот способ, Т.к. в нем руссукие символы тогда будут заниматься не 1 байт, как вин1251, не в байта, как в UTF-8, а 5-6 байтов.

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

определенно исползовать UTF.

Цитата(Wowa @ 20.6.2005, 20:14)

В принципе, НОВЫЕ версии MySQL поддерживают задание кодировок даже для столбцов http://dev.mysql.com/doc/mysql/en/charset-column.html

А я так понял что мы не только для MySQL делать будем.. К тому же как это будет работать - большой вопрос.

Цитата(Mal @ 20.6.2005, 18:19)

К тому же как это будет работать - большой вопрос.

Вот и я о том же. Думаю надо с UTF-8 работать и не заморачиваться. Но тогда и все скрипты должны писаться также в этой кодировке. Проверьте свои редакторы, чтобы могли в ней сохранять
Zend - умеет это хорошо

Мой DreamWeaver умеет Я рад

Цитата(Wowa @ 20.6.2005, 20:32)

Вот и я о том же. Думаю надо с UTF-8 работать и не заморачиваться. Но тогда и все скрипты должны писаться также в этой кодировке. Проверьте свои редакторы, чтобы могли в ней сохранять smile

латиница она и в африке латиница, на сколько я понимаю.

Цитата(Mal @ 20.6.2005, 20:08)

латиница она и в африке латиница, на сколько я понимаю.

да нет, попробуй сохранить любой текстовый файл к примеру в блокноте как UTF, а потом открыть одним из виндовских редакторов (напр PHP Expert Editor)

В кодах программы будут русские комментарии. Поэтому и коды должны быть в UTF-8
А так, как лат. буквы в UTF-8 занимают 1 байт, я не вижу причин противиться этому подходу.

А если заюзать http://ee.php.net/manual/ru/ref.gettext.php ?

Не нравится мне gettext Пробовал его юзать, какая-то чепуха. В прицнипе, я написал свою прогу для создании языковых файлов. Пока не жалусь. Досточно большой проект(из более, чем 10 модулей) ей перевел - без проблем.
Добавлено @ 00:38
Единственным преимуществом gettext вижу то, что он сам определяет новые слова в исходниках. В моей же системе сначала нужно слово занести, а затем вставить полученную переменную в код программы. Но проблем мне это не доставляло. Т.е. работать можно и удобно.

Wowa
в студию

Opik пока у меня на локалке стоит. Но я скоро покажу. Думаю по этому поводу беспокоится не стоит и думаю, что эту тему мы уже в принципе, можем закрывать пока.


Пришли к тому, что:
- вся система будет в UTF-8
- все скрипты также в UTF-8 должны писаться и сохраняться
- Для локализации будем использовать написанную мною софтину, которую я покажу, как только немного времени будет ее выложить.

Кстате, если у нас движек на XML+XSL, то ИМХО локализация на XML файлах будет очень хорошей идеей! Так как хочешь подгрузить просто файл к общему контенту проще чем его генерировать при помоще PHP и уже тогда добавлять в общий XML контент

Цитата(IZ @ 25.6.2005, 13:38)

Так как хочешь подгрузить просто файл к общему контенту проще чем его генерировать при помоще PHP и уже тогда добавлять в общий XML контент

Не понял, что ты имеешь ввиду...


Файлы локализации будут генерироваться автоматом при добавлении нового слова(черей мой софт). А в коде программы тебе надо будет просто вставлять $lang['имя модуля']['слово или фраза..']

Файлы затем выглядят так:
<?php
$lang['имя модуля']['слово или фраза..']="bla bla bla";
$lang['имя модуля']['слово или фраза..']="bla bla bla";
$lang['имя модуля']['слово или фраза..']="bla bla bla";
...
?>

и лежат в /locale/ru/modulename.php
А мы инклюдим нужные файлы, в зависимости, от вызванного модуля. Т.к. у нас будет описана также зависимость модулей от другух модулей в xml, то мы сможем при необходимости инклюдить несколько языковых файлов сразу.

А не проще сделать XML структуру локализационных файлов? Генерировать из будет еще проще, редактировать и добавлять новые тоже.

А выглядеть это будет примерно так:

Код

<?xml version="1.0" encoding="UTF-8"?> <Locale prefix="news" lang="ru">     <add_new>Добавить новую новость</add_new>     <delete_news>Удалить эту новость</delete_news>     <read_archive>Просмотреть архив новостей</read_news>     ... etc </Locale>

Wowa, моя имхА - каждому языку - свой XSL.

Добавлено @ 15:06
Перевод будет проще на другой язык + можно немного поменять структуру будет сразу.

Добавлено @ 15:06

Цитата(dm9 @ 25.6.2005, 16:05)

Wowa, моя имхА - каждому языку - свой XSL.

То есть свой набор XSL-файлов, естесно.

IZ@TOP интересное предложение... Но ихмо это немного замедлит работу системы, т.к. нам каждый раз нужно будет парсить этот файл при каждом вызове скрипта. А если модуль большой, то может быть очень много нужно будет парсить...
Добавлено @ 15:08

Цитата(dm9 @ 25.6.2005, 14:05)

То есть свой набор XSL-файлов, естесно.

Тоже интересно. Можешь дать краткий пример?
Добавлено @ 15:08

Цитата(dm9 @ 25.6.2005, 14:05)

То есть свой набор XSL-файлов, естесно.

Тоже интересно. Можешь дать краткий пример?

Цитата(Wowa @ 25.6.2005, 16:07)

То есть свой набор XSL-файлов, естесно. Тоже интересно. Можешь дать краткий пример?

Это видимо в каждом шаблоне есть несколько файлов на одного и того же модуля к примеру, но на разных языках. Типа ru.index.xsl, en.index.xsl.

Цитата(Wowa @ 25.6.2005, 16:07)

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

Дело в том что эти данные парсить не надо, просто подкачать в общий XML, а при работе с РНР файлами, надо будет каждый раз генерировать этот XML в общий документ

Цитата(IZ @ 25.6.2005, 14:40)

а при работе с РНР файлами, надо будет каждый раз генерировать этот XML в общий документ

Каждый раз, это как? При каждом запуске программы? А откуда будет генерироваться тогда этот общий XML? Из значений взятых из файлов той структуры, которую я предложил. Так?

Wowa, так. В общем будет так: или будем генерировать XML из РНР кода файлов локализации, либо подгружать отдельный XML файл, который будет обрабатываться XSL шаблоном, либо на сервере либо на клиенте (в большинстве случаев это будет наверняка второй вариант). Хотя конечно по такому принципу, XML траффику будет идти больше скорее всего. Но иначе смысла использовать XSL в качестве темлейтера я не вижу...

IZ@TOP лучше сделать один тег word, вместо кучи как у тебя, XSD схему будет сделать легче.

Код

<?xml version="1.0" encoding="UTF-8"?> <Locale lang="ru">    <module name="news" version="1.0+">       <word key="Add new">Добавить новую новость</word>       <word key="Delete post">Удалить эту новость</word>       <word key="Read archive">Просмотреть архив новостей</word>       <!-- etc... ->    </module> </Locale>

Цитата

Файлы локализации будут генерироваться автоматом при добавлении нового слова(черей мой софт). А в коде программы тебе надо будет просто вставлять $lang['имя модуля']['слово или фраза..']

Логичней не грузить весь пакет локализации для всех модулей, а грузить только необходимое. Обычно так не плохо:

Код

$lang=SysCore->loadLanguage("news"); echo $lang["Add new"];

Также хорошо бы хранить все пакеты локализаций в XML либо в базе, но не всё целиком выбирать/парсить.

Sardar, я имел ввиду что к примеру локализация контролов, к примеру, для просмотра прхива новостей хранится в файле controls.archive.news.xml, далее делаем

Код

<addlocale id="controls.archive.news" xml:base="path/to/locale/ru/controls.arhive.news.xml">

просто делаем xInclude для нашего документа и он подключает все необходимые файлы. И нет необходимости грузить все данные.
Так все данные мы будем парсить при помощи XSL и локализацию тоже.
Добавлено @ 19:15
В общем это еще продумать нужно как следует.

А как ты будешь выводить нужную надпись?

Можно хранить в XML файле, при его изменении генерировать новый PHP файлик, а в нем уже будет обычный массив, это если без заморочек с XSL трансформациями.

Opik, а как ты будешь подставлять в шаблоны эти данные? Снова создавать XML дерево?





Мне кажется что при таком построении локализационного XML будет тормозить выборка из него. Потому, что:

будет обработано дерево с поиском по значению атрибутов.

По моему отработает несколько быстрее.

А не слишком ли это длинная строка, из-за которой может потеряться читабельность кода для нас?

Wowa, иных вариантов для подстановки данных я незнаю. К тому же читабельность кода от этого как мне кажется не сильно пострадает.

Тут собственно два варианта:
1. это подставлять, как обычную пхп-переменную на стадии генерации XML. Т.е. $lang["module"]["key"]
2. твой вариант. В принципе попробовать что-либо новое мне всегда интересно. Поэтому я ничего против не имею.

У меня есть написанный мною интерфейс для локализации, который запишет всё в нужном формате в статические XML-файлы. Я скоро залью. Только сначала надо тогда определиться все-таки с форматов XML.

К сожалению это невозможно - если мы будем весь XSL отдавать пользователю для трансформаии на стороне клиента.



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

Почему? Можно 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 код внутри - особо не смотрите. Я писал давно, когда еще многого не знал  Но работает все хорошо.