社區文檔撰寫指南文檔翻譯進化史
開發文檔系統，最開始的時候，是為了解決翻譯文檔遇到的問題：
- 第一個問題、文檔認領；
- 第二個問題、翻譯審核；
- 第三個問題、譯者列表；
- 第四個問題、相關討論的知識沉淀。
先說第一個問題。那會兒翻譯都在 GitHub 上，文檔一般都有幾十篇上百篇文章，為防止重復翻譯一篇文章，每一次號召翻譯我們都是用最原始的方式，在評論下方認領，然后更新到文章內容里。每一次做這個操作的時候都覺得我自己好傻，無時不刻盯著評論區，有評論立刻通知用戶可否認領，并更新到文章中。費神費時，效率低下：
這種認領方式還有另外一個問題：很多用戶認領了一篇文章，但因文章內容太長，需要一兩周才翻譯完，甚至有些用戶認領以后，就消失了，你再也聯系不到他，后面還得重新召喚大家來翻譯別人落下的。翻譯的進度被無止境拖長。
這同時也暴露出來第二個問題，因為翻譯的文章太長，審閱工作變動非常繁重。反饋周期太長、并且不及時。例如譯者標點符號使用錯誤的問題，如果一開始翻譯一小段，審閱者發現后指導改正過來，后面譯者就可以在翻譯的過程中矯正過來，而不是在整篇文章翻譯完后，再一個一個費時地去修改。
針對這兩個問題，wangan 文檔系統開發出來文章分塊的模式。將幾千上萬字的文章切割成多個小分塊，每個分開兩三百個字，一般只需要 10~60 分鐘內即可翻譯完成。這樣減低了參與的門檻，工作之余有個十來分鐘的休息時間都能參與翻譯。
針對每個翻譯小分塊還提供認領機制，在認領指定時間內只有他能翻譯這個分塊，避免了沖突：
譯者列表，是辛苦付出的人兒，飲水思源，我們需要記錄下這些人。之前都是需要一個個去 GitHub 上收集，并對應到社區賬號上。有了翻譯系統，用戶是在本網站上，把數據調出來排個序即可：
最后說一下「第四個問題、相關討論的知識沉淀」，文檔里的文章，有時候晦澀難懂，如 Laravel 的 這篇文檔 。大家都在好奇這個所謂的「服務容器」是用來干啥的？因為文檔系統接入了社區問答，用戶可以底部提問：
接入了社區精華文章推薦，也方便讀者快速解惑：
翻譯系統和這個網站一樣，是一直 在不斷迭代著的。有很多有趣的功能，以后會慢慢添加進去，同時也歡迎大家建議和反饋哈。