將手動翻譯轉換為 po4a¶

po4a-gettextize將嘗試提取任何提供的翻譯檔案的內容，並將此內容用作生成 PO 檔案中的 msgstr。請注意，此過程非常脆弱：翻譯檔案的第 N 字串應該是原始第 N 字串的翻譯。除非兩個檔案共享完全相同的結構，否則這自然不起作用。

在內部，每個 po4a 解析器報告每個提取字串的語法型別。這是在 gettexted 期間檢測到非同步化的。 例如，如果檔案具有以下結構，則翻譯中的第 4 個字串（型別為"章節"）不太可能是原始第 4 個字串（型別為"段落"）的翻譯。更有可能是將新段落新增到原稿中，或者兩個原始段落在翻譯中合併在一起。

    Original         Translation
  chapter            chapter
    paragraph          paragraph
    paragraph          paragraph
    paragraph        chapter
  chapter              paragraph
    paragraph          paragraph

po4a-gettextize詳細診斷任何檢測到的結構不同步。發生這種情況時，應手動編輯檔案（這可能需要您具有目標語言的一些概念）。您必須在其中一個文件中新增假段落或刪除某些內容（或兩者）以修復所報告的差異，直到兩個文件的結構完全匹配。下一節將介紹一些技巧。

即使成功處理文件，未檢測到的差異和靜默錯誤仍然是可能的。這就是為什麼 po4a -gettextize 自動關聯的任何翻譯被標記為<fuzzy>需要人工檢查。必須檢查每個檢索到的 msgstr 實際上是關聯的 msgid 的轉換，而不是之前或之後的字串。

如您瞭解，此處的關鍵是翻譯的文件和原始文件中具有完全相同的結構。最好的方法就是對用於翻譯的 master.doc 的確切版本進行文字化，並且僅在 gettextd 成功後針對最新的主檔案更新 PO 檔案。

如果您足夠幸運，在檔案結構中擁有完美的匹配，則構建正確的 PO 檔案需要幾秒鐘。否則，你很快就會明白為什麼這個過程有這樣一個醜陋的名稱:)但請記住，這個咕咕的工作是代價，以獲得舒適的po4a之後。轉換後，主文件和翻譯之間的同步將始終完全自動。

即使事情出錯，文字化通常仍然比再次翻譯所有內容更快。儘管許多文件的結構已不同步，但我能夠在一天內對整個 Perl 文件的現有法語翻譯進行文字化。這是超過兩兆字節的原始文字（200 萬個字元）：從頭開始翻譯需要幾個月的工作。

獲取文字化過程的提示和技巧¶

檢測到非同步一點後，gettextization 將停止。從理論上講，在文件中的後期，使用與 diff(1) 實用程式相同的演算法，可以重新同步獲取文字化。但是，手動干預仍是必需的，以手動匹配無法自動匹配的元素，這解釋了為什麼未實現自動重新同步（尚未實現？）。

當這種情況發生時，整個遊戲歸結到這些該死的檔案的結構再次透過手動編輯對齊。po4a-gettextize關於它發生時哪裡出了問題相當冗長。它報告不匹配的字串、它們在文字中的位置以及每個字串的型別。此外，到目前為止生成的 PO 檔案將轉儲為 gettextization.failed.po ，以便進一步檢查。

下面是一些其他技巧，以幫助您在這個乏味的過程：

• 刪除翻譯的所有額外內容，例如為譯員提供學分的部分。以後可以使用附錄將它們重新新增到 po4a 中（請參閱 po4a(7)）。
• 如果需要編輯檔案以對齊其結構，則應儘可能選擇編輯翻譯。實際上，如果對原始版本的更改過於具有侵入性，則新舊版本在 PO 更新期間將不匹配，並且相應的翻譯無論如何都會轉儲。但是，如果需要，不要猶豫，也編輯原始文件：重要的是獲得第一個 PO 檔案開始。
• 不要猶豫，殺死任何原始內容，將不存在在翻譯版本。將 PO 檔案與文件同步時，以後將自動重新引入此內容。
• 你或許應該告訴原作者翻譯中似乎合理的任何結構變化。原始文件中的問題應報告給作者。在翻譯中修復它們只會為社群的一部分修復它們。此外，使用 po4a 時不可能;)
• 有時，段落內容確實匹配，但不匹配其型別。修復它與格式相當相關。在 POD 和人中，它通常來自這樣一個事實，即其中一個包含以空白開頭的行，而另一個則不包含。 在這些格式中，此類段落不能換行，因此成為不同的型別。只需刪除空間，您就沒事了。它也可能在 XML 中的標記名稱中出現拼寫錯誤。

  同樣，當分隔線包含某些空格時，或者當 =item 行和項內容之間沒有空行時，兩個段落可能會合併到 POD 中。

• 有時，取消同步訊息似乎很奇怪，因為翻譯附加到錯誤的原始段落。這是流程早期未檢測到問題的跡象。透過檢查 gettextization.failed.po 來搜尋實際的取消同步點，並修復問題的實際所在。
• In some case, po4a adds a space at the end of either the original or the translated strings. This is because every string must be deduplicated during the gettextize process. Imagine that a string appearing several times unmodified in the original, but is translated in differing way, or that different paragraphs are translated in the exact same way.

  Without deduplication, such case would break the gettexization algorithm, as it is a simple one to one pairing between the msgids of both the master and the localized files. Since one of the PO files would miss an entry (that would be reported as duplicate, with two references), the pairing would fail.

  Since po4a uses the entry type ("title" or "plain paragraph", etc) to detect whether the parsing streams got desynchronized, similar issues could occur if two identical entries (same content but differing type) of the master file are translated in the exact same way in the localized file. po4a would detect a fake desyncronization in such case.

  In most cases, the extra space added by po4a to deduplicate the strings has no impact on the formatting. Strings are fuzzied anyway, and msgmerge will probably match the strings accordingly afterward.

• 最後一點，如果 PO 檔案的第一次同步需要很長時間，不要太驚訝。這是因為由 gettextization 生成的 PO 檔案的 msgid 與從最近主檔案生成的 POT 檔案的任何元素不完全匹配。這強制使用昂貴的字串接近演算法搜尋最近的一個。

  例如，Perl 文件的法語翻譯（5.5 MB PO 檔案）的第一個 po4a-updatepo 花了大約 48 小時（是的，兩天），而後續的 po4a-updatepo 檔案只需十幾秒。