odoo开发支持国际化语言的第三方应用

英语开发并安装好应用的单语言版本
普通视图元素的string、help、sum、confirm、placeholder属性文本自动导出
QWeb模版(包括服务端和客户端两个部分),如果没有用t-translation=”off”关闭翻译,
则title、alt、label、placeholder属性文本也会自动导出
关于模型字段(Model Field),如果模型没有标注_translate = False:则string和help属性默认可导出;selection类型字段文本也可导出;translate属性设置为True,则所有存在值(values)都会导出
_constraints和_sql_constraints约束中的help、error信息会导出
其它代码里显式调用国际化字符串获取接口的参数值一同导出

管理员设置
翻译(Translations)=》导入/导出(Import / Export)=》导出翻译(Export Translations)
语言(Language)选择新语言翻译模版(New Language Empty translation template)
文件格式(File Format)选择PO File
导出应用(Apps To Export)里选择您的模块
导出(Export)=>下载《模块名.pot》文件

模块新增i18n目录
将上一步导出的文件移进去作为基准翻译模版
以此模版为基础简单的另存为其它语言文件如:zh_CN.po
或者使用PO editor等编辑软件所译即所得自动生成
还可以当前目录直接运行msginit命令默认生成操作系统对应的语言版本文件

与直接模版另存为比较多了以下三项区别:

根据语言文件内的各项原文本msgid部分翻译成对应的msgstr值
加载翻译分别选择各种语言并覆盖已存在的术语(odoo9更新模块也可达到部分效果)
选择不同的用户语言即可整体确认翻译质量

应用发布
odoo9和odoo8的翻译文件不太兼容,主要是因为各自对msgid的引用方式不同
需要分别针对不同版本的系统制作翻译文件并发布到对应分支上

浏览器每次访问odoo自动向官方服务器发送公司database.uuid信息

Odoo是经典的Web富客户端应用,每次启动都需要预加载很多资源
但是突然有一个外域请求让人很奇怪:

初步分析是一个html link标签发出的get css请求,然后通过301跳转了一次还是空白返回。虽诡异但合规,所以浏览器也没有任何报错
关键就在于这个请求的文件名:2ad90276-9cfa-11e5-9d21-5ce0c51da5ec.css
前缀其实就是系统参数里的database.uuid信息值
这就说明odoo官方其实是可以根据这个估算出每个实施项目的用户情况统计

但对于访问用户来说,虽然是异步请求,但只要没意义多一个都嫌多,特别是内网用户
经过阅读源码发现统计请求来自mail模块(Discussions, Mailing Lists, News)里的announcement.js,其几十行javascript代码随便注释下就可以搞定

刚巧最近在研究应用开发,知道前后端的模版都可以通过继承的方式来进行间接修改
那样最大的好处是官方的源码可以随时同步更新而不用担心直接修改带来的合并冲突
从前端架构的角度来说,模版的继承特性比模块类的继承特性难度大多了,查了下官方文档果然有记载模块类重载的方法

最终根据odoo8和odoo9的异同点特性不断精炼,得到如下兼容代码:

虽然简洁,但不能直接拿来即用,但懂应用开发的朋友绝对一看便知:)

nginx统一多个server location favicon.ico

icon文件存放位置
/var/www/favicon/favicon.ico

/etc/nginx/conf.d/favicon.cnf

或者忽略错误与访问日志

/etc/nginx/conf.d/domain.conf等相关server段里面include统一管理

浏览器书签功能脚本导入文件模版

今天用bookmark script快速实现了一个小功能想分享给朋友
为了将使用过程包装成足够简单易用,我想到了用书签文件交流这种方式
本以为用浏览器导出对应的书签即可,没想到大部分的浏览器只有全部导出功能
于是非常必要有一个最小结构的模版方便随时填充随时交换

odoo.py auto-reload dev自动重启服务ENOSPC系统错误解决

Odoo8
正常环境下直接–auto-reload参数运行缺库错误

pyinotify是一个Python模块,用来监测文件系统的变化
pyinotify依赖于Linux内核的inotify功能,是一个事件驱动的通知器,其通知接口通过三个系统调用从内核空间到用户空间
pyinotify结合这些系统调用,并提供一个顶级的抽象和一个通用的方式来处理这些功能

安装
pip install pyinotify

运行时错误:

Odoo9
正常环境下直接–dev参数运行日志警告

Watchdog是一个跨平台的Python库和shell工具,可以监视文件系统事件。超级好用,并且容易上手

安装
pip install watchdog

运行时错误:

Node
想起来当初刚玩node时也时常会遇到这个错误
不过大多直接sudo运行就可解决,简单理解权限问题也没有深究
但是odoo不能这么搞,源码限制:

还好从odoo9的报错信息里显而易见问题出自底层inotify对一般用户的限制
简单学习了下,得知其有个max_user_watches的内核参数限制普通用户一次最多关联监控个数。一般默认值8192,对于odoo这种大工程或稍大一点的node项目来说明显是不够用的

先通过如下方式验证:

然后通过su切换root身份动态更新配置值放大64倍

接着用不同版本的启动参数运行即可看到AutoReload watcher running成功了

最后还需要将动态修改的参数通过静态配置方式固化下来,否则每次重启还需要重复修改
Centos7下我不建议直接修改/etc/sysctl.conf文件配置,而是通过sysctl.d目录新建独立配置

然后重新启动或者使用

sysctl命令system参数立刻生效

Linux centos yum install odoo rpm postinstall scriptlet

众所周知,odoo官方提供了非常方便的yum安装源用于一键安装
只需先根据版本配置源

odoo8

odoo9

之后即可一键自动解决依赖安装

相信源码安装过的同学都一定很好奇
这么繁琐复杂的细节居然可以全部包装到一个rpm包里透明掉了
还有那么多依赖库,怎么可能yum里全部都有
带着这种疑问认真研究了下
才知道rpm包内除了相应的程序,还可能有pre和post install两个shell脚本
分别对应安装前和安装后执行
以下为8.0版本latest rpm包为例,其中文注释为本人补充方便整体理解

可见诸多内幕与细节全都在这段脚本里完美体现了
知己知彼,剖析清楚每一行代码后,对基于源代码的个性化定制安装部署又有了新的认识