翻译文件中键值的最佳做法 [英] Best practice for key values in translation files

查看:90
本文介绍了翻译文件中键值的最佳做法的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

通常,转换方法采用键>值映射,然后使用该键将其转换为值.现在,我认识到为您的翻译键命名的两种不同方法,在我们团队内部,我们尚未达成共识,这似乎是最好的方法.

In general, translation methods take a key > value mapping and use the key to transform that into a value. Now I recognize two different methods to name your translation keys and within my team we do not come to consensus what seems to be the best method.

方法1: 使用完整的英语单词或句子:

Method 1: Use full English words or sentences:

Name => Name
Please enter your email address => Please enter your email address

方法2: 使用描述情况的关键字:

Method 2: Use keywords describing the situation:

NAME => Name
ENTER_EMAIL => Please enter your email address

我个人更喜欢方法1,因为它直接显示消息的含义.如果翻译不存在,您可以退回到密钥,这不会造成任何问题.但是,当翻译频繁更改时,此方法比较麻烦,因为所有文件都需要更新.同样对于较长的文本,这些键也变得非常大.这可以通过使用ENTER_EMAIL之类的键来解决,但是措词完全不在上下文之内.抽象翻译键的列表将是巨大的,您需要所有键的元数据来说明其用法,并且冲突会更容易发生.

I personally prefer method #1 because it directly shows the meaning of the message. If the translation is not present, you could fall back to the key and this doesn't cause any problems. However, the method is cumbersome when a translation changes frequently, because all the files need to be updated. Also for longer texts these keys become very large. This is solved by using keys like ENTER_EMAIL, but the phrasing is completely out of the context. The list of abstract translation keys would be huge, you need meta data for all the keys explaining their usage and collisions can occur much easier.

是两全其美还是第三种方法?您如何在应用程序中使用翻译键?在我们的情况下,这是一个基于php的Web应用程序,但我认为上述问题足以泛泛地讨论i18n.

Is there a best of both worlds or a third method? How do you use translation keys in your application? In our case it is a php-based webapplication, but I think above problem is generic enough to talk about i18n in general.

推荐答案

这是iOS/OSX开发人员也面临的一个问题.对于他们来说,甚至还有一个称为genstrings标准工具假定使用方法1.但是,Apple开发人员当然不必使用此工具-我不需要.

This is a question that is also faced by iOS/OSX developers. And for them there is even a standard tool called genstrings which assumes method 1. But of course Apple developers don't have to use this tool--I don't.

虽然通过方法1获得的安全网很好(即,如果您以某种方式忘记对字符串进行本地化,则可以显示密钥),但它有一个弊端,那就是它可能导致密钥冲突.有时由于语法规则或上下文差异,需要以两种不同的方式来定位一条相同的显示文本.例如,"E-mail"的法语翻译如果是对话框标题,则是"E-mail";如果是按钮,则是"Envoyer un e-mail"(法语),"E-mail"只是一个名词,不能用作动词,与英语中既是名词又是动词的英语不同).使用方法2,您可以使用EMAIL_TITLE和EMAIL_BUTTON键来解决此问题,此外,这可以为翻译者提供提示,以帮助他们正确进行翻译.

While the safety net that you get with method 1 is nice (i.e you can display the key if you somehow forgot to localize a string) it has the downside that it can lead to conflicting keys. Sometimes one identical piece of display text needs to be localized in two different ways, due to grammar rules or differences in context. For instance the French translation for "E-mail" would be "E-mail" if it's a dialog title and "Envoyer un e-mail" if it's a button (in French the word "E-mail" is only a noun and can't be used as a verb, unlike in English where it's both a noun and a verb). With method 2 you could have keys EMAIL_TITLE and EMAIL_BUTTON to solve this issue, and as a bonus this would give a hint to translators to help them translate correctly.

方法2的另一个优点是,您可以更改英文文本,而不必担心会更新英文以及您所有本地化版本中的密钥.

One more advantage of method 2 is that you can change the English text without having to worry about updating the key in English and in all your localizations.

所以我推荐方法2!

这篇关于翻译文件中键值的最佳做法的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆