Как я понял - речь идёт о версии 6.7.*  или 6.8.* (поправьте меня, если я не прав...)

Если появился новый макрос у которого нет перевода, то при выборе его мы

Как я понял - речь идёт о версии 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.

Если появился новый макрос у которого нет перевода, то при выборе его мышью в левом фрейме редактора, создаётся сначала пустой файл перевода для этого макроса (должны быть даны права на запись веб-пользователю в этой папке)
===
я как-то думал, оно должно быть типа репогзитария в каком-то одном месте. Думал что здесь. :)
======

Так оно и есть в одном месте: Папка WebGUI/lib/WebGUI/i18n/Russian, в которой лежат все переводы на русский язык.

===
а кто такое JT?
=======

JT Smith - главный идеолог, автор и разработчик WebGUI

===
а зачем это они 5 требуют?
===
Начиная с версии 6.8.* требуется MySQL 5.0 & Apache 2.0 + mod_perl 2.0 (http://www.plainblack.com/downloads/builds/6.8.4-gamma/WebGUI/docs/gotcha.txt).

---

Пожалуйста, все вопросы и пожелания оставляйте на форуме, а не направляйте прямиком мне на E-mail

Так оно и есть в одном месте: Папка WebGUI/lib/WebGUI/i18n/Russian, в которой лежат все переводы на русский язык.
--- можненько ссылочку на этом сайтике?

Начиная с версии 6.8.*
--- мне кажется, им форкануться надо, всё-таки suexec для нескольких вебгуёв фича не лишняя. Как интересно на шаренном мод_пёрл-хостинге решается проблема непросмотра mysql-пароля соседа в WebGUI.conf?