Давно собирался решить эту проблему. Заключается она в том, что изначально некоторые строковые переменные прописаны в скриптах форума, а не в языковых файлах, где им бы следовало быть. Соответственно, это усложняет локализацию форума и его работу одновременно с несколькими языками интерфейса. Некоторые строки, первоначально бывшие в скриптах, я уже вынес в языковые файлы (актуально для версии ExBB FM 1.0 RC2), но вполне возможно, что какие-то из них я мог пропустить. Поэтому даже если Вам кажется, что это уже обсуждалось, продублируйте информацию в этой теме
Данный вопрос касается не только строковых переменных, но и регулярных выражений в скриптах форума. Надеюсь, с Вашей помощью удастся реализовать полную локализуемость для ExBB FM 1.0 RC2 без необходимости правки скриптов
1. yura3d - 24 августа 2009 — 19:11 - перейти к сообщению
2. M-A-X - 24 августа 2009 — 19:18 - перейти к сообщению
Если не в тему, то удалите 
Тему нельзя начать на украинскую букву "І"
примерно 152 строка post.php
заменить
Тему нельзя начать на украинскую букву "І"
примерно 152 строка post.php
CODE:
if (preg_match("#^[^A-Za-zА-Яа-я0-9]#is"
заменить
CODE:
if (preg_match("#^[^A-Za-zА-Яа-яІі0-9]#is"
3. yura3d - 24 августа 2009 — 20:00 - перейти к сообщению
M-A-X пишет:
Если не в тему, то удалите
Тему нельзя начать на украинскую букву "І"
Тему нельзя начать на украинскую букву "І"
Спасибо, в дальнейшем, если найдёте подобные недочёты, также выкладывайте их в эту тему
4. M-A-X - 24 августа 2009 — 21:11 - перейти к сообщению
fm.class.php 176 строка и ниже выводит месяцы только на русском
Примерно 939 строка, на что влияет сразу не въехал, по ходу что-то режет :
vars.class.php
Примерно 211 строка:
Удалять-то, наверное, не нужно, просто додати українську букву "і" И латынь по алфавиту переписать, чтоб было кошерно И может добавить букв типа ö 
topic.php 356 строка:
CODE:
/*
_DateFormat Форматирование даны в виде 21 Декабря, 2006 - 20:03:17
*/
function _DateFormat($time) {
$rus_m = array ('01'=>'Января','02'=>'Февраля','03'=>'Марта','04'=>'Апреля','05'=>'Мая','06'=>'Июня',
'07'=>'Июля','08'=>'Августа','09'=>'Сентября','10'=>'Октября','11'=>'Ноября','12'=>'Декабря');
$currDay = strftime ("%d",$time);
$currMonth = strftime ("%m",$time);
$currYear = strftime ("%Y",$time);
$tm = date("H:i:s",$time);
return $currDay.' '.$rus_m[$currMonth].', '.$currYear.' - '.$tm;
}
_DateFormat Форматирование даны в виде 21 Декабря, 2006 - 20:03:17
*/
function _DateFormat($time) {
$rus_m = array ('01'=>'Января','02'=>'Февраля','03'=>'Марта','04'=>'Апреля','05'=>'Мая','06'=>'Июня',
'07'=>'Июля','08'=>'Августа','09'=>'Сентября','10'=>'Октября','11'=>'Ноября','12'=>'Декабря');
$currDay = strftime ("%d",$time);
$currMonth = strftime ("%m",$time);
$currYear = strftime ("%Y",$time);
$tm = date("H:i:s",$time);
return $currDay.' '.$rus_m[$currMonth].', '.$currYear.' - '.$tm;
}
Примерно 939 строка, на что влияет сразу не въехал, по ходу что-то режет
:CODE:
function chunk_split($string)
vars.class.php
Примерно 211 строка:
CODE:
function _strtoupper($var) и function _strtolower
Удалять-то, наверное, не нужно, просто додати українську букву "і"
И латынь по алфавиту переписать, чтоб было кошерно И может добавить букв типа ö topic.php 356 строка:
CODE:
По ходу ни на что не влияет $fm->_Link .= "\n<LINK rel=\"Start\" title=\"Первая страница темы - First page\"
5. altjo - 14 октября 2009 — 16:25 - перейти к сообщению
надеюсь по теме )
в файле memblist.tpl
не знаю исправлено это или нет, но
т.к. "Сортировать по" должно быть справа, а не слева
http://exbb.info/community/tools...p?action=members
в файле memblist.tpl
CODE:
<div style="float:left;">{$fm->LANG['PrintBy']}
<input name="pg" type="text" value="{$per_page}" size="2">{$fm->LANG['UsersByList']}
{$fm->LANG['SortBy']}
</div>
<input name="pg" type="text" value="{$per_page}" size="2">{$fm->LANG['UsersByList']}
{$fm->LANG['SortBy']}
</div>
не знаю исправлено это или нет, но
CODE:
нужно вынести сразу после {$fm->LANG['SortBy']}
т.к. "Сортировать по" должно быть справа, а не слева
http://exbb.info/community/tools...p?action=members
6. altjo - 17 октября 2009 — 15:16 - перейти к сообщению
если под строковыми переменными понимался русский текст, то вот
topic.php
Первая страница темы
tools.php
Правила не установлены
-------------
в папке InvisionExBB
полным полно русского текста
all_header.tpl
email_newtopic.tpl
email_reply.tpl
в файле moveposts_data.tpl
Название темы:
Описание темы:
в файле post_edit.tpl
Добавить подпись редактора?
в файле post_form.tpl
Быстрый ответ в тему
value="Очистить"
-------------
в папке include
upload.class.php
Ошибка загрузки файла!
fm.class.php
Января
...
Декабря
-------------
в папке modules/rss
frontindex.php
В форуме:
Последние сообщения на форуме
topic.php
Первая страница темы
tools.php
Правила не установлены
-------------
в папке InvisionExBB
полным полно русского текста
all_header.tpl
email_newtopic.tpl
email_reply.tpl
в файле moveposts_data.tpl
Название темы:
Описание темы:
в файле post_edit.tpl
Добавить подпись редактора?
в файле post_form.tpl
Быстрый ответ в тему
value="Очистить"
-------------
в папке include
upload.class.php
Ошибка загрузки файла!
fm.class.php
Января
...
Декабря
-------------
в папке modules/rss
frontindex.php
В форуме:
Последние сообщения на форуме
7. altjo - 28 июля 2010 — 09:32 - перейти к сообщению
еще есть оочень много языковых строк в /data/smiles.php
8. yura3d - 29 июля 2010 — 08:53 - перейти к сообщению
altjo пишет:
еще есть оочень много языковых строк в /data/smiles.php
Не думаю, что описания смайлов можно отнести к языковым строкам. Даже если и вынести эти строки в языковые файлы, то что делать с новыми смайлами, добавляемыми через админку?
9. igrok54 - 19 сентября 2010 — 12:59 - перейти к сообщению
Просьба по данной теме.
Если уж собрались чистить код в сторону локализации, то не лишним будет мой опыт по переводу движка форума в кодировку UTF-8, а точнее те проблемы, с которыми пришлось столкнуться.
1. Поддерживаю упомянутый altjo вопрос о файле data/smiles.php - на его перевод было потрачено немало времени из-за того, что в нем кроме всего прочего форма хранения данных идет с учетом количества байтов... А, как известно, кодировка windows-1251 - однобайтная, UTF-8 - двухбайтная. Поэтому переводить пришлось через веб-интерфейс, редактируя русский текст сначала в латиницу на форуме в windows-1251, потом этот же файл кидать на форум в UTF-8 и обратно переводить в кирилицу... Если бы база смайлов хранилась в другой форме, без указания количества байтов, процесс бы вместо нескольких часов занял бы пару минут максимум...
2. В движке часто требуется урезание строк, например для вывода длинного заголовка топика на главной странице и т.п. В коде это делается с помощью php-функции substr, которая криво работает с UTF-8, поэтому эту функцию в тех местах, где производится урезание текста на русском пришлось заменять на аналогичную функцию mb_substr, для которой можно указать кодировку. Пример: строка 99 index.php
было:
заменил на:
красным цветом - изменения.
Попутно, если смотреть еще в сторону возможности выбора пользователем кодировки заново устанавливаемого форума, то в движке имеется переменная $GLOBALS['fm']->LANG['ENCODING'] доступная везде, в которой содержиться строка с кодировкой сайта: "windows-1251". Следовательно, если бы все вхождения русского текста находились в языковых файлах, то все исполняющие PHP-файлы и TPL-файлы могли бы быть в ANSI... А в базе, например, при инсталляции форума пользователем определено бы было, что форум работает в UTF и везде в заголовках передавалась бы переменная $GLOBALS['fm']->LANG['ENCODING'], которая по результатам инсталляции бы уже содержала в себе строку 'UTF-8' либо 'windows-1251'... Остается только создать для каждой кодировки свою папку с файлами локализации. Например, в папке language лежит папка russian, содержащая подпапки UTF-8 и windows-1251... И дописать условие для массива LANG - что берем локализацию по пути:
'language/russian/' . $GLOBALS['fm']->LANG['ENCODING'] . '/'
А приведенная выше строка кода выглядела бы так:
Может стоит подумать в этом направлении?...
Я обещал выложить дистрибутив в UTF. Пока просьбу не выполнил, так как в одном месте еще не победил - при написании или редактировании поста если какой-либо длинный русский текст заключить в ссылку, то кодировка этого текста в середине ломается, одна-две буквы выводятся в ?. Мелочь, но раздражает... Изыскания мои для правки данного бага пока не дали результата. Определил, что проблема возникает из-за либы JsHttpRequest в процессе передачи данных на сервер и возвращения полученного результата. На оффсайте этой библиотеки в форуме по поводу работы с кодировкий UTF-8 достаточно много постов. Автор либы, уважаемый и известный Дмитрий Котеров пишет, что это возможно из-за настроек сервера... Но проблема остается...
Может есть у кого-нибудь советы по поводу поблемы с JsHttpRequest?
Если уж собрались чистить код в сторону локализации, то не лишним будет мой опыт по переводу движка форума в кодировку UTF-8, а точнее те проблемы, с которыми пришлось столкнуться.
1. Поддерживаю упомянутый altjo вопрос о файле data/smiles.php - на его перевод было потрачено немало времени из-за того, что в нем кроме всего прочего форма хранения данных идет с учетом количества байтов... А, как известно, кодировка windows-1251 - однобайтная, UTF-8 - двухбайтная. Поэтому переводить пришлось через веб-интерфейс, редактируя русский текст сначала в латиницу на форуме в windows-1251, потом этот же файл кидать на форум в UTF-8 и обратно переводить в кирилицу... Если бы база смайлов хранилась в другой форме, без указания количества байтов, процесс бы вместо нескольких часов занял бы пару минут максимум...
2. В движке часто требуется урезание строк, например для вывода длинного заголовка топика на главной странице и т.п. В коде это делается с помощью php-функции substr, которая криво работает с UTF-8, поэтому эту функцию в тех местах, где производится урезание текста на русском пришлось заменять на аналогичную функцию mb_substr, для которой можно указать кодировку. Пример: строка 99 index.php
было:
Цитата:
$sub_lastpost = (strlen($allforums[$subid]['last_post']) > 16) ? substr($allforums[$subid]['last_post'], 0, 16).'...' : $allforums[$subid]['last_post'];
заменил на:
Цитата:
$sub_lastpost = (strlen($allforums[$subid]['last_post']) > 16) ? mb_substr($allforums[$subid]['last_post'], 0, 16,'UTF-8').'...' : $allforums[$subid]['last_post'];
красным цветом - изменения.
Попутно, если смотреть еще в сторону возможности выбора пользователем кодировки заново устанавливаемого форума, то в движке имеется переменная $GLOBALS['fm']->LANG['ENCODING'] доступная везде, в которой содержиться строка с кодировкой сайта: "windows-1251". Следовательно, если бы все вхождения русского текста находились в языковых файлах, то все исполняющие PHP-файлы и TPL-файлы могли бы быть в ANSI... А в базе, например, при инсталляции форума пользователем определено бы было, что форум работает в UTF и везде в заголовках передавалась бы переменная $GLOBALS['fm']->LANG['ENCODING'], которая по результатам инсталляции бы уже содержала в себе строку 'UTF-8' либо 'windows-1251'... Остается только создать для каждой кодировки свою папку с файлами локализации. Например, в папке language лежит папка russian, содержащая подпапки UTF-8 и windows-1251... И дописать условие для массива LANG - что берем локализацию по пути:
'language/russian/' . $GLOBALS['fm']->LANG['ENCODING'] . '/'
А приведенная выше строка кода выглядела бы так:
Цитата:
и корректно работала и в windows-1251 и в UTF-8...$sub_lastpost = (strlen($allforums[$subid]['last_post']) > 16) ? mb_substr($allforums[$subid]['last_post'], 0, 16,$GLOBALS['fm']->LANG['ENCODING']).'...' : $allforums[$subid]['last_post'];
Может стоит подумать в этом направлении?...
Я обещал выложить дистрибутив в UTF. Пока просьбу не выполнил, так как в одном месте еще не победил - при написании или редактировании поста если какой-либо длинный русский текст заключить в ссылку, то кодировка этого текста в середине ломается, одна-две буквы выводятся в ?. Мелочь, но раздражает... Изыскания мои для правки данного бага пока не дали результата. Определил, что проблема возникает из-за либы JsHttpRequest в процессе передачи данных на сервер и возвращения полученного результата. На оффсайте этой библиотеки в форуме по поводу работы с кодировкий UTF-8 достаточно много постов. Автор либы, уважаемый и известный Дмитрий Котеров пишет, что это возможно из-за настроек сервера... Но проблема остается...
Может есть у кого-нибудь советы по поводу поблемы с JsHttpRequest?
10. M-A-X - 21 сентября 2010 — 08:43 - перейти к сообщению
Добавлю.
UTF-8 - не двухбайтовая кодировка.
Для латиницы используется только один байт. Поэтому все хранить или в Юникоде или в АНСИ.
UTF-8 - не двухбайтовая кодировка.
Для латиницы используется только один байт. Поэтому все хранить или в Юникоде или в АНСИ.
11. igrok54 - 22 сентября 2010 — 09:13 - перейти к сообщению
M-A-X, да, конечно. Описка, извиняюсь... Многобайтная надо было сказать...
12. yura3d - 25 сентября 2010 — 05:16 - перейти к сообщению
igrok54
Вся проблема в том, что метод хранения данных этого форума не очень подходит для UTF-8. Использование этой кодировки приведёт к увеличению объёма хранимых данных в пересчёте на общее кол-во тем и сообщений, что в конечном итоге не лучшим образом скажется на производительности. Также не нужно забывать, что на сервере пользователя могут отсутствовать библиотеки для работы с UTF-8, такие как mb_string (например, на предыдущем сервере, где размещался наш проект, таковой не было). В этом случае необходимо предусмотреть наличие своих функций для работы с UTF-8. Делать UTF-версию, совмещённую с ANSI-версией (с возможностью выбора языка, и как следствие, кодировки) считаю, что нет необходимости. Смысла нет, поскольку UTF-8 уже содержит в себе широкий набор символов. В тоже время совместное использование 2-х типов кодировок (однобайтной и мультибайтной) будет связано с тем, что данные будут храниться в одной кодировке, а для работы с другими придётся применять ресурсоёмкую конвертацию. Более того, совместная работа с ANSI и UTF усложнит логику работы скрипта по части обработки строк, что не самым лучшим образом отразится на производительности. В дальнейшем мы планируем отказаться от ANSI и полностью перейти на UTF-8
Теперь по поводу смайлов, насколько я понял, Вы занимались ручным редактированием описаний ко всем смайлам. Не понимаю, зачем это было нужно, достаточно было написать простенький для конвертации описаний смайлов. Скрипт бы в цикле обошёл все смайлы и при помощи уже известной Вам функции PHP iconv() за раз сконвертировал в UTF-8 описания всех смайлов
Ну и насчёт проблемы с длинными ссылками, она никак не связана с JsHttpRequest. Объект XmlHttpRequst, обёрткой которого по сути является фронтенд этой библиотеки, как раз таки нативно поддерживает работу только с UTF-8. Соответственно, вся либа JsHttpRequest изначально затачивалась под UTF-8. Более того, форумом не задействуется Ajax на этапе создания и просмотра тем и сообщений. Проблема здесь в том, что для разделения слишком длинных слов используется функция PHP chunk_split(), которая не поддерживает UTF-8. Реализацию можно посмотреть в файле include/fm.class.php
Вся проблема в том, что метод хранения данных этого форума не очень подходит для UTF-8. Использование этой кодировки приведёт к увеличению объёма хранимых данных в пересчёте на общее кол-во тем и сообщений, что в конечном итоге не лучшим образом скажется на производительности. Также не нужно забывать, что на сервере пользователя могут отсутствовать библиотеки для работы с UTF-8, такие как mb_string (например, на предыдущем сервере, где размещался наш проект, таковой не было). В этом случае необходимо предусмотреть наличие своих функций для работы с UTF-8. Делать UTF-версию, совмещённую с ANSI-версией (с возможностью выбора языка, и как следствие, кодировки) считаю, что нет необходимости. Смысла нет, поскольку UTF-8 уже содержит в себе широкий набор символов. В тоже время совместное использование 2-х типов кодировок (однобайтной и мультибайтной) будет связано с тем, что данные будут храниться в одной кодировке, а для работы с другими придётся применять ресурсоёмкую конвертацию. Более того, совместная работа с ANSI и UTF усложнит логику работы скрипта по части обработки строк, что не самым лучшим образом отразится на производительности. В дальнейшем мы планируем отказаться от ANSI и полностью перейти на UTF-8
Теперь по поводу смайлов, насколько я понял, Вы занимались ручным редактированием описаний ко всем смайлам. Не понимаю, зачем это было нужно, достаточно было написать простенький для конвертации описаний смайлов. Скрипт бы в цикле обошёл все смайлы и при помощи уже известной Вам функции PHP iconv() за раз сконвертировал в UTF-8 описания всех смайлов
Ну и насчёт проблемы с длинными ссылками, она никак не связана с JsHttpRequest. Объект XmlHttpRequst, обёрткой которого по сути является фронтенд этой библиотеки, как раз таки нативно поддерживает работу только с UTF-8. Соответственно, вся либа JsHttpRequest изначально затачивалась под UTF-8. Более того, форумом не задействуется Ajax на этапе создания и просмотра тем и сообщений. Проблема здесь в том, что для разделения слишком длинных слов используется функция PHP chunk_split(), которая не поддерживает UTF-8. Реализацию можно посмотреть в файле include/fm.class.php
13. igrok54 - 25 сентября 2010 — 07:01 - перейти к сообщению
yura3d
По поводу возможности выбора юзером кодировки, в которой будет работать его форум - имелось в виду выбор кодировки в процессе инсталляции, но не впоследствии. Соответственно, и вся база бы была в назначенной кодировке. Переконвертации на лету бы не требовалось.
Ну да бог с ним - Вы разработчики, Вам решать...
За посыл в сторону функции chunk_split - большое спасибо, буду копать в этом направлении.
По поводу возможности выбора юзером кодировки, в которой будет работать его форум - имелось в виду выбор кодировки в процессе инсталляции, но не впоследствии. Соответственно, и вся база бы была в назначенной кодировке. Переконвертации на лету бы не требовалось.
Ну да бог с ним - Вы разработчики, Вам решать...
За посыл в сторону функции chunk_split - большое спасибо, буду копать в этом направлении.