2012-05-18 66 views
19

通常,翻譯方法採用鍵>值映射並使用鍵將其轉換爲值。現在我認識到兩種不同的方法來爲您的翻譯密鑰命名,而在我的團隊中,我們並沒有達成共識,似乎是最好的方法。翻譯文件中鍵值的最佳做法

方法1: 使用完整的英文單詞或句子:

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

方法2: 使用關鍵詞描述的情況:

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

我個人比較喜歡的方法#1,因爲它直接顯示消息的含義。如果翻譯不存在,您可以回到關鍵位置,這不會導致任何問題。但是,由於所有文件都需要更新,因此翻譯頻繁更改時該方法非常麻煩。對於更長的文本,這些鍵變得非常大。這可以通過使用諸如ENTER_EMAIL之類的鍵來解決,但措辭完全超出了上下文。抽象翻譯密鑰的列表將是巨大的,你需要所有密鑰的元數據來解釋它們的使用,並且碰撞可能會更容易發生。

是否有兩全其美或第三種方法?你如何在你的應用程序中使用翻譯鍵?在我們的例子中,它是一個基於php的web應用程序,但我認爲上面的問題通常足以說明i18n。

+0

有趣的問題。我傾向於支持#1,但在情況允許時進行混合。 –

+1

我更喜歡#2的要求,當然,總是有一個英文(或原始語言)條目。每條記錄還應包括上次更新時間的日期/時間,以指出已更改的消息以及需要更新的翻譯。另外,應該存儲記錄原始語言的記錄。 –

回答

18

這是iOS/OSX開發者也面臨的一個問題。對他們來說,甚至有一個standard tool called genstrings,它假設方法1。但當然,蘋果開發人員不必使用這個工具 - 我不知道。

雖然您使用方法1獲得的安全網很好(即,如果您忘記本地化字符串,則可以顯示該密鑰),但它的缺點是可能會導致衝突的密鑰。由於語法規則或上下文的差異,有時需要以兩種不同的方式來對同一段顯示文本進行本地化。例如,如果它是一個對話標題,那麼「電子郵件」的法語翻譯將是「電子郵件」,如果它是一個按鈕(「法語」,「電子郵件」只是一個名詞,而「電子郵件」不能用作動詞,不同於英語中它既是名詞又是動詞)。使用方法2,您可以使用EMAIL_TITLE和EMAIL_BUTTON鍵來解決這個問題,並且作爲獎勵,這將給翻譯人員提示,幫助他們正確翻譯。

方法2的另一個優點是您可以更改英文文本而無需擔心更新英文和所有本地化中的密鑰。

所以我推薦方法2!

+0

「EMAIL_TITLE」和「EMAIL_BUTTON」的例子是非常好的例子,但我認爲這不是一個現實的例子。作爲英國開發者,你不知道這個法國案例。因此,您首先編寫了「電子郵件」(#1)或「EMAIL」(#2)。然後你的法語翻譯回來的消息,他需要兩個鍵,所以你改變按鈕到'電子郵件(按鈕)'(#1)或'EMAIL_BUTTON'(#2)。這兩種方法的過程都是一樣的,最後你有碰撞,你需要解決這個問題。你對此有何想法? –

+1

開發人員需要了解一些國際化規則。他們不需要知道某種特定的語言,就是說,在這種情況下,不能期望在不同情況下可以重用一段文本(即使在英文中不存在問題)。因此,在開發應用程序時,當您爲「電子郵件」按鈕引入新字符串時,即使您看到已經有「電子郵件」但已經有不同的上下文,也會向字符串表中添加條目。 – Clafou

+0

請注意,對於許多平臺而言,這種非重用規則有助於以下事實:UI視圖已經本地化爲捆綁包,而且您不會編寫代碼來從字符串表中加載每段文本(所以您經常會獲得同一件的多個實例的英文文本來翻譯,但沒關係,因爲它們的上下文可能不同) – Clafou

1

爲什麼不使用兩個世界?我使用方法#1作爲短字符串,方法#2使用長字符串作爲完整句子。我不害怕在同一個文件中混用兩者。

例如,在下面的字符串文本可如果在一個新的應用程序版本的用戶體驗被修改改變:

"screen description" = "Tap the plus button to add a new item. Tap an item for more options or to edit its details."; 

所以這裏是有意義的應用方法#2。 然而,對於簡單的字符串就像下面這個例子中,方法#1是比較有用的:

"Preferences" = "Preferences"; 

一般來說,當人們試圖規範它經常出現的限制,以我的事情。就我個人而言,我更喜歡更多的「無政府主義」的方法,其中有幾種方法是有效的(不僅如在此方法#1與方法#2線程中,而且例如當一組開發人員針對編碼風格時)。