| yura3d |
Отправлено: 24 августа 2009 — 19:11 
|
ExBB Team
ExBB Developer
ExBB Mods Author
Покинул форум
Сообщений всего: 3394
Дата рег-ции: Февр. 2009
Откуда: Минск, Беларусь
Репутация: 353
|
Давно собирался решить эту проблему. Заключается она в том, что изначально некоторые строковые переменные прописаны в скриптах форума, а не в языковых файлах, где им бы следовало быть. Соответственно, это усложняет локализацию форума и его работу одновременно с несколькими языками интерфейса. Некоторые строки, первоначально бывшие в скриптах, я уже вынес в языковые файлы (актуально для версии ExBB FM 1.0 RC2), но вполне возможно, что какие-то из них я мог пропустить. Поэтому даже если Вам кажется, что это уже обсуждалось, продублируйте информацию в этой теме
Данный вопрос касается не только строковых переменных, но и регулярных выражений в скриптах форума. Надеюсь, с Вашей помощью удастся реализовать полную локализуемость для ExBB FM 1.0 RC2 без необходимости правки скриптов |
| |
|
| M-A-X |
Отправлено: 24 августа 2009 — 21:11
|
Advanced Member
Покинул форум
Сообщений всего: 278
Дата рег-ции: Июль 2009
Откуда: Киев
Репутация: 10
|
fm.class.php 176 строка и ниже выводит месяцы только на русском
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;
}
Примерно 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\" По ходу ни на что не влияет (Отредактировано автором: 24 августа 2009 — 22:18) |
| |
|
| altjo |
Отправлено: 14 октября 2009 — 16:25
|
ExBB Skins Creator
Покинул форум
Сообщений всего: 277
Дата рег-ции: Февр. 2009
Репутация: 86
|
надеюсь по теме )
в файле 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>
не знаю исправлено это или нет, но
CODE:{$fm->LANG['SortBy']} нужно вынести сразу после
т.к. "Сортировать по" должно быть справа, а не слева
http://exbb.info/community/tools...p?action=members |
| |
|
| igrok54 |
Отправлено: 19 сентября 2010 — 12:59
|
Advanced Member
Покинул форум
Сообщений всего: 470
Дата рег-ции: Янв. 2010
Откуда: Пермь
Репутация: 57
|
Просьба по данной теме.
Если уж собрались чистить код в сторону локализации, то не лишним будет мой опыт по переводу движка форума в кодировку 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'] . '/'
А приведенная выше строка кода выглядела бы так:
Цитата:$sub_lastpost = (strlen($allforums[$subid]['last_post']) > 16) ? mb_substr($allforums[$subid]['last_post'], 0, 16,$GLOBALS['fm']->LANG['ENCODING']).'...' : $allforums[$subid]['last_post']; и корректно работала и в windows-1251 и в UTF-8...
Может стоит подумать в этом направлении?...
Я обещал выложить дистрибутив в UTF. Пока просьбу не выполнил, так как в одном месте еще не победил - при написании или редактировании поста если какой-либо длинный русский текст заключить в ссылку, то кодировка этого текста в середине ломается, одна-две буквы выводятся в ?. Мелочь, но раздражает... Изыскания мои для правки данного бага пока не дали результата. Определил, что проблема возникает из-за либы JsHttpRequest в процессе передачи данных на сервер и возвращения полученного результата. На оффсайте этой библиотеки в форуме по поводу работы с кодировкий UTF-8 достаточно много постов. Автор либы, уважаемый и известный Дмитрий Котеров пишет, что это возможно из-за настроек сервера... Но проблема остается...
Может есть у кого-нибудь советы по поводу поблемы с JsHttpRequest?(Отредактировано автором: 19 сентября 2010 — 13:03) |
| |
|
| yura3d |
Отправлено: 25 сентября 2010 — 05:16
|
ExBB Team
ExBB Developer
ExBB Mods Author
Покинул форум
Сообщений всего: 3394
Дата рег-ции: Февр. 2009
Откуда: Минск, Беларусь
Репутация: 353
|
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 |
| |
|
|
Сайт проекта ExBB
Чат на форуме
Помощь
Поиск
BanList
Описание: Если нашли, выкладывайте здесь
