0.00
22 читателя, 46 топиков

OpenERP+Asterisk (Часть 2) Как переформатировать номера телефонов (click2dial)

Статья в процессе редакции


Оригинал статьи

OpenERP+Asterisk коннектор




Как переформатировать номера телефонов


Эта диаграмма объясняет, как номерами телефона управляет asterisk_click2dial модуль.
В диаграмме эти два примера (ex1, ex2 и ex3) основаны на следующей конфигурации:

— Приставка: 0

— Национальная приставка: 0

— Международная приставка: 00

— Моя приставка страны: 33

Читать дальше →

OpenERP+Asterisk (Часть 1) Коннектор OpenERP- Asterisk (click2dial)

Статья в процессе редакции


Оригинал статьи

OpenERP+Asterisk коннектор




Введение

Asterisk — программное обеспечение OpenSource для телефонии. Это программное обеспечение используется, чтобы управлять IP системами в PBX компаниях, объединенных с IP телефоном для каждого служащего и трубками SIP на xDSL или традиционные ISDN линии, чтобы получить доступ к общественной телефонной сети. Asterisk доступна в соответствии с GNU General Public Licence и отредактирована американской компанией Digium. Если Вы хотите знать больше о Asterisk, пожалуйста, прочитайте ее Wikipedia страницу.

Описание коннектора

У коннектора OpenERP- Asterisk есть три главных функции.

Первая, добавляет кнопку набора в представлении адреса партнера так, чтобы Ваши пользователи могли непосредственно набрать номер телефона через Asterisk. Эта функция обычно известна как click2dial. Вот, как это работает:
Читать дальше →

Что легко, а что сложно в OpenERP (в плане разработок)

Здесь я немного хотел бы осветить процесс разработки в OpenERP. Сказать или рассказать, что доступно выполнить, имею ввиду доработок или дополнений (расширений к основным модулям), а что сложновато.

Рано или поздно каждый с этим сталкивается. Ведь не даром же на сегодняшний день существует более 2000 модулей. На самом деле около 50% процентов этих модулей это добавка всего лишь нескольких полей к существующим модулям. Это то что каждый из вас сможет сделать за несколько минут (технически) :).

И так что просто:
Читать дальше →

Заметка о переводе - первая (технические средства)

Общим местом является использование юникода и системы gettext. В модулях OpenERP каждый модуль имеет подкаталог i18n (это сокращение для довольно длинного internationalization — по количеству букв — I18n). В этом каталоге располагается файл-шаблон эталона перевода с расширением .pot и национальные файлы с расширениями .po. Файл .pot создаётся отдельно после написания всех программ и подпрограмм модуля, вбирает в себя все строки программ подлежащие переводу и имеет не плоскую структуру. Это хорошо видно при его просмотре с помощью простого текстового редактора. Здесь и автор перевода и комментарии по каждой строке и возможные варианты перевода для числительных и…

По большому счёту система gettext является националистической, поскольку предоставляет преимущества в скорости работы исключительно английскому языку. В случае других языков идёт поиск и подстановка, что естественно замедляет работу программ при большом объёме текстового вывода.

Я помню первые варианты интернационализации паскаля: там сообщение в программе кодировалось в цифре — номер программы, номер подпрограммы, номер сообщения. Для возможности правки, сообщения нумеровались с интервалом в десятки и сотни. Далее для каждого языка были плоские таблицы и все национальные языки были равноправны в скорости работы. Можно было создать единственный файл с ключами и переводами по довольно большим проектам.

Однако главное-то в том, что все строки перевода привязаны по месту в программах и подпрограммах модуля. В .po файле может быть несколько идентичных строк для перевода, но у них разные привязки. Из этого следует, что при обновлении в программах модуля строк кода Python (при добавлении или удалении), связи рвутся и образуются дыры в уже переведённом. Разработчики, как я понял, мало обращают внимание на это обстоятельство и обновления .pot файлов производятся только в момент новой версии.

Файлы .pot служат, как я уже сказал, шаблоном для национального файла перевода — например, ru.po

Инструмент для перевода удобнее всего, на мой взгляд, редактор poedit, он кроссплатформенный и имеется и в Linux и в Windows, хотя конечно есть и несколько других редакторов (тот же Emax). Сам .pot файл содержит только английский текст строк и пустые строки для перевода. Причём иногда строку правильнее называть позицией, потому как текст для перевода может быть весьма объёмным (например, лицензия GNU в файле для GTK клиента). Редактор poedit позволяет создать из .pot файла национальный .po файл, а также скорректировать .po файл по изменениям в .pot файле.

Из-за различной концовки текстовых строк в NIX и Windows приходится делать два варианта файлов перевода. Пакетное изменение не проходит в связи с содержанием в файлах служебной информации иногда совпадающей с символами конца строк. poedit в настройках позволяет задать вариант концовки строк.

По правилам Pythona на основе .po файлов должны автоматически создаваться транслированные (сжатые и более быстро работающие) файлы .mo, но я вижу это в единственном числе только в GTK клиенте.

Файлы .po срабатывают только однажды: при создании базы данных. Далее все переводы статически хранятся в базе данных и изменение файлов .po никак не влияет на корректировки перевода. Для коррекции нужно запускать сервер с параметром обновления или создавать новую базу.

Предлагаемая разработчиками система перевода от пользователей далеко не всегда работает по всему содержимому показываемого экрана и не может обеспечить полностью 100% перевод. Вдобавок безсистемные переводы от многих пользователей вносят сумятицу понятий в переводах.

Система Rosetta ориентирована на точечные исправления. И затрудняет действия при объёмном переводе.

Эта статья входит в цикл статей «Заметки по русификации». Все заметки:
Предлагаю заметки по русификации OpenERP
Заметка о переводе — первая (технические средства)
Заметка о переводе — вторая (что нужно, и что не нужно переводить)
Заметка о переводе — третья (стиль перевода)
Заметка о переводе — четвёртая (локализация)
Заметка о переводе — пятая (горячие клавиши)
Заметка о переводе — шестая (как пристроить перевод)
Заметка о переводе — седьмая (термины перевода)

Предлагаю заметки по русификации OpenERP

На основе некоторого опыта предлагаю серию своих заметок по переводу продукта на русский язык. В начальные времена Wndows перевод был коряв и более толковая работа получалась на английском. Но OpenERP никак не подходит к личному использованию, а вколачивать текущие данные и пользоваться результатами аналитики будут люди имевшие в школе по английскому 3 с — или вообще учившие немецкий или французский. Так что вопрос перевода весьма значимый.

Разработчики OpenERP весьма вольно подошли к использованию системы gettext и внесли в файлы переводов непереводимые куски динамически формируемых кодов условий и подстановок (например для массовых рассылок). Эти штуки называются доменами (областями) и заключаются в динамически, опять же, формируемые квадратные скобки.

Вся эта прелесть записывается статически в базу данных и при изменении перевода или отдельных модулей никак не изменяется, если не запустить сервер с параметром обновления. Могут одновременно существовать различные базы с различными переводами и различными вариантами модулей при наличии самых последних обновлений, которые их никак не касаются.

Эта статья входит в цикл статей «Заметки по русификации». Все заметки:
Предлагаю заметки по русификации OpenERP
Заметка о переводе — первая (технические средства)
Заметка о переводе — вторая (что нужно, и что не нужно переводить)
Заметка о переводе — третья (стиль перевода)
Заметка о переводе — четвёртая (локализация)
Заметка о переводе — пятая (горячие клавиши)
Заметка о переводе — шестая (как пристроить перевод)
Заметка о переводе — седьмая (термины перевода)

Улучшенный аналог ondelete=restrict для полей many2many

По умолчанию у полей с типом many2many нет параметра ondelete, как у полей с типом many2one, который отвечает за то, что делать с элементом, который ссылается на другой элемент, если этот другой элемент удаляют.

У опции ondelete есть в таком случае два варианта:
cascade — удалять элемент при удалении родителя (не знаю как правильно назвать тот элемент, НА который ссылаются)
restrict — запрет удаления родительского элемента

Бывают случаи, когда для полей many2many тоже было бы неплохо использовать аналог опции ondelete=restrict. У меня как раз такой случай. Есть две модели — product.attribute и product.attribute.group, между которыми связь many2many.

Читать дальше →