持續在地化¶
有適當的基礎結構,因此您的翻譯緊隨開發。這樣,翻譯人員可以一直進行翻譯,而不必在釋出之前處理大量的新文字。
也參考
與 Weblate 整合 說明將開發流程與 Weblate 整合的基本方式。程式碼託管整合 列出常見程式碼託管網站各服務提供者的設定步驟。
這是過程:
開發人員進行變更並將其推送到版本控制系統儲存庫。
可以選擇更新翻譯檔案,請參閱 引入新字串。
Weblate 從版本控制系統儲存庫中拉取變更,解析翻譯檔案並更新其資料庫,見 更新儲存庫。
翻譯者使用 Weblate Web 介面提交翻譯,或上傳離線變更。
譯者完成後,Weblate 會將變更提交到本機儲存庫(請參閱 惰性提交)。
變更被推送回上游儲存庫(見 從 Weblate 推送變更)。
提示
上游程式碼託管網站並非必要。您可以搭配 本機檔案 使用 Weblate,這種方式只會使用 Weblate 內的儲存庫。
更新儲存庫¶
您應該設定某種方法來從來源更新後端儲存庫。
在儲存庫管理中或使用 Weblate 的 REST API 或 Weblate 用戶端 來手動觸發更新
啟用
AUTO_UPDATE以自動更新您的 Weblate 執行個體上的所有元件執行
updategit(選擇專案,或--all來更新全部)
每當 Weblate 更新儲存庫時,更新後附加元件都將被觸發,請參閱 附加元件。
避免發生合併衝突¶
當同一檔案在 Weblate 內外都被變更時,就會出現來自 Weblate 的合併衝突。根據情況不同,有幾種方法可能會有幫助:
只變更 Weblate 中的翻譯檔案來避免合併衝突¶
對於單語檔案來說,避免 Weblate 之外的編輯是容易的——您可以在 Weblate 中新增新字串,並將檔案的整個編輯留在那裡。對於雙語檔案,通常存在某種資訊提取過程可以從原始碼產生可翻譯檔案。在一些情況下,這可以分成兩部分:
該提取產生範本(例如,gettext POT 是用 xgettext 產生的)。
進一步的過程將它合併入實際翻譯(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 拉取請求時的變更。
也參考
程式碼託管通知¶
GitHub、GitLab、Bitbucket、Pagure、Azure Repos、Gitea、Forgejo 及 Gitee 的特定服務提供者 App 與 Webhook 操作指南,請參閱 程式碼託管整合。
特定服務提供者的通知¶
保留這些舊版錨點是為了相容性。目前特定服務提供者的 App 與 Webhook 設定記載於 程式碼託管整合。
每晚自動更新儲存庫¶
Weblate 在後面合併變更時,每晚自動擷取遠端儲存庫來提高效能。可以選擇將其同樣轉換為進行每晚合併,通過允許 AUTO_UPDATE。
從 Weblate 推送變更¶
每個翻譯元件可以建立推送 URL(請參閱 儲存庫推送 URL),在那種情況下 Weblate 能夠將變更推送到遠端儲存庫。Weblate 還可以設定在每次提交時自動推送變更(請參閱 提交時一併推送)。
推送選項表格及特定服務提供者的拉取、合併和審查請求工作流程,請參閱 從 Weblate 推送變更。
受保護的分支¶
如果在受保護的分支上使用 Weblate,可以設定使用拉取請求,並執行翻譯的實際複查(對您不知道的語言可能有問題)。另一個方法是去掉對 Weblate 推送使用者的這個限制。
例如在 GitHub,這可以在儲存庫設定中進行:
與其他人互動¶
Weblate 通過使用它的 API,使與他人的交流更容易。
惰性提交¶
Weblate 會儘可能將同一作者的提交分組到一個提交中。這大大減少了提交的數量,但是如果您想同步版本控制系統儲存庫,例如合併,您可能需要明確地告訴它去做提交(這對 管理者 組是預設允許的,參閱 特權清單)。
如果多個元件分享相同的儲存庫,需要分別將他們全部鎖定:
某人另外變更了已經被變更的字串。
來自上游的結合發生了。
明確地請求了提交。
已請求檔案下載。
變更比 元件設定 上定義為 變更後提交的經過時間 的時間段更陳舊。
提示
每個元件都會建立提交。所以,如果您有很多元件,仍然會看到很多提交。在這種情況下,您可以使用 壓縮 Git 提交 附加元件。
如果您想更頻繁地提交變更而無需檢查存在時間,您可以設定一個排程任務來執行提交。方法是使用 Django 管理介面 中的 Periodic Tasks。首先,建立期望的 Interval(例如 120 秒)。接著,新增新的排程任務並選擇 weblate.trans.tasks.commit_pending 為 Task,{"hours": 0} 為 Keyword Arguments 和想要的間隔。
用指令稿處理儲存庫¶
自訂 Weblate 與儲存庫互動方式是 附加元件。關於如何通過附加元件執行外部指令稿的資訊,請參閱 從附加元件執行指令稿。
跨元件保持翻譯一致¶
一旦具有多個翻譯元件,您會想要確保相同的字串具有相同的翻譯。這可以在幾個層次達成。
翻譯宣傳¶
當 允許翻譯重用 處於啟用狀態時(這是預設的,請參閱 元件設定),在所有的元件中字串相符時,所有新的翻譯自動進行。在所有的元件中這樣的翻譯都適當地歸功於目前翻譯的使用者。
傳播前提條件:
所有元件必須位於單一專案中(僅連結元件是不夠的)。
開啟 允許翻譯重用 自動地為相符的字串重用譯文。
翻譯宣傳需要金鑰來相符單語言翻譯格式,因此在建立翻譯金鑰匙請記住。
字串在翻譯時會傳播,從儲存庫載入的字串不會傳播。
小訣竅
此功能目前存在一些限制,我們希望使其更加通用。請在 https://github.com/WeblateOrg/weblate/issues/3166 分享您的意見回饋。
一致性檢查¶
在字串不同時 不一致 會啟動檢查。您可以藉此來手動複查其差異,並選擇正確的翻譯。
自動翻譯¶
基於不同元件的自動翻譯,可以是跨元件同步翻譯的方式。可以或者手動觸發(請參閱 自動翻譯),或者使用附加元件(自動翻譯)在儲存庫更新時自動執行。