php-i18n Digest 6 May 2010 18:03:56 -0000 Issue 445
Topics (messages 1401 through 1407):
Re: How to i18n better?
1401 by: Norbert Lindenberg â»
1402 by: Tomas Kuliavas
1403 by: Darren Cook
Gettext (was how to i18n better?)
1404 by: Tex Texin
1405 by: Wil Clouser
1406 by: Tex Texin
¡°Îå-Á¬-¹á¡±¹É|Ȩ-¼¤|Àø-·¨
1407 by: qbeftywu
Administrivia:
To subscribe to the digest, e-mail:
[email protected]
To unsubscribe from the digest, e-mail:
[email protected]
To post to the list, e-mail:
[email protected]
----------------------------------------------------------------------
--- Begin Message ---
ICU, the internationalization library underlying the PHP intl
extension, has had support for plural formats since version 4.0, and
added support for gender-based formatting in version 4.4. Both are
available through pattern strings for the PHP MessageFormatter class.
See:
http://docs.php.net/manual/en/class.messageformatter.php
http://icu-project.org/apiref/icu4c/classPluralFormat.html
http://icu-project.org/apiref/icu4c/classSelectFormat.html
Norbert
On May 2, 2010, at 21:19 , Tomas Kuliavas wrote:
Andre Polykanine rašė:
Hello Tomas,
A good point about plurals! How do I handle them if I have Ukrainian,
Russian, and English interfaces?
Check gettext manual (http://www.php.net/ngettext).
Either you use gettext or you are doomed to reinvent it.
--
PHP Unicode & I18N Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--- End Message ---
--- Begin Message ---
Norbert Lindenberg ♻ rašė:
ICU, the internationalization library underlying the PHP intl extension,
has had support for plural formats since version 4.0, and added support
for gender-based formatting in version 4.4. Both are available through
pattern strings for the PHP MessageFormatter class. See:
http://docs.php.net/manual/en/class.messageformatter.php
http://icu-project.org/apiref/icu4c/classPluralFormat.html
http://icu-project.org/apiref/icu4c/classSelectFormat.html
Does it have tools to extract translatable strings from source?
Does it have tools to merge current strings with existing translation?
Does it have tools to edit translations?
Does it have tools to check translations for errors?
ICU might have tools to write localized strings, but I think it does not
have all tools available for gettext. intl extension is new and has
complex syntax. gettext is old, simple and tested. It could be more
stable, if stability was not borked on PHP 5.3 and windows platform.
--- End Message ---
--- Begin Message ---
>> Either you use gettext or you are doomed to reinvent it.
...
> ICU, the internationalization library underlying the PHP intl extension,
> has had support for plural formats since version 4.0, and added support
> for gender-based formatting in version 4.4.
Has anyone here used gettext and then switched to the ICU solution, and
can comment on what it does better than gettext, and what they feel is
missing?
An interesting article here, see section 10.2:
http://wiki.zope.org/zope3/i18noverview.html
My interpretation of this is they wanted to use ICU for Zope3 but it was
too big to port to python, so they borrowed some of its ready-made
translation data, and then used gettext because it was already available
for python.
Darren
> Both are available through
> pattern strings for the PHP MessageFormatter class. See:
> http://docs.php.net/manual/en/class.messageformatter.php
> http://icu-project.org/apiref/icu4c/classPluralFormat.html
> http://icu-project.org/apiref/icu4c/classSelectFormat.html
>
>> Check gettext manual (http://www.php.net/ngettext).
--
Darren Cook, Software Researcher/Developer
http://dcook.org/gobet/ (Shodan Go Bet - who will win?)
http://dcook.org/work/ (About me and my work)
http://dcook.org/blogs.html (My blogs and articles)
--- End Message ---
--- Begin Message ---
This discussion seems to confuse several different aspects of message handling.
I don't have time for a lengthy note, so briefly:
To support localization of text you need several different capabilities.
There is of course storing and retrieving of strings by locale.
This is gettext's main mission.
On top of that you need message formatting functions- support for embedded
variables with ordered placement holders, support for message variants based on
number (singular, plural, and other).
You may want tools for extraction.
You will want a way to send strings out for translation and to incorporate
translations into the application.
You will want a deployment strategy (how are the strings packaged and sent
along with the application).
You may want an update mechanism (adding languages and fixing strings without
changing code or resending the entire application)
You may want some tools to verify the translated strings are physically
consistent with the originals (same number of embedded variables, same number
of strings, etc.)
You may want inheritance or other hierarchical approach to reusing strings
across locales. (English for US, Canada, etc.)
Gettext is basically storage and retrieval. It's model is designed for
applications that get packaged and distributed to end-users.
ICU is a complete package for internationalization and Unicode support. It's
message storage and retrieval is ok. It's message formatting is much more
robust than gettext. It is sizable, but can be stripped down.
PHP applications being server based, and generally already using a database in
conjunction with most applications, can easily use a simple database design for
string storage and retrieval by locale.
You need to address how you will package strings to go out for translation and
load them, but that is trivial to arrange. To the extent you can provide a
simple php app to enable translators to update the database more directly, you
can greatly simplify and accelerate localization and testing.
An important aspect of localization is to enable translators to view the
context and the results, to raise quality.
If you can eliminate the string file submission, compile, build stages and let
the translators see the results almost immediately without development
involvement, it is a big win.
Performance of string retrieval from the database is very high.
Eliminating the management and workflow around lots of string files is
important.
Gettext has its place, but its not the best solution for php, or more generally
server based, apps.
The php 5.3 functions for message formatting via icu are very good and provide
the needed capabilities.
If you have existing code and need to extract strings, there are tools that
will do that.
Some freeware, some commercial (like lingoport globalyzer).
I would not worry about being doomed to reinvent gettext. It is trivial to do
so, and all in all there are better approaches for server-based apps.
tex
--- End Message ---
--- Begin Message ---
If you are really interested in this kind of thing and want to look at
improvements over gettext, you should get in touch with the people
working on https://wiki.mozilla.org/L20n . It has a long ways to go,
but there is a lot of thought being put into how to make a better
system.
Wil
On Mon, May 3, 2010 at 5:59 PM, Tex Texin <[email protected]> wrote:
> This discussion seems to confuse several different aspects of message
> handling.
>
> I don't have time for a lengthy note, so briefly:
>
> To support localization of text you need several different capabilities.
>
> There is of course storing and retrieving of strings by locale.
> This is gettext's main mission.
> On top of that you need message formatting functions- support for embedded
> variables with ordered placement holders, support for message variants based
> on number (singular, plural, and other).
>
> You may want tools for extraction.
> You will want a way to send strings out for translation and to incorporate
> translations into the application.
> You will want a deployment strategy (how are the strings packaged and sent
> along with the application).
> You may want an update mechanism (adding languages and fixing strings without
> changing code or resending the entire application)
> You may want some tools to verify the translated strings are physically
> consistent with the originals (same number of embedded variables, same number
> of strings, etc.)
> You may want inheritance or other hierarchical approach to reusing strings
> across locales. (English for US, Canada, etc.)
>
> Gettext is basically storage and retrieval. It's model is designed for
> applications that get packaged and distributed to end-users.
>
> ICU is a complete package for internationalization and Unicode support. It's
> message storage and retrieval is ok. It's message formatting is much more
> robust than gettext. It is sizable, but can be stripped down.
>
> PHP applications being server based, and generally already using a database
> in conjunction with most applications, can easily use a simple database
> design for string storage and retrieval by locale.
> You need to address how you will package strings to go out for translation
> and load them, but that is trivial to arrange. To the extent you can provide
> a simple php app to enable translators to update the database more directly,
> you can greatly simplify and accelerate localization and testing.
>
> An important aspect of localization is to enable translators to view the
> context and the results, to raise quality.
>
> If you can eliminate the string file submission, compile, build stages and
> let the translators see the results almost immediately without development
> involvement, it is a big win.
>
> Performance of string retrieval from the database is very high.
> Eliminating the management and workflow around lots of string files is
> important.
>
> Gettext has its place, but its not the best solution for php, or more
> generally server based, apps.
>
> The php 5.3 functions for message formatting via icu are very good and
> provide the needed capabilities.
>
> If you have existing code and need to extract strings, there are tools that
> will do that.
> Some freeware, some commercial (like lingoport globalyzer).
>
>
> I would not worry about being doomed to reinvent gettext. It is trivial to do
> so, and all in all there are better approaches for server-based apps.
>
> tex
>
>
>
>
> --
> PHP Unicode & I18N Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--- End Message ---
--- Begin Message ---
Thanks Wil.
The ideas I put down are not new and have been implemented elsewhere so I am
sure the Mozilla guys are aware.
I thought this list should be aware there are other accepted approaches to
gettext.
Tex
From: [email protected] [mailto:[email protected]] On Behalf Of Wil Clouser
Sent: Monday, May 03, 2010 9:05 PM
To: Tex Texin
Cc: [email protected]
Subject: Re: [PHP-I18N] Gettext (was how to i18n better?)
If you are really interested in this kind of thing and want to look at
improvements over gettext, you should get in touch with the people
working on https://wiki.mozilla.org/L20n . It has a long ways to go,
but there is a lot of thought being put into how to make a better
system.
Wil
On Mon, May 3, 2010 at 5:59 PM, Tex Texin <[email protected]> wrote:
> This discussion seems to confuse several different aspects of message
> handling.
>
> I don't have time for a lengthy note, so briefly:
>
> To support localization of text you need several different capabilities.
>
> There is of course storing and retrieving of strings by locale.
> This is gettext's main mission.
> On top of that you need message formatting functions- support for embedded
> variables with ordered placement holders, support for message variants based
> on number (singular, plural, and other).
>
> You may want tools for extraction.
> You will want a way to send strings out for translation and to incorporate
> translations into the application.
> You will want a deployment strategy (how are the strings packaged and sent
> along with the application).
> You may want an update mechanism (adding languages and fixing strings without
> changing code or resending the entire application)
> You may want some tools to verify the translated strings are physically
> consistent with the originals (same number of embedded variables, same number
> of strings, etc.)
> You may want inheritance or other hierarchical approach to reusing strings
> across locales. (English for US, Canada, etc.)
>
> Gettext is basically storage and retrieval. It's model is designed for
> applications that get packaged and distributed to end-users.
>
> ICU is a complete package for internationalization and Unicode support. It's
> message storage and retrieval is ok. It's message formatting is much more
> robust than gettext. It is sizable, but can be stripped down.
>
> PHP applications being server based, and generally already using a database
> in conjunction with most applications, can easily use a simple database
> design for string storage and retrieval by locale.
> You need to address how you will package strings to go out for translation
> and load them, but that is trivial to arrange. To the extent you can provide
> a simple php app to enable translators to update the database more directly,
> you can greatly simplify and accelerate localization and testing.
>
> An important aspect of localization is to enable translators to view the
> context and the results, to raise quality.
>
> If you can eliminate the string file submission, compile, build stages and
> let the translators see the results almost immediately without development
> involvement, it is a big win.
>
> Performance of string retrieval from the database is very high.
> Eliminating the management and workflow around lots of string files is
> important.
>
> Gettext has its place, but its not the best solution for php, or more
> generally server based, apps.
>
> The php 5.3 functions for message formatting via icu are very good and
> provide the needed capabilities.
>
> If you have existing code and need to extract strings, there are tools that
> will do that.
> Some freeware, some commercial (like lingoport globalyzer).
>
>
> I would not worry about being doomed to reinvent gettext. It is trivial to do
> so, and all in all there are better approaches for server-based apps.
>
> tex
>
>
>
>
> --
> PHP Unicode & I18N Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--- End Message ---
--- Begin Message ---
[email protected]
《 “五步连贯”股权激励法--留驻核心人才 》
时 间:2010年5月29-30日（深 圳）
时 间:2010年6月04-05日（上 海）
（股权激励第一人薛中行博士主讲）---- 为企业建立最完善的股权激励方案
------------------------------------------------------------------------
◆课程对象：企业总裁、董事长、总经理、决策者、人力资源总监、财务总监及薪
资福利经理、中高层管理人员、HR管理从业人员等。
◆课--程--背--景：
* 如何让新员工入职后就有归属感？
* 如何让老员工永具激情和创造力？
* 如何让核心员工与企业同心同德？
* 如何让公司高管与你不离不去？
* 如何合理设计股权激励方案？◆如何能让激励达到长期有效？
* 如何优化企业股权？
* 如何在股权被稀释的同时保持控制权和经营权的统一？
* 如何既保持企业股权激励的功能发挥，又能将其操作与法律风险控制到一个防火
墙内？…… 薛中行教授将在课上一一为您揭晓答案，手把手教您设计适合自身企业
的股权激励方案。 为您的企业打造“金手铐”，有效留住核心人才，增强企业凝聚
力；
为您的企业打造“金钥匙”，彻底激发员工潜能，加速企业实现目标、发展壮大；
为您的企业打造“金色降落伞”，圆满解决元老退出各大难题；
……目前,员工持股、年底分红等“股权激励”问题是众多企业最为关注的核心问题
，薛博士“手把手”教您运用股权期权这一独特的“创富机器”,为您的企业量身打
造一幅诱人的
“金手铐”，开启人才价值的“金钥匙”。
◆课--程--收--益：
咨询式培训--课程采取小班制授课方式,这样可以更好的保证授课效果，方便现场
咨询与互动，让学员真正的能够学到、悟到、得到进而可以做到。创新性与唯一性-
-国内首家系统性的股权激励培训，先后创造了业内五个第一。系统性与全面性--课
程从人力资本提升的角度出发结合当前的法律、法规、财务、税务等各方面内容从方
案设计到激励实施都进行系统而全面的阐述。真实性与实用性---课程中所讲的股权
设计模式都是薛博士在近十年来他亲自参与的各大中型企业的实际顾问案例中总结提
炼出来的，完全都能转化运用在学员企业上.并且分享。
股权激励方面的众多经典案例，具有极高的学习和参考价值。个性化与专业性---
由薛博士亲自与学员在workshop中进行一对一的辅导与交流，运用其深厚专业的学术
知识与丰富的实战经验为学员“量体裁衣”，制定最佳方案。
◆课--程--大--纲：
◇模块一 五步连贯股权激励法
（一）股权激励“前奏曲”
1、股权、股份与股票
2、实股、期股与期权
3、短期、中期与长期
4、赠与、购买与赊账
5、有形、无形与计量
思考：财聚人聚VS财散人聚？朝三暮四vs朝四暮三？
（二）股----“好的模式是成功的一半”
1、期权模式
2、限制性股票模式
3、股票增值权模式
4、虚拟股票模式
研讨：如何根据自身情况，选择合适的股权激励模式组合？
动态股权制的建构
（三）人----“重在人力资本投资”
1、对"岗"还是对"人"?
2、从精英到员工，多大范围股权激励才合适？
3、工作性质与股权激励：高管、核心技术人员，还是营销骨干？
4、定人三段论
5、股权激励留人的核心在哪里？
思考：《劳动合同法》下如何巧用股权激励达到激励和约束知识员工的目的？
（四）价----“人力资本可计量”
1、如何给企业合理估值定价？上市公司的期权定价模型
2、如何给人员合理估值定价？
3、技术管理要素如何合理入股？
4、如何合理设计激励杠杆？
思考1：内部市场价格VS 外部评估价格？
思考2：唐骏的十亿身价与紫金矿业的高溢价发行有无联系？
（五）量----“过犹不及、与时俱进”
1、你的蛋糕有多大？
2、从1%到10%
3、六十年后看你的企业
思考：如何合理分配股份、期权额度和数量？
既不缺乏激励力度，又避免过度激励，稀释股权。 股权激励的相对数论。
（六）时----“嵌套与循环”
1、 生命周期vs行业特点
2、 股权激励的长周期与短周期
3、 延期支付与股权激励
4、 8年限制期
思考：如何选择“对的时间”来完成对的事？
研讨：金手铐是如何铸就的？
◇模块二 股权激励方案设计技巧
（一）股权激励成功的七个关键要素
1、如何评价一个股权激励的成功？
2、股权激励7要素
（二）股权激励争议案例深度剖析
1、TCL的股权激励：从赞许到失望
2、光明乳业：股权激励四人行
3、海尔高管为何辞职？
（三）股权激励的设计环节与流程
1、 股权激励整体设计流程
2、 股权激励三阶段论
3、 如何循序渐进发展股权激励
4、股权期权的会计处理及有关问题
四、我们该如何设计股权激励方案？
◇模块三 股权激励相关法律问题
1、案例分析：股权激励四大争议案例
2、证监会关于股权激励的有关规定
3、上市公司股权激励案例分析
4、财政部 国税总局等有关股权激励的规定
5、会计准则中的股份支付
思考：如何在股权激励的同时设计限制性条款？
◇模块四 股本设计股权治理技巧
1、如何合理设计股权
2、影子股票、信托股票与虚拟股票的对比。
重点研讨：如何有效设计法律防火墙，避免股权纠纷，规避为上市造成障碍
◇模块五 股权激励实战案例讨论会
与薛中行博士深入探讨自身企业设计与实施股权激励方案涉及的种种实际问题。
------------------------------------------------------------------------
◆讲--师--介--绍：
薛中行博士：股权激励第一人；毕业于中国著名高等学府复旦大学，在复旦大学
经济管理学院接受现代经济学的培养，并多次应邀访学于英美等著名高等学府。同
时出于对中国优秀古典文化的热爱，中行博士亦潜心钻研《周易》二十余载，具有
现代商业经济与中国古典哲学的双重思维方式和文化底蕴。
◇中国证监会登记结算股权激励课题组组长
◇经济学博士、资深投资银行专家
◇中国股权激励第一人，国内实战派股权激励专家
◇企业“股权激励”领域的拓荒者、权威专家
◇担任近百家企业的首席咨询顾问
◇擅长讲授人力资源与资本运作各模块的课程，尤其是股权激励课程
◇中大、浙大等多家著名院校客座教授，主讲股权激励课程，满意度高达95%
◇先后创造了业内众多个第一：
第一家系统总结了各种股权激励案例，并在此基础上提炼出国内唯一成熟可行的“
五步连贯股权激励法”；
第一家采用“股权释兵权”，为浙江一福布斯上榜企业成功解决了“元老退出”难题；
第一家将“博弈论”的分析工具引入到中国企业咨询实际，帮助企业在战略制定、股
权分配、岗位评估、企业文化方面进行独特的应用；
第一家提出“人力资源股权化”、“人力资源证券化”概念，帮助大量企业解决员工
激励难题，实现了人力资源的资本化运作；
第一家帮助双家族企业解决了公司治理难题。
薛博士有近20年的从业经验，组织并成功实施过众多著名企业公司的咨询项目，
其中包括海尔集团、宝钢集团、中石化、中外运、交通银行、华泰证券、泰阳证券、
汉王科技、海南航空、天津电力、北仑电厂、苏源集团、苏通房地产、亿达集团、长
甲集团、圣马纸业、苏常柴、民丰特纸、江苏交科院、临淄信用社、鄞州银行等，在
业界具有相当知名度。早年中行博士曾经任职于上海实业、华泰证券、联合证券等企
业，具有丰富的企业管理、企业上市、重组并购，的实战经验；熟悉ESOP（员工持股
计划）、限制性股权、业绩股票、分红权、虚拟股权、增值权等长期激励机制，在绩
效评估，平衡积分卡，薪资体系方面有着成功的案例，先后为多家福布斯上榜企业提
供咨询。
●导师授课风格
◇具有一流的讲师风格，亲和力强，是位极具人格魅力的讲师。
◇在中山大学、浙江大学等EMAB主讲的股权激励课程授课满意度连续4年排名第1。
◇深厚的理论功底和10多年近100家企业首席咨询顾问的实操经验，使其讲授的课程理
论联系实际、深入浅出，与学员产生强烈共鸣；有实例、有工具，操作性极强。
◇倡导快乐学习。授课语言风趣幽默、注重互动、鼓励参与，深受客户和学员的欢迎。
-------------------------------------------------------------------------
◆主-办-单-位：中--培--信--息--网
◆标-准-费-用: ￥4500元/人（含指定内部教材、午餐、茶点费等）
◆报-名-咨-询：T E L: (０７５５) ６１２８ ０１５２（深 圳）
◆报-名-咨-询：T E L: (０ ２ １) ５１０８ ３２９０（上 海）
-------------------------------------------------------------------------
[报 名 回 执 表]
F A X:(07 55) 6128 0153 或 (0 2 1) 5108 3296
我单位共____人报名参加2010年___月____日在□深圳、□上海举办的:“五步连贯”
股权激励法--留驻核心人才；
单位名称：_______________________________ 参会人数:_________人
联系人：___________ 电 话:______________ 传 真：________________
参会费用:￥：______________元 邮 件：_________________
参 会 人：_______________________________________________________
付款方式：□1、现金 □2、转帐
预订项目：□是、□否 住宿（请选择打“√”）
备注:请您把报名回执回传我司，��确保您报名无误,请您再次电话确认!
--- End Message ---
