Update zh tw languages and fix some broken links

i18n/zh-tw/docusaurus-plugin-content-docs/current/contributing/guidelines-refactoring.md

@@ -6,35 +6,35 @@ aliases:
   - /zh-tw/guidelines-refactoring
 ---
 
-# 重构指南
+# 重構指南
 
 ## 背景
 
-自 2014 年 2 月 12 日编写了第一行代码以来，Gitea 已经发展成为一个庞大的项目。
-因此，代码库变得越来越大。代码库越大，维护就越困难。
-存在许多过时的机制，许多框架混合在一起，一些遗留代码可能会导致错误并阻碍新功能的开发。
-为了使代码库更易于维护，使 Gitea 变得更好，开发人员应牢记使用现代机制来重构旧代码。
+自 2014 年 2 月 12 日編寫了第一行程式碼以來，Gitea 已經發展成爲一個龐大的專案。
+因此，程式碼庫變得越來越大。程式碼庫越大，維護就越困難。
+存在許多過時的機制，許多框架混合在一起，一些遺留程式碼可能會導致錯誤並阻礙新功能的開發。
+爲了使程式碼庫更易於維護，使 Gitea 變得更好，開發人員應牢記使用現代機制來重構舊程式碼。
 
-本文档是关于重构代码库的指南集合。
+本文件是關於重構程式碼庫的指南集合。
 
-## 重构建议
+## 重構建議
 
-- 设计更多关于未来的内容，而不仅仅解决当前问题。
-- 减少模糊性，减少冲突，提高可维护性。
-- 描述重构，例如：
-  - 为什么需要重构。
-  - 如何解决旧问题。
-  - 重构的优点/缺点是什么。
-- 只做必要的更改，尽量保留旧逻辑。
-- 引入一些中间步骤，使重构更容易审查，完整的重构计划可以在几个 PR 中完成。
-- 如果存在分歧，应该请 TOC（技术监督委员会）参与决策。
-- 添加必要的测试以确保重构的正确性。
-- 非错误重构优先在里程碑的开始时进行，这样可以更容易地在发布之前发现问题。
+- 設計更多關於未來的內容，而不僅僅解決當前問題。
+- 減少模糊性，減少衝突，提高可維護性。
+- 描述重構，例如：
+  - 爲什麼需要重構。
+  - 如何解決舊問題。
+  - 重構的優點/缺點是什麼。
+- 只做必要的更改，儘量保留舊邏輯。
+- 引入一些中間步驟，使重構更容易審查，完整的重構計劃可以在幾個 PR 中完成。
+- 如果存在分歧，應該請 TOC（技術監督委員會）參與決策。
+- 添加必要的測試以確保重構的正確性。
+- 非錯誤重構優先在里程碑的開始時進行，這樣可以更容易地在發佈之前發現問題。
 
-## 审查和合并建议
+## 審查和合併建議
 
-- 重构的 PR 不应该长时间保持打开状态（通常为 7 天），应尽快进行审查。
-- 重构的 PR 应尽快合并，不应被其他 PR 阻塞。
-- 如果 TOC 没有异议，重构的 PR 可以在 7 天后由一名核心成员（非作者）批准后合并。
-- 如果最终结果良好，容忍一些不完美/临时的步骤。
-- 如果重构是必要的，容忍一些回归错误，并尽快修复错误。
+- 重構的 PR 不應該長時間保持打開狀態（通常爲 7 天），應儘快進行審查。
+- 重構的 PR 應儘快合併，不應被其他 PR 阻塞。
+- 如果 TOC 沒有異議，重構的 PR 可以在 7 天后由一名核心成員（非作者）批准後合併。
+- 如果最終結果良好，容忍一些不完美/臨時的步驟。
+- 如果重構是必要的，容忍一些迴歸錯誤，並儘快修復錯誤。