А рабочим примером не поделитесь? Хотелось бы посмотреть на реализацию редактирования через админку простым пользователем — просто когда у меня возникает вопрос «что же использовать?» я вспоминаю про проблемы *.mo файлов
> формат открытый, есть даже реализации
Пока нашел только File_Gettext, последний релиз 2007 год…
The GNU gettext library works on a per-process, not per-thread basis. This means that in a multi-user setting such as the Apache web server it will only work with a prefork MPM (i.e. one process per user). Worker and other threaded MPMs will not work.
In addition, many users control GNU gettext by setting system environment variables such as LANG. This is not a good solution for a web server environment due to an obvious race condition.
Редактировать то можно, а вот как Вы будете создавать *.mo файлы на сервере пользователя?
Пример — CMS (форум, блог, и тд. и тп.) в которой пользователи могут сами изменять перевод, в этом случае PHP файлы будут удобнее и проще, чем объяснять простым пользователям, что делать с *.po файлами.
Жалко. Для обычных пользователей это еще может быть полезно (но они все равно не знают ни HTML ни синтаксис шаблонов), а вот для разработчиков — только мешает (не верю что кому может быть удобно редактировать шаблоны без подсветки синтаксиса, в неудобной textarea, без нормального поиска и т.д. и т.п.).
Оптимальный вариант — возможность редактирования и там и там. Надеюсь когда нибудь это появится…
У IPB сейчас тоже не все гладко. Просто форум им не конкурент пока, но в будущем очень вероятно (правда только в том случае, если код у XenForo будет лучше).
2) Настройки темы — интересно сделано, но усложнит создание собственных стилей; с другой стороны — в некоторых случаях позволит обойтись стандартной темой…
3) Те куски кода которые можно заметить — радуют.
4) добрался до плагинов, не понравилось:
* Все через админку[1]
* build id вручную… зачем?! неужели так сложно автоматизировать это?[1]
* Длинные_Названия_Классов — почему не использовать пространства имен? (код устарел до релиза)
* У event-ов похоже нет интерфейсов — придется постоянно лазить в админку чтобы посмотреть что он принимает.
[1] — По опыту работы с IPB — очень надоедает постоянно переключаться между редактором и браузером и искать на нужных страницах нужные кнопки (это отнимает время и отвлекает внимание). Очень надеюсь что со временем это будет автоматизировано.
С нуля всегда проще начать, чем исправлять существующее… но вообще я буду очень рад если XenForo:
* или позволит отказаться от IPB;
* или заставит IPB улучшить качество собственного кода и более серьезно относится к тестированию.
Чтобы конкурировать им придется увеличить скорость разработки, а это приведет к ухудшению кода и появлению ошибок, что еще больше снизит скорость… Более того, из-за малого количества разработчиков (всего двое?) начало реализации любого доп компонента полностью оставит развитие самого ядра/форума (нечто подобное сейчас происходит с IPB и IP.Nexus)
Redmine лучше ставить из репозитория (svn co) т.к. это сильно облегчит обновления, особенно если будут изменяться шаблоны.
Каких либо проблем с русским языком и mysql мною замечено не было (американский шаред хостинг). Зато была замечена забавная бага с временем коммита для svn — если установить для руби (в конфиге Redmine) нужный часовой пояс (+3), то при установке другого часового пояса в post_commit хуке для svn (тоже +3) — время всех ревизий будет в будущем (+6)…
> А для магазина неужели нет ничего удобнее?
Есть, но одно дело что-то стороннее требующее написания интеграции, и совсем другое — родной магазин (IP.Nexus). Сказать о нем что-либо не могу, т.к. он еще не вышел, но вообще меня, как разработчика модификаций для IPB, не очень радует выбранное IPS направление развития. Подождем что будет дальше — тем более новый конкурент появился.
> В контексте «форум для форума» можно отправлять.
> А не для просмотра дней рождений участников, собственного IP адреса, времени когда я заходил последний раз и статистики по сообщениям в сотне разрезах.
Спорно. Тем более никто не мешает создать собственный стиль без ненужной информации.
У IPB, кстати, система шаблонов очень простая и довольно удобная (как для пользователей так и для разработчиков), очень интересно как с этим обстоят дела у XenForo.
* www.gnu.org/software/gettext/manual/gettext.html#Plural-forms
* www.gnu.org/software/gettext/manual/gettext.html#Translating-plural-forms
А рабочим примером не поделитесь? Хотелось бы посмотреть на реализацию редактирования через админку простым пользователем — просто когда у меня возникает вопрос «что же использовать?» я вспоминаю про проблемы *.mo файлов
> формат открытый, есть даже реализации
Пока нашел только File_Gettext, последний релиз 2007 год…
И, кроме этого, в мануале можно найти:
Учитывая это, свой велосипед уже не кажется таким плохим. Числительные при желании тоже можно реализовать наподобие того, как это сделано в gettext-е.
ни к чему не призываю, это просто мои соображения
Пример — CMS (форум, блог, и тд. и тп.) в которой пользователи могут сами изменять перевод, в этом случае PHP файлы будут удобнее и проще, чем объяснять простым пользователям, что делать с *.po файлами.
Оптимальный вариант — возможность редактирования и там и там. Надеюсь когда нибудь это появится…
— На младшем тарифе (Shared 1) RoR можно запустить всего в 1 поток (80MB дают о себе знать)
В остальном замечаний нет.
1) только MySQL?
2) Настройки темы — интересно сделано, но усложнит создание собственных стилей; с другой стороны — в некоторых случаях позволит обойтись стандартной темой…
3) Те куски кода которые можно заметить — радуют.
4) добрался до плагинов, не понравилось:
* Все через админку[1]
* build id вручную… зачем?! неужели так сложно автоматизировать это?[1]
* Длинные_Названия_Классов — почему не использовать пространства имен? (код устарел до релиза)
* У event-ов похоже нет интерфейсов — придется постоянно лазить в админку чтобы посмотреть что он принимает.
[1] — По опыту работы с IPB — очень надоедает постоянно переключаться между редактором и браузером и искать на нужных страницах нужные кнопки (это отнимает время и отвлекает внимание). Очень надеюсь что со временем это будет автоматизировано.
* или позволит отказаться от IPB;
* или заставит IPB улучшить качество собственного кода и более серьезно относится к тестированию.
> Четкий и красивый API для модулей расширения.
У IPB неплохо сделано, если не брать во внимание огромное кол-во ошибок.
Спасибо за ссылку — ушел смотреть.
Какие и чем он превосходит?
(мне это действительно интересно, особенно сравнение с IPB)
Каких либо проблем с русским языком и mysql мною замечено не было (американский шаред хостинг). Зато была замечена забавная бага с временем коммита для svn — если установить для руби (в конфиге Redmine) нужный часовой пояс (+3), то при установке другого часового пояса в post_commit хуке для svn (тоже +3) — время всех ревизий будет в будущем (+6)…
p.yusukekamiyamane.com/icons/attribution/
Это по-моему ключевая фраза, но почему-то в большинстве случаев авторы не указывают как и где размещать эту ссылку :(
Кстати, можно и не указывать ссылку после покупки набора — цена совсем небольшая, по-моему.
Есть, но одно дело что-то стороннее требующее написания интеграции, и совсем другое — родной магазин (IP.Nexus). Сказать о нем что-либо не могу, т.к. он еще не вышел, но вообще меня, как разработчика модификаций для IPB, не очень радует выбранное IPS направление развития. Подождем что будет дальше — тем более новый конкурент появился.
> В контексте «форум для форума» можно отправлять.
> А не для просмотра дней рождений участников, собственного IP адреса, времени когда я заходил последний раз и статистики по сообщениям в сотне разрезах.
Спорно. Тем более никто не мешает создать собственный стиль без ненужной информации.
У IPB, кстати, система шаблонов очень простая и довольно удобная (как для пользователей так и для разработчиков), очень интересно как с этим обстоят дела у XenForo.
P.S. Смайлы у него жесть…
IPB это не только форум — еще 10 различных приложений… даже магазин есть…