ExBB Community » » Обсуждение » Языковые строки в скриптах

Страниц (1): [1]
 

1. yura3d - 24 августа 2009 — 19:11 - перейти к сообщению
Давно собирался решить эту проблему. Заключается она в том, что изначально некоторые строковые переменные прописаны в скриптах форума, а не в языковых файлах, где им бы следовало быть. Соответственно, это усложняет локализацию форума и его работу одновременно с несколькими языками интерфейса. Некоторые строки, первоначально бывшие в скриптах, я уже вынес в языковые файлы (актуально для версии ExBB FM 1.0 RC2), но вполне возможно, что какие-то из них я мог пропустить. Поэтому даже если Вам кажется, что это уже обсуждалось, продублируйте информацию в этой теме

Данный вопрос касается не только строковых переменных, но и регулярных выражений в скриптах форума. Надеюсь, с Вашей помощью удастся реализовать полную локализуемость для ExBB FM 1.0 RC2 без необходимости правки скриптов
2. M-A-X - 24 августа 2009 — 19:18 - перейти к сообщению
Если не в тему, то удалите Улыбка
Тему нельзя начать на украинскую букву "І"
примерно 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 строка и ниже выводит месяцы только на русском
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\"
По ходу ни на что не влияет Улыбка
5. altjo - 14 октября 2009 — 16:25 - перейти к сообщению
надеюсь по теме )

в файле 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>&nbsp;


не знаю исправлено это или нет, но
CODE:
{$fm->LANG['SortBy']}
нужно вынести сразу после &nbsp;
т.к. "Сортировать по" должно быть справа, а не слева
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
В форуме:
Последние сообщения на форуме
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
было:
Цитата:
$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?
10. M-A-X - 21 сентября 2010 — 08:43 - перейти к сообщению
Добавлю.
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
13. igrok54 - 25 сентября 2010 — 07:01 - перейти к сообщению
yura3d
По поводу возможности выбора юзером кодировки, в которой будет работать его форум - имелось в виду выбор кодировки в процессе инсталляции, но не впоследствии. Соответственно, и вся база бы была в назначенной кодировке. Переконвертации на лету бы не требовалось.
Ну да бог с ним - Вы разработчики, Вам решать...

За посыл в сторону функции chunk_split - большое спасибо, буду копать в этом направлении.

Яндекс.Метрика   

Powered by ExBB
[Script Execution time: 0.0513]     [ ]