15321250321
010-86462584

手機APP開發國際化

2022-05-29

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

按鍵命名

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

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

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

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

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

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

例如

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

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

翻譯文件結構

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

翻譯文件結構的一些示例

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

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

擺脫未使用的翻譯

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

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

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

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

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

添加新翻譯

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

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

委派翻譯工作

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

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

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

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

下一步

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