Vir*_*dia 43 php locale internationalization
我读过Joel关于Unicode的文章,我觉得从字符集的角度来看,我至少掌握了国际化的基本知识.除了阅读这个问题之外,我还做了一些关于设计考虑的国际化研究,但是我不禁怀疑还有更多我不知道或者不知道的东西.不知道要问.
我学到的一些东西:
我在哪里:
我想更多地了解:
编辑:我添加了赏金,因为我想从经验中获得更多真实世界的例子.
Adr*_*ore 56
我们的游戏Gemsweeper已被翻译成8种不同的语言.我在这个过程中学到的一些东西:
如果译者被给予单个句子进行翻译,请确保他知道每个句子的使用情况.否则他可能提供一个可能的翻译,但不是你想要的翻译.诸如Babelfish之类的工具在不理解上下文的情况下进行翻译,这就是为什么结果通常如此糟糕.试着将任何非平凡的文本从英语翻译成德语并返回,你会看到我的意思.
出于同样的原因,不应将应翻译的句子分成不同的部分.那是因为你需要维护上下文(见前一点),因为某些语言可能在句子的开头或结尾有变量.使用占位符而不是分解句子.例如,而不是
"这是我们的15步教程的一步"
写下类似的东西:
"这是我们的15步教程的第1步"
并以编程方式替换占位符.
不要指望译者有趣或有创意.除非你给特定的文字段落命名并额外付费,否则他通常没有足够的动力去做.例如,如果您在语言资产中有笑话,请在旁注中告诉译者不要尝试翻译它们,而是将它们排除在外或用更严重的句子替换它们.否则翻译人员可能会逐字翻译笑话,这通常会导致完全无意义.在我们的案例中,我们有一个翻译和一个笑话作家,用于最重要的翻译(英语).
尝试找到一个翻译人员,他的第一语言是他要翻译你的软件的语言,而不是相反.否则他可能会写一个可能正确的文本,但对母语人士来说听起来很奇怪或过时.此外,他应该与您的翻译目标居住在您所在的国家/地区.例如,来自瑞士的讲德语的人不会是德语翻译的好选择.
如果有可能,请让您的一位公共beta测试用户了解特定翻译,以验证已翻译资产和已完成的软件.我们有一些非常好的和非常差的翻译,取决于提供它的人.根据我们的一些用户的说法,瑞典语翻译完全是胡言乱语,但对它做任何事都为时已晚.
请注意,对于具有新功能的每个更新版本,您都必须翻译您的语言资产.这可能会产生一些严重的开销.
请注意,如果您的软件已翻译,最终用户将希望技术支持能够说出他们的语言.再一次,Babelfish很可能不会这样做.
编辑 - 还有一些要点
尽可能简化本地化之间的切换.在Gemsweeper中,我们有一个热键可以在不同的语言之间切换.它使测试更容易.
如果要使用外来字体,请确保它们包含特殊字符.我们为Gemsweeper选择的字体适用于英文文本,但我们必须手工添加相当多的字符,这些字符仅存在于德语,法语,葡萄牙语,瑞典语,...
不要编写自己的本地化框架.使用像Gettext这样的开源框架,你可能会好得多.Gettext支持句子中的变量或复数等功能,并且非常坚固.编译本地化资源,因此没有人可以篡改它们.此外,您可以使用像Poedit这样的工具来翻译文件/检查其他人的翻译并确保所有字符串都已正确翻译,并且在您更改基础源代码时仍然是最新的.我已经尝试过自己滚动并使用Gettext而不得不说Gettext加上PoEdit是优越的.
编辑 - 更多点
了解不同的文化有不同的数字和日期格式.编号方案不仅在每种文化方面都有所不同,而且在该文化中也是不同的.在EN-US中,您可以格式化数字'-1234'; '-1,234'或(1,234)取决于数字的目的是什么.了解其他文化做同样的事情.
了解您从哪里获取全球化信息.例如,Windows具有CurrentCulture,UICulture和InvariantCulture的设置.了解每个人的意义以及它与您的系统的交互方式(它们并不像您想象的那么明显).
如果你要做东亚翻译,那就做你的功课吧.东亚语言与语言有很多不同之处.除了具有同时使用的多个字母表之外,它们还可以使用不同的布局系统(自上而下)或基于网格.东亚语言中的数字也可能非常不同.在en-US中,您只能在有限条件下更改系统(例如1对1),除了逗号和句点之外还有其他数字注意事项.
Jav*_*ier 11
- 我的菜单和应用程序中的各种列表按字母顺序排列,以便于阅读.
列表应该排序,菜单不应该排序.请记住,给定的用户可能希望以多种语言使用您的应用程序,他仍然应该在同一个地方的任何地方找到它.
与快捷方式相同,如果你有任何:不要翻译它们.
另外,请记住,国际化和翻译是两个截然不同的事情,分别管理它们.
Epc*_*lon 11
当我们处理Dreamfall和柯南时代的i18n/l10n问题时,我们遇到了一些值得记住的问题.其中一些我们解决了,一些是为我们解决的,一些我们解决了.有些我们从未解决过......
确保您的所有工具和所有代码都支持您要使用的所有字符集,并在项目过程中再次检查该假设两次,并确保更多次.
确保使用支持您要使用的所有语言的字体.声称为unicode的大多数字体只是unicode,因为它拥有的字符位于正确的代码点.这并不意味着它对所有代码点都有可用的字符.
文本包装不仅在空格中完成,因为某些语言不使用空格来分隔单词(中文浮现在脑海中).确保文本换行例程处理文本时没有任何空格.
正确处理复数在简单的情况下是棘手的,并且在困难的情况下很难.确保您对将要使用的语言有足够的了解,以便能够编写代码来正确处理复数问题.请记住,英语(和其他"西方"语言是容易的.
永远不要打破句子并用它们构建字符串以适应变量,因为变量可能以不同的语言放在句子的其他地方.使用占位符.
请记住,对于某些语言,占位符的值可能会更改如何编写句子.语法很难.确保你有一个处理它的计划.(具体来说,请确保您有一种方法可以根据性别,时间等对您在占位符中使用的值进行分类).
我想做出以下评论 - 这些评论来自一些公司指南,其中第1类产品在31种不同的语言环境中进行翻译.遵循这些指导方针为我们(我们的开发团队而不是整个公司)提供了最高的翻译效率.
不要尝试重用错误消息的片段.例如,不要以为因为你有两个错误"You selected the wrong menu item"并且"That menu item is not yet available",可以提取"menu item"到一个单独的项目,并在两地使用.所有消息都应自包含,因为它们的翻译可能会根据上下文而改变
使用熟悉技术的专业翻译人员.如果你去接近像BabelFish这样的服务,你将得到你应得的一切.例如,"Microsoft Windows"是"Microsoft Windows"无处不在地球上,它不会成为"Microsoft Fenster"在德国.
尽量不要嵌入变量内的信息(如"The %1 has failed"这里%1因为位置的变化动态),而事实上,两性均可发生变化:"La table est rubbish"对"L'Homme est drunk",或者"The red table"VS "La table rouge".最好使用附加参数的通用名词:"The item has failed [%1]".
仅翻译用户期望看到的内容.日志文件中的日志消息(只有您将使用)应该是英语(或您的母语),而不是翻译成您无法读取的斯瓦希里语.
菜单应按功能排序,而不是按整理顺序排序.
可翻译单元应存储在代码外部并在运行时加载.这使得翻译成为一个只关闭外部文件的问题,而不是试图将更改转变为代码中间.它还使得将来更容易添加其他语言.
这就足够了.最好在你睡着之前停下来:-)
关于数字的事情:在英语中,据我所知,你只使用1和1的复数和2或更多的复数.喜欢:"你有1条消息"; "2条消息"; "3 ...消息".在俄语中,这些事情变得更加复杂.你使用单数为1,21,31,41 ... 101,121(因此,对于以1结尾的所有内容,除非它以11结尾).然后你使用奇异的格式 2,3,4; 22,23,24; 32,33,34 ...... 102,103,104; 122,123,124.在所有其他情况下,你使用复数的属格案例.
实施起来并不难.什么是辛苦,虽然是实现的东西,就会知道如何应对其所有的怪事任何先验未知的语言:-)
这只是数字:-)
到目前为止,我没有很多东西可以添加到最好的答案中,但这里有一些需要考虑和检查的事情.
好吧,我还有更多的话要说...
小智 5
有一件事我学到了很多困难:如果你有几个需要翻译的文件,在名称中包含一个额外的标签,以便以后你可以在整个文件夹中搜索该标签.
例如,不是命名文件'sample-database.txt',而是命名英文版'sample-database-loc-en.txt',意大利语版本'sample-database-loc-it.txt