持續在地化¶
有適當的基礎結構，因此您的翻譯緊隨開發。這樣，翻譯人員可以一直進行翻譯，而不必在釋出之前處理大量的新文字。
也參考
與 Weblate 整合 說明將開發流程與 Weblate 整合的基本方式。程式碼託管整合 列出常見程式碼託管網站各服務提供者的設定步驟。
這是過程：
開發人員進行變更並將其推送到版本控制系統儲存庫。
可以選擇更新翻譯檔案，請參閱 引入新字串。
Weblate 從版本控制系統儲存庫中拉取變更，解析翻譯檔案並更新其資料庫，見 更新儲存庫。
翻譯者使用 Weblate Web 介面提交翻譯，或上傳離線變更。
譯者完成後，Weblate 會將變更提交到本機儲存庫（請參閱 惰性提交）。
變更被推送回上游儲存庫（見 從 Weblate 推送變更）。
提示
上游程式碼託管網站並非必要。您可以搭配 本機檔案 使用 Weblate，這種方式只會使用 Weblate 內的儲存庫。
更新儲存庫¶
您應該設定某種方法來從來源更新後端儲存庫。
使用 通知掛勾 與大多數常見的程式碼託管服務整合，詳情請參閱 程式碼託管整合。您還必須啟用 啟用掛勾，這項功能才能運作。掛勾傳遞會更新存放庫 URL 與承載內容相符的組件；請參閱 比對 Webhook 目標。
在儲存庫管理中或使用 Weblate 的 REST API 或 Weblate 用戶端 來手動觸發更新
啟用
AUTO_UPDATE以自動更新您的 Weblate 執行個體上的所有組件執行
updategit（選擇專案，或--all來更新全部）
每當 Weblate 更新儲存庫時，更新後附加元件都將被觸發，請參閱 附加元件。
比對 Webhook 目標¶
Forge Webhook 會更新 原始碼儲存庫 與承載內容中的存放庫 URL 完全相符的組件（包括 Forge 回報的 HTTPS 或 SSH URL，以及尾端斜線等常見變體）。
通用程式碼代管平台 webhook 端點是相容性介面，一般存放庫通知傳遞不會經過密碼學驗證。包含安裝資料的舊版 GitHub App 通知是例外：通用 GitHub 端點會使用 GITHUB_LEGACY_APP_WEBHOOK_SECRET 驗證其簽章。存放庫比對不會套用專案或組件存取控制，因為 webhook 也必須更新私有專案及 受限組件。其 JSON 回應會包含存放庫、分支及已啟用掛勾的診斷計數。成功回應還會包含已更新組件的完整專案／組件代稱及絕對 API URL。因此，提供相符的存放庫 URL 可確認存放庫已註冊，並揭露這些識別資訊。
透過已驗證整合管理的組件不會納入通用 webhook 比對及其診斷計數。目前這適用於 GitHub (透過 Weblate GitHub App) VCS 後端。這些組件只會透過其專用、具權杖及簽章的 GitHub App webhook URL 接收通知。未來的已驗證整合也應採用相同的分離方式。
傳回的 API URL 不會授予組件存取權。網頁介面與 API 仍會執行一般存取控制，webhook 回應也不包含存放庫內容、翻譯或認證資訊。在可用的情況下，請優先使用 應用程式 webhook URL 等已驗證整合。
在 2026.9 版的變更: 已移除以主機及路徑尾碼作為備援的比對方式。如果更新停止，請將 原始碼儲存庫 調整為與 Forge Webhook 承載內容中的 URL 一致。
避免發生合併衝突¶
當同一檔案在 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 用戶端。
單獨操作的可用性取決於權限，設定的版本控制系統，是否設定了推送，是否所選物件可被鎖定。
從此頁面發起的儲存庫動作會排入背景處理佇列。對專案而言，Weblate 會在同一個工作中依序處理受影響的儲存庫，並顯示進度。重複發起相同動作會開啟現有工作；該工作完成前，無法對同一個儲存庫發起不同動作。
同步 和 重新掃描 儲存庫操作會依照上述方式排入背景處理佇列。個別翻譯才有獨立的 檔案管理 動作。這些動作會在網頁請求期間重寫該翻譯檔案並提交結果；不適用於專案或組件層級的操作。
讀取儲存庫內容的操作（例如更新、重設或重新掃描）也會讓 Weblate 中的翻譯檔案保持一致。處理完成後，新增或移除的翻譯檔案都會反映出來。詞彙表語言同步與清除的說明請參閱 語言檔案和同步。
動作 |
它做什麼 |
典型使用 |
|---|---|---|
提交 |
將儲存在 Weblate 中的未提交變更提交到本機儲存庫。 |
在其他地方進行儲存庫操作前，先提交 Weblate 的待處理變更。 |
推送 |
將提交的本機儲存庫變更推送到設定的上游。 |
當自動推送停用或延遲時向上遊傳送提交的譯文。 |
更新 |
取得上游變更，用組件已設定的 合併類型 整合它們並核對翻譯檔案。 |
用預設整合策略讓 Weblate 和上游同步。 |
以合併方式更新 |
擷取上游變更，並透過明確的合併操作進行整合。 |
覆蓋單一更新的預設合併樣式。 |
以變基方式更新 |
取得上游變更並在上游基礎上變基本機 Weblate 提交。 |
當歷史記錄相符工作流時保持歷史記錄線性。 |
用不含快進的合併進行更新 |
擷取上游變更，且即使可以快進，仍明確建立合併提交。 |
出於審計或分支管理理由保留合併提交。 |
鎖定 / 解鎖 |
阻止或允許譯者在 Weblate 中進行進一步變更。 |
在 Weblate 以外維護儲存庫時凍結翻譯變更。 |
重設並丟棄 |
重置 Weblate 的本機儲存庫到上游，丟棄未提交的 Weblate 變更並核對翻譯檔案。 |
當上遊應覆蓋本機 Weblate 儲存庫狀態時使用。 |
重設並重新套用 |
重置 Weblate 的本機儲存庫到上游，核對翻譯檔案並重新應用未提交的變更。見 重置並重新應用復原行為。 |
從有差異的歷史記錄復原，同時保留未提交的 Weblate 翻譯。 |
清理 |
從本機儲存庫簽出中移除未跟蹤的檔案和過時分支。 |
清理 Weblate 簽出中殘留檔案或過時儲存庫狀態。 |
同步 |
強制 Weblate 將所有已知的譯文寫回儲存庫檔案。 |
修復儲存庫檔案與資料庫狀態不同步的情況。 |
重新掃描 |
將來自本機儲存庫的翻譯檔案重新讀取到 Weblate 中並刪除檔案不再相符組件設定的翻譯。 |
在手動進行儲存庫操作或建立檔案後匯入檔案變更。 |
刪除重複項 |
從單一翻譯檔案中刪除辨識符號相同的重複字串。 |
修復 Weblate 回報的重複字串，也就是檔案中包含重複翻譯單元的情況。 |
清除未使用項目 |
從單一翻譯檔案移除基礎檔案中已不存在的字串。清理翻譯檔案 附加元件可以自動執行此操作。 |
在不安裝附加元件的情況下執行一次性清除。 |
移除陳舊項 |
從單一 PO 翻譯檔案中刪除陳舊字串。 |
在不啟用自動移除過時字串的情況下，執行一次性 PO 清除。 |
對 Git 儲存庫而言，兩種重設動作都只影響已設定的 儲存庫分支，不會重設或移除其他本機分支。清理 會刪除其他所有本機分支（包括尚未推送的提交），並移除未追蹤檔案，但不會刪除上游儲存庫中的分支。
若您以無關的歷史記錄取代上游分支，Weblate 切換至該分支時可能會失敗，因為它會沿用既有的本機分支，並嘗試合併或重定基。若重設時設定的是另一個分支，也無法修復未啟用的本機分支。例如，重設 master 不會變更舊的本機 dev 分支。
若受影響分支上的本機變更都不需要保留，請設定一個工作分支，在 儲存庫維護 中執行 清理，並等候作業完成。接著再切換至受影響的分支，Weblate 就會從上游重新建立該分支。若受影響的分支已經是目前設定的分支，請使用 重設並捨棄，以從上游取代其本機歷史記錄。
重置並重新應用復原行為¶
重置和重新應用 操作保留來自 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 設為 "full"，也會將遠端變更合併至工作副本。排程細節和其他更新模式請參閱 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 分享您的意見回饋。
一致性檢查¶
在字串不同時 不一致 會啟動檢查。您可以藉此來手動複查其差異，並選擇正確的翻譯。
自動翻譯¶
基於不同組件的自動翻譯，可以是跨組件同步翻譯的方式。可以或者手動觸發（請參閱 自動翻譯），或者使用附加元件（自動翻譯）在儲存庫更新時自動執行。