?本文反過來試圖強調(diào)手機APP開發(fā)國際化部分的主要問題，該部分一方面對最終用戶影響最大，另一方面對日常編碼影響很大——界面翻譯。盡管在本文中我們將分析如何在手機APP開發(fā)中實現(xiàn)國際化，但提供的大多數(shù)問題和可能的解決方案都可以手機APP于不同的開發(fā)環(huán)境。

按鍵命名

開發(fā)多語言手機APP時面臨的首要難題之一是為鍵選擇最合適的命名約定，這將代表要翻譯的文本。

有一種誘惑是要么保持鍵短，從而在需要參考翻譯信息時減少打字量，要么保持它們長而深的嵌套，從而具有明確定義的結(jié)構(gòu)。然而，做空通常不是一個好主意。盡管人們不必記住某些翻譯的長路徑，但它通常會導(dǎo)致看起來笨拙的長鍵名，這必須支持所需的區(qū)分。考慮以下稍微夸張的示例：

en-GB: dashboard_main_table_headers_first_name: First name

很容易被分割成

en-GB: dashboard: main_table_headers: first_name: First name

另一方面，過于嵌套的鍵可能會變得曲折且難以記憶，實際上許多級別可以很容易地省略而不會引入歧義，例如

en-GB: dashboard show: view: main_section: table: headers: first_name: First name

通過去除一些不必要的關(guān)卡并將其中的一些關(guān)卡合二為一，我們可以很容易地實現(xiàn)合理的解決方案。

en-GB: dashboard: show: table_headers: first_name: First name

關(guān)于密鑰創(chuàng)建要問的第二個問題是密鑰中實際包含的內(nèi)容。答案可能是：“只要是直觀的、明確的，并且可以讓您高效地查找和編寫翻譯”。這種結(jié)構(gòu)的示例可能如下所示：

例如

en-GB: customer: products: show: label_price: Price

最后一級的命名應(yīng)該是一致的，每次我們必須這樣做的時候不要過多地考慮如何命名特定的鍵。顯然，我們可能需要在翻譯中添加一些公共分支，以存儲在命名空間等之間共享的鍵。仍然具有良好定義的命名約定肯定會提高依賴于翻譯的繁重手機APP的效率。

翻譯文件結(jié)構(gòu)

在小型手機APP中，沒有必要準(zhǔn)備比每種語言一個更多的語言環(huán)境文件。盡管如此，隨著手機APP的增長，翻譯文件變得難以維護(hù)和管理——因此，經(jīng)過深思熟慮的語言環(huán)境文件樹可能是避免這種問題之王的一種方法。作為額外的獎勵，為同一手機APP的特定模塊分發(fā)翻譯包會更容易。

翻譯文件結(jié)構(gòu)的一些示例

Module name based ..yml ..yml #Shared

例如

invoicing admin.en-GB.yml admin.da-DK.yml admin.en-GB.yml admin.da-DK.yml

Namespace / Role name based ..yml ..yml #Shared

或者

admin invoicing.en-GB.yml invoicing.da-DK.yml invoicing.en-GB.yml invoicing.da-DK.yml

l ..yml ..yml #Shared

等等……您甚至可以將語言包放在不同的目錄中。在大多數(shù)情況下，對于大多數(shù)情況來說，一層嵌套感覺就足夠了。這取決于您選擇哪種方法，并且最適合給定的手機APP。

擺脫未使用的翻譯

持續(xù)的開發(fā)、升級、重構(gòu)等通常會導(dǎo)致翻譯文件中出現(xiàn)孤立的翻譯分支，除非非常注意保持一切潮流。無論如何，有時我們想檢查我們的翻譯文件是否有點太大。第一個想法是掃描源代碼中的鍵并將其與語言環(huán)境文件中的任何內(nèi)容進(jìn)行比較——之后，只需刪除代碼中未提及的所有鍵。這實際上有兩個缺點。

第一個是如果使用鍵繼承或者某些鍵不是從主手機APP代碼而是從某些庫等調(diào)用的。這顯然會導(dǎo)致刪除正在使用的鍵。第二種情況產(chǎn)生相同的效果，并且是由調(diào)用鍵時使用字符串插值引起的。

為了解決這個問題，我們可能會嘗試啟用密鑰記錄并讓手機APP運行（最好在生產(chǎn)環(huán)境中）。啟用此機制并運行完整的測試套件也會有很大幫助（取決于測試覆蓋率）。這種通過掃描源代碼增強的方法應(yīng)該為我們提供幾乎（如果不是全部）在手機APP中使用的完整密鑰，我們可以將其與龐大的翻譯文件進(jìn)行比較。

用于記錄翻譯鍵的簡單代碼

module I18n  module Registry    protected    def lookup(locale, key, scope = \[], options = {})      @log ||= Logger.new(File.join(Rails.root, 'log', 'i18n_registry.log'))      @log.info key      super    end  endendI18n::Backend::Simple.send :include, I18n::Registry

尋找缺失的翻譯

就像查找未使用的翻譯一樣，我們可以通過某種注冊表來增加源代碼掃描。這次我們可以將我們的解決方案基于 Rails I18n 提供的 exception_handler 鉤子

I18n.exception_handler = lambda do |exception, locale, key, options|  @log ||= Logger.new(File.join(Rails.root, 'log', 'missing_translations.log'))  case exception    when I18n::MissingTranslationData      @log.info key      options\[:rescue_format] == :html ? exception.html_message : exception.message    end  else    raise exception  endend

添加新翻譯

在開發(fā)過程中向翻譯文件添加翻譯是最沒有生產(chǎn)力的任務(wù)之一。在使用兩種或多種語言的手機APP中尤其如此。但是，使用 exception_handler 的強大功能，我們可以自動化這個密鑰創(chuàng)建過程。

當(dāng)?shù)谝淮握{(diào)用缺少的翻譯鍵時，這可能會在每種語言的翻譯文件中生成該鍵，根據(jù)鍵名自動創(chuàng)建翻譯等。我們甚至可以調(diào)用一些服務(wù)，它會自動將通用翻譯大致翻譯成不同的語言. 實際上提供了一個 gem 允許這樣做，所以不要在此處粘貼代碼，而是查看它的 github 存儲庫。

委派翻譯工作

除非團(tuán)隊有一些專門的翻譯，否則將翻譯委托給一些外部資源是很常見的，比如客戶、客戶的員工、外包翻譯等。在所有情況下，都必須開發(fā)某種翻譯過程的方法。

直接編輯文件 可能會有些尷尬且不易處理，尤其是對于不熟悉翻譯文件語法的翻譯人員。小的縮進(jìn)變化或一些特殊的符號移除甚至?xí)?dǎo)致手機APP無法啟動。這是最便宜的開始方式。

開發(fā) 專門的翻譯界面 可能很誘人，但需要深思熟慮。如果外部服務(wù)不能提供例如所需的訪問控制，則可能值得在內(nèi)部開發(fā)一些東西。在這種情況下 ，可以使用37signals 的 Tolk 作為基礎(chǔ)。瀏覽 github 以獲取其他共享解決方案，以免從頭開始重新發(fā)明輪子。

在大多數(shù)情況下，基于SaaS的解決方案 似乎是最好的解決方案——旨在與翻譯團(tuán)隊合作，可以大大減少問題的數(shù)量、花費的時間并促進(jìn)本地化手機APP的過程。對于翻譯 rails 手機APP，目前有兩個主要參與者：rails-only  LocaleApp 和更通用 的 WebTranslateIt。請查看它們的功能并確定最適合您的功能。

下一步

手機APP國際化的許多方面在本文中甚至都沒有涉及——它涵蓋了在手機APP開發(fā)期間處理翻譯的方面——然而，這是所有未來 i18n 相關(guān)任務(wù)的基礎(chǔ)。因此，選擇最適合您的方法，讓您的手機APP使用另一種語言。

• 上一篇 : 手機app開發(fā)人員有哪些？
• 下一篇 : 手機客戶端APP開發(fā)，手機應(yīng)用APP開發(fā)之前的考慮因素