https://www.opennet.dev/openforum/vsluhforumID3/90318.html Доступна новая версия myl10n 1.2 (http://myl10n.ru/), web-интерфейса для организации совместной работы над локализацией приложений, в том числе для управления локализацией одновременно нескольких проектов. Система поддерживает гибкие средства разграничения полномочий пользователей, вплоть до доступа к заданному набору переменных локализации. Проект написан на языке Python с использованием фреймворка Django, в качестве СУБД поддерживается PostgreSQL и MySQL. Код распространяется под лицензией BSD-2-Clause.<br><br><br>В новом выпуске:<br><br><br>- Функция копирования и перемещения выделенных разделов/кодов в другие разделы;<br>- Функция удаления разделов/кодов списком;<br>- Функция очистки лога локализации на предмет удаленных элементов;<br>- Функция сохранения языковых настроек как для пользователя так и для проекта в целом;<br>- Возможность апгрейда базы до новой версии без потери данных;<br>- Исправлены ошибки верстки в разделе parts<br>- Исправлены общие ошибки локализации и произведены мелкие исправлений<br><br><br><br><br>URL: http:// https://www.opennet.dev/openforum/vsluhforumID3/90318.html#30 Wed, 05 Jun 2013 12:47:17 GMT &gt;&gt; А расскажите еще что-нибудь интересное?:) <br>&gt; В начале было слово...<br>&gt; http://hg.51t.ru/nz/ <br>&gt; безбазное :) <br><br>Кстати, раньше оно было на sqlite3, и по сравнению с ним, скорость возросла в 5 раз на поиск и в 30-60 раз на генерацию странички.<br> https://www.opennet.dev/openforum/vsluhforumID3/90318.html#29 Wed, 05 Jun 2013 12:44:48 GMT &gt; Ну, для большей совместимости да..<br>&gt; Но при работе в крупных проектах я заметил что народ обычно завязывается <br>&gt; на конкретную базу, и под нее затачивает какие-то тонкости, несовместимые с <br>&gt; другими БД, но при этом сильно ускоряющие обработку данных / что-нибудь еще.<br><br>Такие вещи лучше выносить отдельно, в какой-нибудь модуль. При этом для приложения всё должно быть прозрачно, только при опредёлённых условиях оно будет быстрее.<br><br>&gt; Здесь конечно ускорять пока нечего, но мало ли что в будущем будет:) <br><br>Такими темпами может и не быть будущего.<br> <br>&gt; Здесь используются две самые популярные базы - постгрес и msql..<br><br>У меня ни на компьютере, ни на сервере таких баз нет.<br><br>&gt; Да, логично сделать sqlite3, что бы поднималось из коробки..<br>&gt; Но это ведь не фреймворк, это законченный продукт, адаптированный под конкретные ресурсы и цели.<br><br>Оно не будет использоваться, если не станет мейнстримом. Сначала им должны поиграться, быстро запустить, быстро заценить, и потом уже вставлять куда-то. Сложность должна воз https://www.opennet.dev/openforum/vsluhforumID3/90318.html#28 Wed, 05 Jun 2013 12:26:34 GMT &gt; А расскажите еще что-нибудь интересное?:)<br><br>В начале было слово...<br><br>http://hg.51t.ru/nz/<br><br>безбазное :)<br> https://www.opennet.dev/openforum/vsluhforumID3/90318.html#27 Wed, 05 Jun 2013 11:50:31 GMT Вот зачем полезно новости публиковать:-) сразу становится понятно куда поект двигать!:-)<br><br>Спасибо за комментарии!<br> https://www.opennet.dev/openforum/vsluhforumID3/90318.html#26 Wed, 05 Jun 2013 11:29:24 GMT &gt;&gt; Про воспользоваться на месте вы абсолютно правы, но реализация этой возможности указана <br>&gt;&gt; в todo, что радует..<br>&gt;&gt; Про плоский sql ясно, согласен на все сто.. Но вы же здесь <br>&gt;&gt; первый раз это не просто так упомянули..<br>&gt; Я только сказал, что если проект прибит только к mysql и postgresql <br>&gt; (хотя у django есть слой абстракции "из коробки"), то потом он <br>&gt; и будет жить с этими двумя базами, и переписывать умучаешься.<br>&gt; Точнее, я сказал несколько короче "это чё, пыхеры?" <br><br>Ну, для большей совместимости да.. <br>Но при работе в крупных проектах я заметил что народ обычно завязывается на конкретную базу, и под нее затачивает какие-то тонкости, несовместимые с другими БД, но при этом сильно ускоряющие обработку данных / что-нибудь еще. <br>Здесь конечно ускорять пока нечего, но мало ли что в будущем будет:)<br><br>Здесь используются две самые популярные базы - постгрес и msql.. <br>Да, логично сделать sqlite3, что бы поднималось из коробки..<br>Но это ведь не фреймворк, это законченный продукт, адаптированный под https://www.opennet.dev/openforum/vsluhforumID3/90318.html#25 Wed, 05 Jun 2013 11:21:08 GMT &gt; В смысле, для сессий приложение одно, но настроек дофига, и его возможностей <br>&gt; для хранения сессий в memcache хватает.<br>&gt; https://docs.djangoproject.com/en/dev/topics/http/sessions/#configuring-the-session-engine <br><br>Супер! Спасибо! <br>Отписал и они уже сделали тикет. <br><br>А расскажите еще что-нибудь интересное?:)<br> https://www.opennet.dev/openforum/vsluhforumID3/90318.html#24 Wed, 05 Jun 2013 11:19:52 GMT &gt; Про воспользоваться на месте вы абсолютно правы, но реализация этой возможности указана <br>&gt; в todo, что радует..<br>&gt; Про плоский sql ясно, согласен на все сто.. Но вы же здесь <br>&gt; первый раз это не просто так упомянули..<br><br>Я только сказал, что если проект прибит только к mysql и postgresql (хотя у django есть слой абстракции "из коробки"), то потом он и будет жить с этими двумя базами, и переписывать умучаешься.<br><br>Точнее, я сказал несколько короче "это чё, пыхеры?"<br> https://www.opennet.dev/openforum/vsluhforumID3/90318.html#23 Wed, 05 Jun 2013 11:12:36 GMT В смысле, для сессий приложение одно, но настроек дофига, и его возможностей для хранения сессий в memcache хватает.<br>https://docs.djangoproject.com/en/dev/topics/http/sessions/#configuring-the-session-engine<br> https://www.opennet.dev/openforum/vsluhforumID3/90318.html#22 Wed, 05 Jun 2013 10:51:15 GMT Про воспользоваться на месте вы абсолютно правы, но реализация этой возможности указана в todo, что радует.. <br><br>Про плоский sql ясно, согласен на все сто.. Но вы же здесь первый раз это не просто так упомянули.. <br><br>В данном конкретном проекте, где конкретно скули на ваш взгляд надо поменять на "не плоское" хранение данных? <br><br>Вообще, сейчас популярно использование той же кассандры; Но тогда стоит в корне менять подход, и всё на noSQL и делать.. разве нет? <br><br>А если мешать sql и nosql это еще больше нагрузит проект переплетением технологий.. Где та золотая середина?<br>