红豆、绿豆和本地化


红豆绿豆一起炒,倒进盘子里哗啦一下红豆绿豆都分开了,为什么呀?俩豆 —— 很老的笑话了,今天提起来不是炒冷饭啦,只是因为昨天和几个美国同事聊天,说起软件汉化多么难,别说汉化了,就说这个红豆绿豆的笑话翻译到英文都几乎不可能 —— 英文是有单复数的,如果上手第一句就讲 Someone is frying a red bean and a green bean… —— 好吧,包袱就没得抖了。

收到了一些来自中国用户的反馈,有几条讲到了 Access 在汉化时候的拗口和不地道。比如把 Named Macro 叫做“已命名的宏”,粗看还过得去,但是在“Create a New Named Macro”这样的上下文里面,这就变成了“新建一个已命名的宏”,Oops… 不免有点自相矛盾了… 把这个bug拿来和红豆绿豆一起讲并不是想推委说这个 bug 是不能避免的,只是想说汉化真的是很难很难,尤其是汉化一个功能繁多,应用场景复杂的软件,一个翻译在一个场景之下行得通,再另一个场景下就不 make sense了。在有限资源的情况下,如果我们可以得到中国用户的反馈,这对于我们来说是莫大的帮助。不仅是汉化啦,对于软件功能的适用性,对中国用户的深入理解,对中国市场的前瞻,你们都比在隔海遥望的我们更有切身体会。

这个博客开在这里不是为了广播我们,而是为了倾听你们的声音 :)刚发了一个小的调研,请大家能够做一下:http://deploy.ztelligence.com/start/index.jsp?PIN=15WBQYFW2L99C

P.S.: 问题1-3只需要基于你是白领上班族、公司IT部门员工、还是程序员,选一个做就可以了。然后4-6是单选。应该2分钟就可以做完吧~~ (做不完是你中文阅读慢哦!=P)

 

- Lois


Comments (3)

  1. gnoy says:

    自从与您交流过后一直未能收到问题正面答复,既然微软能放下身段倾听中国的声音,我作为从未出过国门的中国用户理应有此权利,下面我就提点尖锐的。当然,我也不一定要获得正面回复,提是我的权利,获得答复是你的权利,哈哈

    1.微软ACCESS项目组到底是否真正了解自己的产品优势和劣势吗?这个问题问的有点愚蠢,自己的孩子自己还有不清楚吗?但我觉得有时候可能不敢正面问题所在,所有家长都认为自己的孩子最优秀,但不敢回答为什么成不了爱因斯坦(泛指啊:))。

    2.我所认为的ACCESS优势

    2.1正如你前问说到过的“小王选择了Access是看中了Access“一站式”的服务,不仅有表单,窗体(form),还有报表。”,这个优势是天生的,没必要天天挂在嘴边:)。

    2.2非常优秀的子窗体,子报表。这个概念的产生比这个功能要重要的多,目前包括.NET也没有类似解决方案,只有蹩脚的替代方案。

    2.3非常优秀的报表解决方案,目前无类似其他语言或工具可以与ACCESS报表相提并论,无论是设计阶段还是报表预览打印都无可挑剔。

    3.我所认为的ACCESS劣势

    3.1非常令人头疼的部署,并不是说你装了ACCESS就能正常运行开发人员开发的应用程序。你还要了解com组件的兼容性。即运行环境还有待提高

    3.2VBA不同操作系统环境下的表现差异还有待缩小。开发跨不同语言的应用程序是个灾难。

    3.3什么时候.net的优秀特性能加以移植到窗体中,断开连接是非常优秀的理念。窗体的记录集为什么不能和vb中datagrid的记录集特性一样,我所指的是他们都是记录集但产生的xml却不一样。datagrid的记录集产生的记录集完整保留了数据新增记录,修改记录等信息。通过ADO可以很方便维护数据,而ACCESS的窗体记录集产生的XML无此功能。

    3.4虽然可以通过ADO调用远程XML来变通调用远程ACCESS JET数据,貌似这个功能已经遭到.NET的弃用,ACCESS如何来加强这个远程调用JET数据功能。

    3.5我敢肯定,ACCESS新增加的WEB窗体等WEB功能是个鸡肋如同页的下场。因为它不是在扬长避短,而是另起炉灶,而且自身的发展居然受制于人。宏可能是未来发展方向,但不能超越VBA前始终前途渺茫。一个有N多替代方案的东西的出台本身就是个错误。就拿你说的前一篇例子来说。即使使用过时的ado+XMLHTTP来处理,通过ACCESS客户端一样可以获得数据,能获得数据就可以利用ACCESS的报表,干嘛还要使用SharePoint呢。

    3.6ACCESS操作SharePoint是在帮助SharePoint呢,还是SharePoint是在帮助ACCESS。我觉得这个要搞清楚。如果是后者我支持ACCESS中新增加的WEB窗体概念。

    暂时就这么多,未来会一直关注您的博客,但可能不会轻易出手了:)

  2. Garry Trinder says:

    非常感谢gnoy的留言,首先是你对Access优势的肯定,来自客户的肯定是对Access项目组所有组员的鼓励。

    你说到了Access需要改进的地方————这也是我们花时间写博客要听到的意见和建议:关于你提到的Access以来COM组件问题,你是不是介意给我发email详细介绍你是怎么用Access的时候遇到这个问题的呢?是不是在runtime里面用到了ActiveX控件呢?我想知道更多的详细情况,并请负责相关方面的组员来解答你的问题。

    关于VBA跨不同语言操作,从开始到现在,绝大多数的Access应用程序都是在目标语言环境下,基于目标语言而设计的。这并不代表说将来这不会变。我已经将你的意见转述给了Access项目组VBA和Expression方面的同事,他们会在设计Access下一个版本的时候把这一个需求考虑进去,他们会综合其他的需求一起考虑,排重要性,最后决定会不会对产品在这方面作改进。

    Access和SharePoint并不存在谁帮谁的问题 :) Access和SharePoint两者各有各的强项,结合二者是为了帮助有需要把Access数据库搬到网络来应用的用户。如果你没有这方面的需求,可以继续使用Access胖客户端的功能,继续使用VBA, 并且尝试我们新增加的data macro,导航模块,等等,我也很想知道使用这些新功能对你现有的客户端Access应用程序带来的价值 :)

    谢谢!

  3. zhuyiwen says:

    看了你的文章,感觉Office的帮助文档就不再那么生硬了,呵呵。

    文化的差异呀……

Skip to main content