希望翻译能符合中国人的习惯(版主请看)
今天我去i18n看了看汉化的方式，好像都是把单词一个个对照着翻译，但这样会造成长一些的词或句子读起来很别扭。另外，我希望翻译的时候有些词的用法能尽量和windows靠拢，这样从windows转过来的人会适应得快些(比如：放弃 改为 取消)</br>还有一个问题，日历的那个“星期”还是没有翻正确嘛(如图)。我觉得应译为 第35周才对 qianzheng82Linux中级社员所言极是 没办法，如果一个一个的翻译，时间太长了，人手又少，所以有很多是通过字典翻译的，有这个现象，至于放弃还是取消，好像在win下不同环境也不一样的。 天知道你说的是哪个软件，我们也没法改呀。哪里有“放弃”啊？
我们会竭尽所能做到让大家满意。你有兴趣可以看看 Evolution 1.4.2+ 中的联系人管理。我们已经将百家姓分配到了ABCD字母表中了，比如“张三”就在“Z”里，“李四”在“L”里。不知道这样你是不是满意。
不过有时候翻译成什么不是我们能够控制的。比如你说的这个例子，假如我们从程序员那里得到的字符串只有“Week”一个的话，那么我们只能翻译为“星期”。但假如我们得到是一个标准的C字符串“Week %d”的话，我们就知道应该翻译为“第%d周”了。 翻译后应该进行检查，否则质量就难保证了。
如果测试中发现这类错误，只有修改源代码了。 如果这个week的翻译要改源码的话，那可以用“周次”来代替。因为一个英语单词可以有好多种译法，但确时要根据实际的语境来译，并不只是一个词一个词机械地对照翻译。当然现在Linux的中文翻译也已经很不错了，在此也要谢谢各位所做出的努力。我只是希望中文化能更完美。 世界上所有的语言都是存在二义性的。Week 可能在此处是“周次”这个表顺序的词，而在其它地方可能是和Month，Day等组合使用，是真正的名词“星期”。又如，Columns这个词，看来好像是“列”的复数比较适合。但在某些情况下，比如KWord里的插入表格对话框，那么还是“列数”比较好。
你所说的语境，也是我们翻译者所期望的。但可惜，目前Linux下软件的翻译，只是机械的字符串对译，一点语境的含义都没有。也就是说，不管一个软件里出现了多少个Week，这些Week是在哪里出现的，我们翻译者只会得到一个单一的Week。假如我们将这个Week翻译成了“周次”，那么这个软件中所有的Week也将变成“周次”。这个结果当然不是我们想要的。
就目前的情况而言，虽然中文翻译在质控上还有欠缺的地方，但也绝对没有落到和某些机器翻译的结果那样驴唇不对马嘴的情况。
不过说到头，我还是不知道这个是什么软件，也没法改。 翻译质控问题我们的组织一直都很关注，也一直都在努力改进。但是很多东西并非是翻译者能够控制的了的。
举例来说，你写了一个软件，由于中文没有单复数区分，波兰语的单复数变化甚为复杂，波兰语翻译员根本不知道你所指的句子是哪种单复数形式，翻译出来就只有一种形式，实际显示出来，可能会驴唇不对马嘴。
事实上，我们内部有严格的质控制度，如果你是翻译，你可能会不舒服的。 翻译后应该进行检查，否则质量就难保证了。
如果测试中发现这类错误，只有修改源代码了。
通常开发者都不太关注国际化问题，即便发现源代码有错误，也很难说服开发者修改。翻译者都是外围人员，很难接触到源代码。我们的翻译往往是同步推出的，很难做到逐个测试，开发者也不会等待我们。再说，开发中的软件不一定都能编译成功。很多翻译者是不会写软件的。 世界上所有的语言都是存在二义性的。Week 可能在此处是“周次”这个表顺序的词，而在其它地方可能是和Month，Day等组合使用，是真正的名词“星期”。又如，Columns这个词，看来好像是“列”的复数比较适合。但在某些情况下，比如KWord里的插入表格对话框，那么还是“列数”比较好。
你所说的语境，也是我们翻译者所期望的。但可惜，目前Linux下软件的翻译，只是机械的字符串对译，一点语境的含义都没有。也就是说，不管一个软件里出现了多少个Week，这些Week是在哪里出现的，我们翻译者只会得到一个单一的Week。假如我们将这个Week翻译成了“周次”，那么这个软件中所有的Week也将变成“周次”。这个结果当然不是我们想要的。
就目前的情况而言，虽然中文翻译在质控上还有欠缺的地方，但也绝对没有落到和某些机器翻译的结果那样驴唇不对马嘴的情况。
不过说到头，我还是不知道这个是什么软件，也没法改。
关于翻译时有些词语有二义性的问题，其实已经有完美的解决方案了，可以参考一下 freeciv 的做法：
http://www.freeciv.org/i18n.html 上说得比较详细，可惜现在不是所有的程序都是这样做的，但我觉得做法值得推广。
另外做翻译不是死死的翻译 po 文件，像 Week 这个词出现了 二义性，你完全可以按照 freeciv 的做法，对源码做个小小的 patch， 就可以解决问题。 翻译质控问题我们的组织一直都很关注，也一直都在努力改进。但是很多东西并非是翻译者能够控制的了的。
举例来说，你写了一个软件，由于中文没有单复数区分，波兰语的单复数变化甚为复杂，波兰语翻译员根本不知道你所指的句子是哪种单复数形式，翻译出来就只有一种形式，实际显示出来，可能会驴唇不对马嘴。
事实上，我们内部有严格的质控制度，如果你是翻译，你可能会不舒服的。
单复数的问题同上，参考 freeciv 的做法。 是啊~
要做就作最好的哦~~~~~
精益求精ing~~~~~~ 我在 kde-3.2-beta1 中发现 week 的错误已经修正，很让人惊喜，在此也感谢各位所做的努力。 运用perl强大的正则表达式字符处理能力可能能使翻译过程更智能化:)自动化不用说啦。
仅供参考^_^不过语境机器真是很难判断。 第一，只有熟练的用户才能保证翻译的质量。和程序一样，翻译也是有测试——完善——测试——再完善直至发布稳定版的过程；只有翻译者自己频繁使用自己翻译的测试版本，才能尽量及时修正错误。
第二，翻译一定要看上下文，POT文件里有程序作者的注释的地方，往往是最难翻译的地方；此外，源代码几乎是必备的。
第三，不要怕给程序作者写信，很多程序的作者是很在意自己程序的国际化的，尤其是来自CJK的意见。再者说，他若是不理你，那也是他自己的损失。
页:
[1]