| Цитата(Opik @ 18.6.2005, 15:31) |
| cp1251 |
А для японцев тоже cp1251?
Добавлено @ 15:11
| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Vingrad CMS > Локализация и кодировка системы |
| Автор: Wowa 17.6.2005, 15:12 |
| У меня есть предложение ко всем - ввести разработку скриптов в UTF-8 и вообще все данные и в базе и везде хранить в UTF-8 Конечно, если система будет использоваться на каком-то русскоязычном сайте, то русские символы будут по два байта занимать, вместо 1-го байта в windows-1251, но зато мы навсегда решим все проблемы с кодировками. Я очень хочу, чтобы система была очень хорошо локазирована. НО, все же, если взять наш форум в пример, то конвертация его базы в UTF-8, имхо было бы большой глупостью. |
| Автор: Wowa 17.6.2005, 15:34 |
| Что означает настоящая мультиязычность в CMS? Настоящая мультиязычность, это когда на CMS можно построить сайт: 1. На любом языке 2. На нескольких языках сразу С первым проблем у нас не будет, а вот со вторым могут быть. Т.к. сайты имеющие информацию на разных языках иногда имеют также разную структуру страниц. Я предлагаю, чтобы каждую создаваемую через CMS страницу, можно было бы создавать на нескольких языках. Пример вызова страницы: domain.ru/?page=o_vingrade&lang=ru domain.ru/?page=o_vingrade&lang=de lang=ru - имеет смысл записывать наверное в сессию, чтобы не передавать с каждой ссылкой. |
| Автор: Mal Hack 17.6.2005, 17:52 |
| Wowa а как тогда будем хранить к примеру текст новостей на разных языках? Тут проблема в этом. К тому же если пользователь захочет добавить язык, то придется еще столбец в БД записывать. |
| Автор: Wowa 17.6.2005, 18:14 | ||||
в UTF-8
Ну, это не проблема. Впрочем, я не уверен все равно, что это нужно в доп. столбце делать. Может быть отдельную запись создавать и как-то связывать..... |
| Автор: Mal Hack 17.6.2005, 18:24 | ||
Вот меня этот вопрос существенно интересует. Сколько я не искал выходов, так и не нашел рациональлных. Можно, конечно, делать для каждого модуля еще одну таблицу, куда псать Модуль | ID записи в основной таблице |параметр (Название статьи) | Язык | текст на языке. Как думаешь? |
| Автор: Wowa 17.6.2005, 18:30 | ||
я считаю неплохим - вариант с доп. столбцом |
| Автор: Irokez 17.6.2005, 19:14 |
| по-моему следует сделать так: для каждого модуля завести по две таблицы: одна на данные которые переводить не нужно вторая - для данных которые нужно переводить структура второй таблицы: id - внешний ключ - ссылка на первичный ключ первой таблицы lang - внешний ключ - ссылка на певичный ключ таблицы языков др. поля. языки также будут храниться в двух аналогично построенных таблицах |
| Автор: Gold Dragon 18.6.2005, 10:54 |
| по моему Mal Hack предложил оптимальный вариант |
| Автор: Opik 18.6.2005, 14:27 |
| Ну да, тут особо вариантов нету.. добавлять lang к таблице, и выводить только у выбранных. Было бы неплохо систему как на php.net - язык выбирается автоматически, в то же время есть возможность выставить язык самому. |
| Автор: Wowa 18.6.2005, 14:28 |
| Так, а что думаете насчет UTF-8 ? |
| Автор: Opik 18.6.2005, 14:31 |
| Wowa а в чем проблема с cp1251? не сталкивался - не знаю, обоснуй? |
| Автор: dm9 18.6.2005, 15:11 | ||
А для японцев тоже cp1251? Добавлено @ 15:11 |
| Автор: Wowa 18.6.2005, 15:34 | ||
В разных языках - разные алфавиты. В немецком языке есть буквы с умляутам, во франц. яз. - другие спец. буквы есть, литовский, латвийский, польский - там тоже отличия. Добавлено @ 15:35 Кодировка, которая включает в себя символы всех нац. алфавитов - это UTF-8. |
| Автор: Opik 18.6.2005, 15:41 |
| Wowa понял |
| Автор: Sardar 18.6.2005, 17:15 | ||
Только во втором пункте подребуеться UTF-x, а таких проектов очень мало, когда люди говорящие на разных языках постят контент друг другу. Увидел ли я китайские иероглифы или вопросики, по барабану, понять я это не смогу Отсюда сталкивамся с выбором, а стоит ли увеличивать размеры контента в 1.7 раз.Если места много, то конечно надо писать в UTF-8, мало ли что в будущем всплывёт |
| Автор: Wowa 18.6.2005, 17:33 |
| Sardar Под вторым пунктом я подразумевал необязательный вывод контента на нескольких языках сразу. Это может быть таблица с контентом и столбцами для разных языков. А вывод будет осуществляться на том языке, на котором нужно. Но даже в этом случае нам нужен UTF-8, чтобы хранить эти разные языки в одной таблице. |
| Автор: Opik 20.6.2005, 18:32 |
| А если для каждого языка свою кодировку? ru - windows-1251 en - ещё какую нить и т.д. |
| Автор: Wowa 20.6.2005, 19:14 | ||
В принципе, НОВЫЕ версии MySQL поддерживают задание кодировок даже для столбцов http://dev.mysql.com/doc/mysql/en/charset-column.html Но, как это работает на практике, не замедляет ли работу и не возникает ли проблем с поиском по базе - предстоит выяснить. В качестве недостатка использования разных кодировок для разных языков - это невозможность написания нормальным способом на одной странице текста на разных языках. Это можно будет сделать только, если хтмльный уникод юзать. Но мне не нравится этот способ, Т.к. в нем руссукие символы тогда будут заниматься не 1 байт, как вин1251, не в байта, как в UTF-8, а 5-6 байтов. Далее. Если пользователь зарегистрировался и ввел инфу о себе на русском при кодировке windows-1251, а затем переключил язык интерфейса на англ. яз.,то вся информация, которую он ранее ввел, будет для него кракозябликами отображаться. |
| Автор: Mal Hack 20.6.2005, 19:19 | ||
определенно исползовать UTF.
А я так понял что мы не только для MySQL делать будем.. К тому же как это будет работать - большой вопрос. |
| Автор: Wowa 20.6.2005, 19:32 | ||
Вот и я о том же. Думаю надо с UTF-8 работать и не заморачиваться. Но тогда и все скрипты должны писаться также в этой кодировке. Проверьте свои редакторы, чтобы могли в ней сохранять Zend - умеет это хорошо |
| Автор: IZ@TOP 20.6.2005, 19:36 |
Мой DreamWeaver умеет Я рад  |
| Автор: Mal Hack 20.6.2005, 20:08 | ||
латиница она и в африке латиница, на сколько я понимаю. |
| Автор: Irokez 20.6.2005, 20:14 | ||
да нет, попробуй сохранить любой текстовый файл к примеру в блокноте как UTF, а потом открыть одним из виндовских редакторов (напр PHP Expert Editor) |
| Автор: Wowa 20.6.2005, 20:59 |
| В кодах программы будут русские комментарии. Поэтому и коды должны быть в UTF-8 А так, как лат. буквы в UTF-8 занимают 1 байт, я не вижу причин противиться этому подходу. |
| Автор: Opik 21.6.2005, 00:34 |
| А если заюзать http://ee.php.net/manual/ru/ref.gettext.php ? |
| Автор: Wowa 21.6.2005, 00:37 |
| Не нравится мне gettext Пробовал его юзать, какая-то чепуха. В прицнипе, я написал свою прогу для создании языковых файлов. Пока не жалусь. Досточно большой проект(из более, чем 10 модулей) ей перевел - без проблем. Добавлено @ 00:38 Единственным преимуществом gettext вижу то, что он сам определяет новые слова в исходниках. В моей же системе сначала нужно слово занести, а затем вставить полученную переменную в код программы. Но проблем мне это не доставляло. Т.е. работать можно и удобно. |
| Автор: Opik 21.6.2005, 00:38 |
| Wowa в студию |
| Автор: Wowa 21.6.2005, 00:41 |
| Opik пока у меня на локалке стоит. Но я скоро покажу. Думаю по этому поводу беспокоится не стоит и думаю, что эту тему мы уже в принципе, можем закрывать пока. Пришли к тому, что: - вся система будет в UTF-8 - все скрипты также в UTF-8 должны писаться и сохраняться - Для локализации будем использовать написанную мною софтину, которую я покажу, как только немного времени будет ее выложить. |
| Автор: IZ@TOP 25.6.2005, 14:38 |
| Кстате, если у нас движек на XML+XSL, то ИМХО локализация на XML файлах будет очень хорошей идеей! Так как хочешь подгрузить просто файл к общему контенту проще чем его генерировать при помоще PHP и уже тогда добавлять в общий XML контент |
| Автор: Wowa 25.6.2005, 14:44 | ||
Не понял, что ты имеешь ввиду... Файлы локализации будут генерироваться автоматом при добавлении нового слова(черей мой софт). А в коде программы тебе надо будет просто вставлять $lang['имя модуля']['слово или фраза..'] Файлы затем выглядят так: <?php $lang['имя модуля']['слово или фраза..']="bla bla bla"; $lang['имя модуля']['слово или фраза..']="bla bla bla"; $lang['имя модуля']['слово или фраза..']="bla bla bla"; ... ?> и лежат в /locale/ru/modulename.php А мы инклюдим нужные файлы, в зависимости, от вызванного модуля. Т.к. у нас будет описана также зависимость модулей от другух модулей в xml, то мы сможем при необходимости инклюдить несколько языковых файлов сразу. |
| Автор: IZ@TOP 25.6.2005, 15:04 | ||
| А не проще сделать XML структуру локализационных файлов? Генерировать из будет еще проще, редактировать и добавлять новые тоже. А выглядеть это будет примерно так:
|
| Автор: dm9 25.6.2005, 15:05 | ||
| Wowa, моя имхА - каждому языку - свой XSL. Добавлено @ 15:06 Перевод будет проще на другой язык + можно немного поменять структуру будет сразу. Добавлено @ 15:06
То есть свой набор XSL-файлов, естесно. |
| Автор: Wowa 25.6.2005, 15:07 | ||||
| IZ@TOP интересное предложение... Но ихмо это немного замедлит работу системы, т.к. нам каждый раз нужно будет парсить этот файл при каждом вызове скрипта. А если модуль большой, то может быть очень много нужно будет парсить... Добавлено @ 15:08
Тоже интересно. Можешь дать краткий пример? Добавлено @ 15:08
Тоже интересно. Можешь дать краткий пример? |
| Автор: IZ@TOP 25.6.2005, 15:40 | ||||
Это видимо в каждом шаблоне есть несколько файлов на одного и того же модуля к примеру, но на разных языках. Типа ru.index.xsl, en.index.xsl.
Дело в том что эти данные парсить не надо, просто подкачать в общий XML, а при работе с РНР файлами, надо будет каждый раз генерировать этот XML в общий документ |
| Автор: Wowa 25.6.2005, 15:42 | ||
Каждый раз, это как? При каждом запуске программы? А откуда будет генерироваться тогда этот общий XML? Из значений взятых из файлов той структуры, которую я предложил. Так? |
| Автор: IZ@TOP 25.6.2005, 16:14 |
| Wowa, так. В общем будет так: или будем генерировать XML из РНР кода файлов локализации, либо подгружать отдельный XML файл, который будет обрабатываться XSL шаблоном, либо на сервере либо на клиенте (в большинстве случаев это будет наверняка второй вариант). Хотя конечно по такому принципу, XML траффику будет идти больше скорее всего. Но иначе смысла использовать XSL в качестве темлейтера я не вижу... |
| Автор: Sardar 25.6.2005, 18:52 | ||||||
IZ@TOP лучше сделать один тег word, вместо кучи как у тебя, XSD схему будет сделать легче.
Логичней не грузить весь пакет локализации для всех модулей, а грузить только необходимое. Обычно так не плохо:
Также хорошо бы хранить все пакеты локализаций в XML либо в базе, но не всё целиком выбирать/парсить. |
| Автор: IZ@TOP 25.6.2005, 19:11 | ||
Sardar, я имел ввиду что к примеру локализация контролов, к примеру, для просмотра прхива новостей хранится в файле controls.archive.news.xml, далее делаем
Так все данные мы будем парсить при помощи XSL и локализацию тоже. Добавлено @ 19:15 В общем это еще продумать нужно как следует. |
| Автор: Wowa 2.9.2006, 00:46 | ||
А как ты будешь выводить нужную надпись? |
| Автор: Opik 2.9.2006, 16:48 |
| Можно хранить в XML файле, при его изменении генерировать новый PHP файлик, а в нем уже будет обычный массив, это если без заморочек с XSL трансформациями. |
| Автор: IZ@TOP 4.9.2006, 15:37 | ||||||||||
Opik, а как ты будешь подставлять в шаблоны эти данные? Снова создавать XML дерево?
Мне кажется что при таком построении локализационного XML будет тормозить выборка из него. Потому, что:
будет обработано дерево с поиском по значению атрибутов.
По моему отработает несколько быстрее. |
| Автор: Wowa 4.9.2006, 17:48 | ||
А не слишком ли это длинная строка, из-за которой может потеряться читабельность кода для нас? |
| Автор: IZ@TOP 4.9.2006, 18:03 |
| Wowa, иных вариантов для подстановки данных я незнаю. К тому же читабельность кода от этого как мне кажется не сильно пострадает. |
| Автор: Wowa 4.9.2006, 18:08 |
| Тут собственно два варианта: 1. это подставлять, как обычную пхп-переменную на стадии генерации XML. Т.е. $lang["module"]["key"] 2. твой вариант. В принципе попробовать что-либо новое мне всегда интересно. Поэтому я ничего против не имею. У меня есть написанный мною интерфейс для локализации, который запишет всё в нужном формате в статические XML-файлы. Я скоро залью. Только сначала надо тогда определиться все-таки с форматов XML. |
| Автор: IZ@TOP 4.9.2006, 19:48 | ||||||
К сожалению это невозможно - если мы будем весь XSL отдавать пользователю для трансформаии на стороне клиента.
С локализаией нужно бы подумать. Было бы очень хорошо отдавать XML файлик юзеру и чтобы он у него кешировался - это было бы просто замечательно, потому как небыло бы необходимости отдавать его каждый раз и нагружать при этом сервер. Формат все же, думаю, лучше такой:
|
| Автор: Wowa 4.9.2006, 22:19 | ||
Почему? Можно XSLT ведь динамически генерировать? |
| Автор: sergejzr 4.9.2006, 23:50 | ||||||||||||
Я делал локализацию для форума на яве. Мне вариант с ХМЛ очень понравился. Ставим в заголовке время жизни файла на бесконечность и клиент его подгрузит один раз в жизни. Трафф и рессурсы экономятся весьма. В таком случае нам по большому счёту пофиг на кодировку и можем(те) делать спокойно УТФ-8, не беспокоясь за трафф. (это естесственно не относится к файлам сгенеренным на сервере, но таких случаев будет ничтожно мало.)
Я в своём варианте просто упростил это. Существует фаил core.xsl, который содержит все необходимые функции и подгружается ко всем xslям (кстати механизм подгрузки я там тоже разработал и не забываем, что этот файл тоже кэшируется!) вот примерно как будет переводится слово:
А сам словарь грузится так:
Для этого естественно в сгенеренном xml передаётся переменная- название файла для перевода остальное скрипт сам сделает. ПС: Вообще, я когда им занимался, много интересных вещей сделал. Жалко, что времени сейчас нет Добавлено @ 23:57 Сам файл - словарь
Позже напишу, как в ХМЛ вставлять переменную, чтобы правйный словарь грузить Добавлено @ 00:01
|
| Автор: Sardar 5.9.2006, 00:22 | ||||
sergej.z, одна проблема - это тот же gettext, но в XML. Благодаря xInclude можно инцлюдить необходимые строки, но это по прежнему статика. А как сделать:
Для строки в окошке с новыми сообшениями? Сделал переводчик, умеет форматировать выражения, началось как нечто универсальное, но в итоге для выражений использую PHP. На входе XML, который компилиться в PHP (сохраняеться в кеше пока исходник не измениться), работает шустро, но идеологически не "совершенство". Пример date.ru.xlp:
Писал ещё в прошлом году, будет время доработаю. В идеале языковой пакет должен быть кратким, менее "имеративным" и заточенным именно под форматирование (я не лингвист, ориентируюсь на русский/английский/голландский). |
| Автор: Wowa 5.9.2006, 00:54 | ||
А так делать не надо Вполне можно обойтись: "Непрочитанных писем: 0(1, 2....)". И так имхо всегда - можно найти замену. Зачем себя нагружать на пустом месте? |
| Автор: sergejzr 5.9.2006, 01:09 | ||||
Вот, состряпал статический вариант. Распаковываем, открываем index.xml и пляшем оттуда. Работает только страница логина. Какие данные введёте - пофиг. Главное - поиграйте со страницей, посмотрите исходники . Мне лично очень понравилось, как получилось. Особенно обратите внимание на размер файлов ХМЛ (Например для страницы с логином)
Там в afterlogin.xml Попробуй поменять в нём параметр mails. Думаю, без проблем разберёшься, а ро я там тонкостей уже не помню. Полгода прошло.. На крайняк для первых 10 значений для всех языков дифференциировать.. Добавлено @ 01:10
В принципе согласен, но ведь нет предела совершенству ))) |
| Автор: IZ@TOP 5.9.2006, 10:58 | ||
Собственно именно это нам и нужно. Большие заморочки нам наверное не сильно нужны, ну а если и понядобятся, то добавить всякие лингвистические проверки будет не сложно в самой логике шаблона. |
| Автор: Sardar 5.9.2006, 11:26 | ||||||||
Продукт отличаеться от хорошего продукта мелочами 
По сути выделить минимум операций необходимых для построения и форматирования строки, затем это собираеться автоматом в PHP, который перестраиваеться как только перестроился языковой пакет. Также устроены все шаблонизаторы с "компиляцией в PHP", это не кажеться чем то особо сложным или навороченным ведь?
С одной стороны не реюзабельно, положить подобное в отдельный языковой пакет позволит держать некую либу форматирования, например для дат и не зависить от системной локали. Также можно будет делать общий .xsl шаблон для всех языков (единая шкурка), что ИМХО удобно. С другой стороны если скзать честно, почти все мои остальные языковые пакеты содержат только статику... а когда оно в шаблоне, то выглядит логично, сам шаблон разбиваем по модулям, но получиться отдельный скин для каждого языка, а добавление языка будет сложным, нужно отследить все строки...sergej.z, ещё не переубедил, но смутил |
| Автор: IZ@TOP 5.9.2006, 12:05 | ||
Я против хранения шаблонов на разных языках - представить боюсь что будет если понадобиться что-то поменять в шаблоне!!! Этож нужно будет их все переделывать  |
| Автор: sergejzr 5.9.2006, 12:20 | ||
Да, я тоже против! С ХМЛ одна траблочка. Гр%$&анная Опера не подгружает ХМЛ с помощью document(). (возможно в новых версиях они исправили, не смотрел). В этом случае предлагаю словарь грузить в главный ХМЛ. В принципе будет не намного страшнее, хотя и не так красиво. Если контент гзипится, то на трафф нагрузка всё равно будет в разы меньше, чем в ХТМЛ. ПС: Кстати в моём примере автоматически поддерживаются несколько скинов. В ХМЛе просто стоят параметры, откуда брать картинки, css итд. Короче говоря там почти всё (или всё ) в плане фрэймворка готово. Новые страницы очень легко пишуться. |
| Автор: IZ@TOP 5.9.2006, 12:48 | ||
А еще Firefox не знает что такое disable-output-escaping у xsl:value-of. Но это мелочи. Для оперы можно парсить все на стороне сервера. Благо оперой пользуются не так много человек (надеюсь  ). В случае с Firefox беспокоиться не стоит если все документы будут валидным XML/XHTML'ем.На счет стандарта шаблонов: если кто хочет описать свою идею (некий стандарт построения), давайте в отдельный топик. Разумеется с учетом мультидоменности - чтобы были общие шаблоны для всех, приватные для отдельных сайтов и т.п. |
| Автор: sergejzr 8.9.2006, 03:26 | ||
http://forum.vingrad.ru/index.php?showtopic=111041&view=findpost&p=847773 |
| Автор: Wowa 8.9.2006, 20:47 |
| Ребята, я залил на SVN папку sys_admin. В ней находится написанная мною утилита для создания языковых файлов в любом формате(там шаблонная система). На ней я уже много проектов сделал. Вполне удобно. Если у кого-то есть варинты лучше - то пишите. Иначе же прошу всех ознакомиться с моей утилитой и начать ее использовать как можно быстрее. Обязательно прочтите в этой папке файл readme.txt. Там инструкции по установке. P.S. На php код внутри - особо не смотрите. Я писал давно, когда еще многого не знал Но работает все хорошо. |
