Пользователь:
Visitor
Дата: 30-марта-2006 9:56 pm
Просмотров: 8010
Оценка: -3
Оценить [ | ]
Как я понял - речь идёт о версии 6.7.* или 6.8.* (поправьте меня, если я не прав...)
===
да.
===
Если появился новый макрос у которого нет перевода, то при выборе его мышью в левом фрейме редактора, создаётся сначала пустой файл перевода для этого макроса (должны быть даны права на запись веб-пользователю в этой папке)
===
я как-то думал, оно должно быть типа репогзитария в каком-то одном месте. Думал что здесь. :)
===
В старых версиях (от JT) обрезались длинные фразы из за того, что результаты формы передавались методом GET, а не POST.
===
а кто такое JT?
===
Проблемы с кириллицей в Юникоде могут быть с регулярными выражениями.
===
ну это просто отдельная песня, я пока за substr() болею.
===
##<-- start transliteration -->##
====
кстати, был поражён тем, насколько на CPAN всё плохо с транслитерацией кириллицы... единственное похожее --- Lingua::RU::Translit, да и тот оставляет желать.
===
Попробуйте для пробы заменить substr() на что-то другое...
===
так это вроде не режекс, а libc, оно вроде должно уметь substr() с локалью.
===
Есть ещё один "дурацкий" способ: переводить с помощью Text::Iconv в utf8, обрабатывать, а затем возвращать с помощью Text::Iconv опять в Юникод Cool.
===
несколько чересчур круто держать свой порт HTML::Template::Expr с такой доработкой :)
===
По поводу mysql-4.0 - У меня около года работало WG на 4.0 (собран с кодировкой по-умолчанию utf8). Сортировало правильно, но SELECT LIKE "%Слово%" работало, как регистрозависимое.
===
тото и оно --- поиск надо бы.
===
Если собрать MySQL с кодировкой по-умолчанию koi8-r, то сортировать будет неправильно.
===
редко кто из хостеров сейчас не позволяет на каждую таблицу отдельно выставлять collation utf8, однако
===
Этой осенью перешёл на 4.1 и, затем почти сразу на 5.0. (в соответствии с новыми требованиями WebGUI),
===
а зачем это они 5 требуют?
===
но у MySQL 5.0 с кириллицей в Юникоде проблемы. Он не корректно отображает около 3 или 4 кириллических букв (какие именно - зависит от того, с какой кодировкой собран по-умолчанию utf8 или koi8-r). Подобное наблюдалось в ранних версиях 4.1. Поэтому пришлось перевести WebGUI базы данных на utf8, при том, что содержимое хранится в Юникоде. Вобщем сейчас работает аналогично тому, как я описал работу с 4.0.
