Доступна новая версия myl10n 1.2 (http://myl10n.ru/), web-интерфейса для организации совместной работы над локализацией приложений, в том числе для управления локализацией одновременно нескольких проектов. Система поддерживает гибкие средства разграничения полномочий пользователей, вплоть до доступа к заданному набору переменных локализации. Проект написан на языке Python с использованием фреймворка Django, в качестве СУБД поддерживается PostgreSQL и MySQL. Код распространяется под лицензией BSD-2-Clause.
В новом выпуске:
- Функция копирования и перемещения выделенных разделов/кодов в другие разделы;
- Функция удаления разделов/кодов списком;
- Функция очистки лога локализации на предмет удаленных элементов;
- Функция сохранения языковых настроек как для пользователя так и для проекта в целом;
- Возможность апгрейда базы до новой версии без потери данных;
- Исправлены ошибки верстки в разделе parts
- Исправлены общие ошибки локализации и произведены мелкие исправлений
URL: http://myl10n.ru/
Новость: http://www.opennet.me/opennews/art.shtml?num=37093
на nginx+uwsgi работает ?
Да, нет проблем
А есть ли сайт/документация на английском или хотя бы испанском? :)
Веб-морда тоже только на русском.
Или аналогичный/альтернативный проект с документацией не только на русском.
Просто не понятно как же локализаторам этим пользоваться переводя переменные на свои языки, ведь не весь мир на русском умеет читать.
> А есть ли сайт/документация на английском или хотя бы испанском? :)
> Веб-морда тоже только на русском.
> Или аналогичный/альтернативный проект с документацией не только на русском.
> Просто не понятно как же локализаторам этим пользоваться переводя переменные на свои
> языки, ведь не весь мир на русском умеет читать.Есть еще такие публичные сервисы, как :
Transifex, crowdinНо по мне, так когда все переменные в куче лежат это не удобно. И поиск фиговый.
Зато там есть много такого, что можно перенять:-)
Те проекты, насколько я понимаю, отталкиваютя от изначального файла локализации..
А в этом предлогается структуру переменных развести красиво, по разделам, а потом автоматом собирать файлы локализации клиентом, из данных, которые сервер поставляет в json;
Клиенты простенькие там тоже имеются...Но это, скорее проект для установки и использования внутре компании, нежели публично.. Пока во всяком случае.
К 1.4 версии ожидается совсем уже продакшен, а это август - сентябрь.. Посмотрим что из этого получится:-)
> К 1.4 версии ожидается совсем уже продакшен, а это август - сентябрь..
> Посмотрим что из этого получится:-)Да, там в TODO всё это написано:)
Собственно для английского заделанн был одноименный домен в .org
интерфейс морды по умолчанию на английском.Документацию на английском обещали к июлю
А чё не на пыхе?
а нафига?:)
http://myl10n.ru/install/без комментариев
> http://myl10n.ru/install/
> без комментариевМожет я недалекий, .. но я не понял к чему вы это..
Поясните пожалуйста.
Вместо простой и ясной установки django-проекта там какой-то долбаный квест. Ещё и apache с memcached гвоздями приколочены.
> Вместо простой и ясной установки django-проекта там какой-то долбаный квест. Ещё и
> apache с memcached гвоздями приколочены.Вместо простой и ясной установки django-проекта там типичная установка php-проекта. :)
Кстати, с sqlite3 оно не работает? Я могу просто запустить "как есть"?
>> Вместо простой и ясной установки django-проекта там какой-то долбаный квест. Ещё и
>> apache с memcached гвоздями приколочены.
> Вместо простой и ясной установки django-проекта там типичная установка php-проекта. :)
> Кстати, с sqlite3 оно не работает? Я могу просто запустить "как есть"?sqlight3 наверное будет в 1.3:)
memcached не гвоздями, а вполне адекватно.
Он использован там для того, что бы уменьшить нагрузку на бд, уменьшив количество запросов.Насколько я смотрел и понял - он обрабатывает сессии пользователей и сессии капчи, что вполне логично.
Про типичную установку php - ты имеешь ввиду sqlinstall? или вообще общий принцип установки?
Там в TODO указано что в 1.3 всё это будет сильно упрощено.
> Про типичную установку php - ты имеешь ввиду sqlinstall? или вообще общий принцип установки?Я не увидел ни слова ни про virtualenv, ни про pip/easy_install, ни про manage.py runserver
> sqlight3 наверное будет в 1.3:)
в смысле, реальные пацаны orm не используют? про возможность работы с той же mongo вообще молчу.
> Он использован там для того, что бы уменьшить нагрузку на бд, уменьшив количество запросов.
плоские таблицы (sql) там, где они неуместны - это всегда проблема.
> Насколько я смотрел и понял - он обрабатывает сессии пользователей и сессии капчи, что вполне логично.
А для этого обязательно демон, да ещё и memcached? Да, конечно, с каким-нибуь gunicorn глобалы не покрутишь, но что-нибудь попроще нельзя было сделать?
Кстати, у меня вопрос ко всем - с gunicorn глобалы не покрутишь?
Короче, пых - это ваше всё. Не нужно на django делать так, как на пыхе, очень вас прошу.
Спасиб за ответ:)> Я не увидел ни слова ни про virtualenv, ни про pip/easy_install, ни
> про manage.py runserver- там же в туду написано, что будет 1.3
>> sqlight3 наверное будет в 1.3:)
> в смысле, реальные пацаны orm не используют? про возможность работы с той
> же mongo вообще молчу.- неясно причем здесь sqlight3.
SQLite поддерживает обработку одного запроса в момент времени. При большом количестве каждый запрос будет блокировать весь файл и могут "тормозить" запросы.
Я думаю, что равно как и встроенный сервер, он в этом проекте нужен только для того что бы позволить проекту работать "из коробки". Это будет в 1.3, без свистоплясок с зависимостями и конфигурированием.
Сам проект, по мимо установщика, использует ORM.
Почему они не сделали установщик табличек через syncdb - для меня действительно остается загадкой.. Возможно вывод sqlall их не утроил чем-то.. Может хронимки сделать хотели, хотя я этого там не увидел.С другой стороны новый скрипт миграции со старой версии базы на новую это объясняет;
Другой вариант.. ну только если моделей под старые версии по наделать, и сними проверять корректность схемы?
> плоские таблицы (sql) там, где они неуместны - это всегда проблема.- приведите пожалуйста пример:) ну, хотя бы на примере этого проекта.. Где и почему как вам кажется? Это интересно!
>> Насколько я смотрел и понял - он обрабатывает сессии пользователей и сессии капчи, что вполне логично.
> А для этого обязательно демон, да ещё и memcached? Да, конечно, с
> каким-нибуь gunicorn глобалы не покрутишь, но что-нибудь попроще нельзя было сделать?- memcached можно настроить на распределенную работу, тем самым сбалансировать нагрузку.
Для этого же в схеме используется подход работы с базой как master/slave, - проект расчитан как высоконагруженный.
А что плохого в том, что бы сессии отсылать стороннему сервису, возможно на другой сервер?
> - приведите пожалуйста пример:) ну, хотя бы на примере этого проекта..
> Где и почему как вам кажется? Это интересно!1. Поиск по тэгам
db = [{ "name": "myitem",
"text": "tra la la",
"tags": [ "python", "php", "fight" ] },
... ]выборка всех объектов:
[i for i in db if 'php' in i.tag]
либо
db = [{ "name": "myitem",
"text": "tra la la",
"tags": "python,php,fight" ] },
... ][i for i in db if 'php' in i.tag.split(',')]
в sql - отдельная таблица, хранящая id-шники, связи, получение объектов - короче, много лишнего, придание объема плоскому.
2. добавление полей.db['myitem']['balance'] = 500
[i for i in db if 'balance' in i and i.balance > 0]
в sql - изменение всей дб на каждый чих
3. вложенностьdb['myitem']['comments'] = [mydict(name='Vasya',comment='Жжош',pubdate='1 мартобря'),mydict(name='Petya',comment='Жжу. А что делать?',pubdate='2 мартобря')
в sql - создание ИЛИ новых полей, ИЛИ новой таблицы, ассоциации. На 57-й таблице уже можно запутаться, кто кого харлал, получается или 57 таблиц с 2-3 полями, или 120 полей в самой базе, даже если они не нужны. на хранении примерно одинаковых объектов можно вообще запутаться, что делать. Постоянный поиск компромиссов, вместо того, чтобы просто писать, просто навешивать объекты, и когда уже всё готово, думать об оптимизации и о переезде некоторых данных, сохраняя работоспособность. А не решать все проблемы тогда, когда ещё ничего не готово.
sql - это плоские данные с устоявшейся схемой. для всего остального существует бессхемная реализация.
> - memcached можно настроить на распределенную работу, тем самым сбалансировать
> нагрузку.
> Для этого же в схеме используется подход работы с базой как master/slave,
> - проект расчитан как высоконагруженный.
> А что плохого в том, что бы сессии отсылать стороннему сервису, возможно
> на другой сервер?90% пользователей и 100% тех, кто хочет ознакомиться, попробуют сначала runserver. И для нагрузки 100 запросов в сутки хватит и его возможностей, при запуске где-нибудь в tmux, через proxy_pass (этап подготовки займёт минуты три), и эта работа будет их устраивать. Оно не попадёт в суровый энтерпрайз на миллионные нагрузки и не сформирует сообщество, если им нельзя будет просто взять и воспользоваться, "на-месте".
Про воспользоваться на месте вы абсолютно правы, но реализация этой возможности указана в todo, что радует..Про плоский sql ясно, согласен на все сто.. Но вы же здесь первый раз это не просто так упомянули..
В данном конкретном проекте, где конкретно скули на ваш взгляд надо поменять на "не плоское" хранение данных?
Вообще, сейчас популярно использование той же кассандры; Но тогда стоит в корне менять подход, и всё на noSQL и делать.. разве нет?
А если мешать sql и nosql это еще больше нагрузит проект переплетением технологий.. Где та золотая середина?
> Про воспользоваться на месте вы абсолютно правы, но реализация этой возможности указана
> в todo, что радует..
> Про плоский sql ясно, согласен на все сто.. Но вы же здесь
> первый раз это не просто так упомянули..Я только сказал, что если проект прибит только к mysql и postgresql (хотя у django есть слой абстракции "из коробки"), то потом он и будет жить с этими двумя базами, и переписывать умучаешься.
Точнее, я сказал несколько короче "это чё, пыхеры?"
>> Про воспользоваться на месте вы абсолютно правы, но реализация этой возможности указана
>> в todo, что радует..
>> Про плоский sql ясно, согласен на все сто.. Но вы же здесь
>> первый раз это не просто так упомянули..
> Я только сказал, что если проект прибит только к mysql и postgresql
> (хотя у django есть слой абстракции "из коробки"), то потом он
> и будет жить с этими двумя базами, и переписывать умучаешься.
> Точнее, я сказал несколько короче "это чё, пыхеры?"Ну, для большей совместимости да..
Но при работе в крупных проектах я заметил что народ обычно завязывается на конкретную базу, и под нее затачивает какие-то тонкости, несовместимые с другими БД, но при этом сильно ускоряющие обработку данных / что-нибудь еще.
Здесь конечно ускорять пока нечего, но мало ли что в будущем будет:)Здесь используются две самые популярные базы - постгрес и msql..
Да, логично сделать sqlite3, что бы поднималось из коробки..
Но это ведь не фреймворк, это законченный продукт, адаптированный под конкретные ресурсы и цели.
Ну а если так хочется другую базу - нет проблем, подправьте settings.py и будет вам счастье..В чем я ошибаюсь?
> Ну, для большей совместимости да..
> Но при работе в крупных проектах я заметил что народ обычно завязывается
> на конкретную базу, и под нее затачивает какие-то тонкости, несовместимые с
> другими БД, но при этом сильно ускоряющие обработку данных / что-нибудь еще.Такие вещи лучше выносить отдельно, в какой-нибудь модуль. При этом для приложения всё должно быть прозрачно, только при опредёлённых условиях оно будет быстрее.
> Здесь конечно ускорять пока нечего, но мало ли что в будущем будет:)
Такими темпами может и не быть будущего.
> Здесь используются две самые популярные базы - постгрес и msql..У меня ни на компьютере, ни на сервере таких баз нет.
> Да, логично сделать sqlite3, что бы поднималось из коробки..
> Но это ведь не фреймворк, это законченный продукт, адаптированный под конкретные ресурсы и цели.Оно не будет использоваться, если не станет мейнстримом. Сначала им должны поиграться, быстро запустить, быстро заценить, и потом уже вставлять куда-то. Сложность должна возрастать - для попробовать одна, для разворота чуть сложнее, для миллиона юзеров - ещё сложнее. А не вываливать всю сложность сразу, тогда просто никто не будет разбираться. Потому что никто не знает, что это, и не будет тратить огромные усилия, чтобы только узнать "а что это такое, и как работает?"
В django для кэша, сессий и пр. есть дофига средств. Почему бы не дать одмину это всё сконфигурировать под себя, не заставляя непременно использовать memcached?
> В django для кэша, сессий и пр. есть дофига средств. Почему бы
> не дать одмину это всё сконфигурировать под себя, не заставляя непременно
> использовать memcached?Серьезно? Я не знал..
Я думал там стабильно: 'django.contrib.sessions'...
А какие средства которые я могу как админ сконфигурировать под себя?
Ну, здесь то нет, а на абстрактном проекте?
В смысле, для сессий приложение одно, но настроек дофига, и его возможностей для хранения сессий в memcache хватает.
https://docs.djangoproject.com/en/dev/topics/http/sessions/#...
> В смысле, для сессий приложение одно, но настроек дофига, и его возможностей
> для хранения сессий в memcache хватает.
> https://docs.djangoproject.com/en/dev/topics/http/sessions/#...Супер! Спасибо!
Отписал и они уже сделали тикет.А расскажите еще что-нибудь интересное?:)
> А расскажите еще что-нибудь интересное?:)В начале было слово...
безбазное :)
>> А расскажите еще что-нибудь интересное?:)
> В начале было слово...
> http://hg.51t.ru/nz/
> безбазное :)Кстати, раньше оно было на sqlite3, и по сравнению с ним, скорость возросла в 5 раз на поиск и в 30-60 раз на генерацию странички.
Вот зачем полезно новости публиковать:-) сразу становится понятно куда поект двигать!:-)Спасибо за комментарии!