持續在地化

有適當的基礎結構,因此您的翻譯緊隨開發。這樣,翻譯人員可以一直進行翻譯,而不必在釋出之前處理大量的新文字。

也參考

與 Weblate 整合 說明將開發流程與 Weblate 整合的基本方式。程式碼託管整合 列出常見程式碼託管網站各服務提供者的設定步驟。

這是過程:

  1. 開發人員進行變更並將其推送到版本控制系統儲存庫。

  2. 可以選擇更新翻譯檔案,請參閱 引入新字串

  3. Weblate 從版本控制系統儲存庫中拉取變更,解析翻譯檔案並更新其資料庫,見 更新儲存庫

  4. 翻譯者使用 Weblate Web 介面提交翻譯,或上傳離線變更。

  5. 譯者完成後,Weblate 會將變更提交到本機儲存庫(請參閱 惰性提交)。

  6. 變更被推送回上游儲存庫(見 從 Weblate 推送變更)。

digraph translations { graph [fontname = "sans-serif", fontsize=10, ranksep=0.6, newrank=true]; node [fontname = "sans-serif", fontsize=10, margin=0.15]; edge [fontname = "sans-serif", fontsize=10]; subgraph cluster_codehosting { rank=same; graph [color=lightgrey, label="Upstream code-hosting site", style=filled ]; "VCS repository" [shape=cylinder]; } subgraph cluster_weblate { rank=same; graph [color=lightgrey, label="Weblate", style=filled ]; repo [label="Weblate repository", shape=cylinder]; database [label=Database, shape=cylinder]; } "Developers" [shape=box, fillcolor="#144d3f", fontcolor=white, style=filled]; "Translators" [shape=box, fillcolor="#144d3f", fontcolor=white, style=filled]; "Developers" -> "VCS repository" [label=" 1. Push "]; "VCS repository" -> "VCS repository" [label=" 2. Updating translations ", style=dotted]; "VCS repository" -> repo [label=" 3. Pull "]; repo -> database [label=" 3. Parse translations "]; "database" -> repo [label=" 5. Commit changes "]; "Translators" -> "database" [label=" 4. Translate "]; "repo" -> "VCS repository" [label=" 6. Push repository "]; }

提示

上游程式碼託管網站並非必要。您可以搭配 本機檔案 使用 Weblate,這種方式只會使用 Weblate 內的儲存庫。

更新儲存庫

您應該設定某種方法來從來源更新後端儲存庫。

每當 Weblate 更新儲存庫時,更新後附加元件都將被觸發,請參閱 附加元件

避免發生合併衝突

當同一檔案在 Weblate 內外都被變更時,就會出現來自 Weblate 的合併衝突。根據情況不同,有幾種方法可能會有幫助:

只變更 Weblate 中的翻譯檔案來避免合併衝突

對於單語檔案來說,避免 Weblate 之外的編輯是容易的——您可以在 Weblate 中新增新字串,並將檔案的整個編輯留在那裡。對於雙語檔案,通常存在某種資訊提取過程可以從原始碼產生可翻譯檔案。在一些情況下,這可以分成兩部分:

  1. 該提取產生範本(例如,gettext POT 是用 xgettext 產生的)。

  2. 進一步的過程將它合併入實際翻譯(gettext PO 檔案用 msgmerge 更新)。

您可以在 Weblate 內執行第二步,它會確保所有未提交變更在此操作前被包含在內。

做外部變更時鎖定 Weblate 來避免合併衝突

您可以將 Weblate 整合到更新流程:先透過 Weblate 的 REST API 強制 Weblate 推送所有待處理變更並鎖定翻譯,再於 Weblate 外部更新檔案。

進行更新的指令碼看起來像這樣:

# Lock Weblate translation
wlc lock
# Push changes from Weblate to upstream repository
wlc push
# Pull changes from upstream repository to your local copy
git pull
# Update translation files, this example is for Django
./manage.py makemessages --keep-pot -a
git commit -m 'Locale updates' -- locale
# Push changes to upstream repository
git push
# Tell Weblate to pull changes (not needed if Weblate follows your repo
# automatically)
wlc pull
# Unlock translations
wlc unlock

如果多個元件分享相同的儲存庫,需要分別將他們全部鎖定:

wlc lock foo/bar
wlc lock foo/baz
wlc lock foo/baj

備註

範例使用了 Weblate 用戶端,這需要設定(API 金鑰)來遠端控制 Weblate。可以透過使用 HTTP 客戶端代替 Weblate 用戶端 來達成這一點,例如 curl,請參閱 Weblate 的 REST API

儲存庫維護

儲存庫維護 檢視顯示專案、元件或翻譯的儲存庫狀態,並讓特權使用者從使用者介面執行維護操作。

也可用 Weblate 的 REST API 觸發相同操作,或為受支援的子集觸發相同操作,Weblate 用戶端

單獨操作的可用性取決於權限,設定的 VCS,是否設定了推送,是否所選物件可被鎖定。

檔案管理 動作只能從個別翻譯的 儲存庫維護 使用。這些動作會重寫該翻譯檔案並提交結果;它們不是全專案或全元件的操作。

讀取儲存庫內容的操作(例如更新、重設或重新掃描)也會讓 Weblate 中的翻譯檔案保持一致。處理完成後,新增或移除的翻譯檔案都會反映出來。詞彙表語言同步與清除的說明請參閱 語言檔案和同步

動作

它做什麼

典型使用

提交

將儲存在 Weblate 中的未提交變更提交到本機儲存庫。

在其他地方進行儲存庫操作前,先提交 Weblate 的待處理變更。

推送

將提交的本機儲存庫變更推送到設定的上游。

當自動推送停用或延遲時向上遊傳送提交的譯文。

更新

取得上游變更,用元件已設定的 合併類型 整合它們並核對翻譯檔案。

用預設整合策略讓 Weblate 和上游同步。

以合併方式更新

擷取上游變更,並透過明確的合併操作進行整合。

覆蓋單一更新的預設合併樣式。

以變基方式更新

取得上游變更並在上游基礎上變基本機 Weblate 提交。

當歷史記錄相符工作流時保持歷史記錄線性。

用不含快進的合併進行更新

擷取上游變更,且即使可以快進,仍明確建立合併提交。

出於審計或分支管理理由保留合併提交。

鎖定 / 解鎖

阻止或允許譯者在 Weblate 中進行進一步變更。

在 Weblate 以外維護儲存庫時凍結翻譯變更。

重設並丟棄

重置 Weblate 的本機儲存庫到上游,丟棄未提交的 Weblate 變更並核對翻譯檔案。

當上遊應覆蓋本機 Weblate 儲存庫狀態時使用。

重設並重新套用

重置 Weblate 的本機儲存庫到上游,核對翻譯檔案並重新應用未提交的變更。見 重置並重新應用復原行為

從有差異的歷史記錄復原,同時保留未提交的 Weblate 翻譯。

清理

從本機儲存庫簽出中移除未跟蹤的檔案和過時分支。

清理 Weblate 簽出中殘留檔案或過時儲存庫狀態。

同步

強制 Weblate 將所有已知的譯文寫回儲存庫檔案。

修復儲存庫檔案與資料庫狀態不同步的情況。

重新掃描

將來自本機儲存庫的翻譯檔案重新讀取到 Weblate 中並刪除檔案不再相符元件設定的翻譯。

在手動進行儲存庫操作或建立檔案後匯入檔案變更。

刪除重複項

從單一翻譯檔案中刪除辨識符號相同的重複字串。

修復 Weblate 回報的重複字串,也就是檔案中包含重複翻譯單元的情況。

清除未使用項目

從單一翻譯檔案移除基礎檔案中已不存在的字串。清理翻譯檔案 附加元件可以自動執行此操作。

在不安裝附加元件的情況下執行一次性清除。

移除陳舊項

從單一 PO 翻譯檔案中刪除陳舊字串。

在不啟用自動移除過時字串的情況下,執行一次性 PO 清除。

重置並重新應用復原行為

重置和重新應用 操作保留來自 Weblate 的待提交變更,同時重置本機儲存庫狀態來相符上游。

該操作只有在重置後目標語言檔案仍存在或者 Weblate 能用有效的 新翻譯的範本 為該元件建立這些檔案時可以還原未提交的翻譯。

如果這些條件均不滿足,Weblate 會在其資料庫中保留未提交的變更並報告復原錯誤,而不是稍後因一般性的解析錯誤而出現故障。

聚焦 Git 操作避免合併衝突

即使 Weblate 是翻譯檔案變更的唯一來源,使用 壓縮 Git 提交 附加元件、將 合併類型 設為 Rebase,或在 Weblate 外部壓縮提交(例如合併拉取請求時),仍可能發生衝突。

此情形下,合併衝突的原因不同。例如,您在上游合併之前的 Weblate 提交後,Weblate 可能有新的本機提交。出現這種情況通常是因為合併操作不是自動進行的,變更要等待幾天或數週進行人工稽核。Git 有時會無法辨識上游的變更是否與 Weblate 相符,並拒絕執行變基操作。

以 squash 方式合併 Weblate 變更,會使這類問題更難復原。Squash 合併會建立新的提交,而非在上游歷程中保留個別 Weblate 提交。Weblate 的本機儲存庫仍有原始提交,但 Git 無法再證明上游已包含這些提交。如果衝突也是手動解決,檔案內容可能與兩個儲存庫都不同,因此即使拉取請求已在上游合併,Weblate 仍可能持續無法更新。

如果上游因 squash 合併而不再包含 Weblate 提交,僅更新儲存庫可能還不夠。請從 儲存庫維護 使用 重設並重新套用,在保留待處理翻譯的同時將 Weblate 重設至上游;請參閱 重置並重新應用復原行為。只有在上游應完全取代 Weblate 本機變更時,才使用 重設並捨棄

要解決此問題,您需要在合併拉取請求時儘量減少 Weblate 中的待處理變更,或者透過不擠壓變更來完全避免衝突。

這裡有幾個避免這一問題的選項:

  • 別對 Weblate 變更使用 壓縮 Git 提交 或擠壓合併。擠壓操作是 Git 為何在合併後不再辨識變更的原因。

  • 在 Weblate 外部解決衝突時,請使用一般合併提交來合併 Weblate 提交,並將結果推送至上游。請勿以 squash 方式合併用於解決衝突的拉取請求。

  • 在合併前讓 Weblate 提交未提交變更。這會更新拉取請求的所有變更,且兩個儲存庫會處於同步狀態。

  • 使用 Weblate 中的審閱功能(見 翻譯工作流程),這樣您可以在 CI 透過後自動合併 GitHub 拉取請求。

  • 在 Weblate 中使用鎖定避免在稽核 GitHub 拉取請求時的變更。

也參考

Weblate 用戶端

程式碼託管通知

GitHub、GitLab、Bitbucket、Pagure、Azure Repos、Gitea、Forgejo 及 Gitee 的特定服務提供者 App 與 Webhook 操作指南,請參閱 程式碼託管整合

特定服務提供者的通知

保留這些舊版錨點是為了相容性。目前特定服務提供者的 App 與 Webhook 設定記載於 程式碼託管整合

每晚自動更新儲存庫

Weblate 在後面合併變更時,每晚自動擷取遠端儲存庫來提高效能。可以選擇將其同樣轉換為進行每晚合併,通過允許 AUTO_UPDATE

從 Weblate 推送變更

每個翻譯元件可以建立推送 URL(請參閱 儲存庫推送 URL),在那種情況下 Weblate 能夠將變更推送到遠端儲存庫。Weblate 還可以設定在每次提交時自動推送變更(請參閱 提交時一併推送)。

推送選項表格及特定服務提供者的拉取、合併和審查請求工作流程,請參閱 從 Weblate 推送變更

也參考

請參閱 存取儲存庫 來設定 SSH 金鑰,和 惰性提交 獲得關於 Weblate 決定提交變更的資訊。

受保護的分支

如果在受保護的分支上使用 Weblate,可以設定使用拉取請求,並執行翻譯的實際複查(對您不知道的語言可能有問題)。另一個方法是去掉對 Weblate 推送使用者的這個限制。

例如在 GitHub,這可以在儲存庫設定中進行:

../_images/github-protected.png

與其他人互動

Weblate 通過使用它的 API,使與他人的交流更容易。

惰性提交

Weblate 會儘可能將同一作者的提交分組到一個提交中。這大大減少了提交的數量,但是如果您想同步版本控制系統儲存庫,例如合併,您可能需要明確地告訴它去做提交(這對 管理者 組是預設允許的,參閱 特權清單)。

如果多個元件分享相同的儲存庫,需要分別將他們全部鎖定:

  • 某人另外變更了已經被變更的字串。

  • 來自上游的結合發生了。

  • 明確地請求了提交。

  • 已請求檔案下載。

  • 變更比 元件設定 上定義為 變更後提交的經過時間 的時間段更陳舊。

提示

每個元件都會建立提交。所以,如果您有很多元件,仍然會看到很多提交。在這種情況下,您可以使用 壓縮 Git 提交 附加元件。

如果您想更頻繁地提交變更而無需檢查存在時間,您可以設定一個排程任務來執行提交。方法是使用 Django 管理介面 中的 Periodic Tasks。首先,建立期望的 Interval(例如 120 秒)。接著,新增新的排程任務並選擇 weblate.trans.tasks.commit_pendingTask{"hours": 0}Keyword Arguments 和想要的間隔。

用指令稿處理儲存庫

自訂 Weblate 與儲存庫互動方式是 附加元件。關於如何通過附加元件執行外部指令稿的資訊,請參閱 從附加元件執行指令稿

跨元件保持翻譯一致

一旦具有多個翻譯元件,您會想要確保相同的字串具有相同的翻譯。這可以在幾個層次達成。

翻譯宣傳

允許翻譯重用 處於啟用狀態時(這是預設的,請參閱 元件設定),在所有的元件中字串相符時,所有新的翻譯自動進行。在所有的元件中這樣的翻譯都適當地歸功於目前翻譯的使用者。

傳播前提條件:

  • 所有元件必須位於單一專案中(僅連結元件是不夠的)。

  • 開啟 允許翻譯重用 自動地為相符的字串重用譯文。

  • 翻譯宣傳需要金鑰來相符單語言翻譯格式,因此在建立翻譯金鑰匙請記住。

  • 字串在翻譯時會傳播,從儲存庫載入的字串不會傳播。

小訣竅

此功能目前存在一些限制,我們希望使其更加通用。請在 https://github.com/WeblateOrg/weblate/issues/3166 分享您的意見回饋。

一致性檢查

在字串不同時 不一致 會啟動檢查。您可以藉此來手動複查其差異,並選擇正確的翻譯。

自動翻譯

基於不同元件的自動翻譯,可以是跨元件同步翻譯的方式。可以或者手動觸發(請參閱 自動翻譯),或者使用附加元件(自動翻譯)在儲存庫更新時自動執行。