Git 是幾乎所有開發者每天都會碰到的工具，但你可能很少想過：它的繁體中文翻譯是怎麼被維護的？
這場分享不會把重點放在「某個詞到底該怎麼翻」的語言學辯論。實際上，Git 繁體中文翻譯社群很小，真正困難的往往不是翻譯決策，而是更務實的問題：要怎麼讓人願意開始翻？要怎麼 review？要怎麼把大家的貢獻整理成符合 Git 上游慣例的提交？
Git l10n 有一套自己的運作方式。翻譯不是隨便一個人改完 .po 檔、送 PR 就結束；要注意提交到哪個 repo、對應的 commit 格式（Signed-off-by）、squash、寄送到 l10n 流程，以及最後如何進入 Git release。這些規則對熟悉 Git 的人來說都不一定直覺，更不用說只是想幫忙修一句中文的新貢獻者。
為了降低門檻，我們導入 Weblate，希望讓不熟悉 Git 流程的人也能直接在網頁上參與翻譯。但導入之後才發現，Weblate 產生 commit 的方式，和 git-l10n 對提交記錄的要求並不完全相容。於是，維護者必須在「讓貢獻變簡單」與「讓 upstream 可以接受」之間，設計出一套實際可運作的中間流程。
本議程會分享 Git 繁體中文翻譯團隊實際踩過的坑：最初是如何從簡體中文基礎建立繁體中文翻譯、如何吸引新貢獻者、如何 review 翻譯品質、如何處理 Weblate 產生的 commit、如何透過人工 squash、Co-Authored-By 與自動化腳本保留貢獻紀錄，最後再把整理好的成果送進 Git 的正式 l10n 流程。
這場議程也會分享，一個翻譯字串從 Weblate 被修改、被維護者 review、被整理成符合慣例的 commit，到最後進入 Git release，中間到底經過哪些關卡。也會談到，在人力有限的情況下，哪些事情值得自動化，哪些事情仍然需要人工判斷，以及維護者如何在貢獻者體驗與上游規範之間取得平衡。
如果你維護過開源專案、想建立翻譯流程、正在思考如何降低貢獻門檻，或只是好奇「一句中文翻譯要怎麼正式走進 Git」，這場議程會提供一個非常真實、很小但很完整的案例。
