本頁將詳細說明 Google Season of Docs 接受的技術文件寫作專案。
專案摘要
- 開放原始碼組織：
- 全球 Wordnet 關聯
- 技術撰稿人：
- Yoyo Wu
- 專案名稱：
- Wordnet 結構
- 專案長度：
- 標準長度 (3 個月)
Project description
這項專案的緣由
身為專攻語言學的技術作家，我很高興看到這類專案，因為它以統一的語意概念架構連結不同語言，並已應用於 Google 翻譯等實際業務。我想為這個專案的文件做出貢獻，讓內容更貼近使用者需求。
問題
在瀏覽原始文件的內容後，認為我們可以解決下列問題，藉此改善檔案：缺少開頭的「總覽」一節，介紹 Wordnet 的基本概念，這對新手很有幫助。雖然 WordNet 中的所有關係都會以統一的範本推出，但某些關係缺少必要資訊，例如示例和測試，這些資訊會分散在 Princeton WordNet 網頁、EuroWordnet 一般規範和其他資源中。「簡短定義」和「定義」、「簡短範例」和「範例」缺乏統一的句子模式，因為「簡短定義」和「簡短範例」是使用者滑鼠游標懸停在特定關係時的說明文字，「定義」和「範例」則主要用於介紹關係，因此應採用統一的句子模式，但與「簡短定義」和「簡短範例」的模式不同。測試來自 EWN，但條件區塊應置於主要測試內容之前，因為使用者會先查看條件，判斷自己的語言資料是否符合條件，然後再進行測試。此外，測試內文含有大量語言縮寫，也不容易理解。評論部分的內容多元，有時會強調定義的特定要點，有時則會說明專案相關詳細資料。我認為我們應該為這個部分設定標準，將特定專案的資訊移至「專案專屬名稱」部分，這樣對使用者來說會更方便。「專案專屬名稱」部分會列出所有專案中的關聯名稱，由於發生不相符錯誤，因此需要檢查這個部分。需要將術語彙對照表直接連結至文件，並新增所有新手可能不熟悉的縮寫和術語。
指南規範
在起草文件之前，我也想與專案團隊討論以下兩個主題，我們會根據討論結果制定整個專案的一般規範。
關於目標對象 以下是我親身經歷的實際例子：雖然我是語言學系學生，但第一次看到原始文件時，我不知道「synset」的意思，是從普林斯頓 Wordnet 網頁上才知道 synset 的意思。
首先，我們必須瞭解潛在目標對象的知識結構。如果我們無法確定所有目標對像都具備相關知識，則至少需要新增「總覽」專區，並連結字詞詞彙和其他相關資源，在 Wordnet 和相關專案上引導他們。在整個文件製作過程中，我們應始終將這項假設納入考量，
關於文件的功能 據我所知，詞彙網結構文件的目標是協助使用者熟悉詞彙網中的所有關係類型，使用者可以根據提供的資訊將字詞分組為這些關係。不過，原始文件看起來比較像學術論文摘要。如果說明文件的用途是學術參考，那麼這麼做是可以接受的，但如果說明文件的用途是引導使用者，那麼就必須在學術和實用性之間取得平衡。
優點
我可以協助翻譯中文版文件。我有將語言學論文從英文翻譯成中文的經驗。 我可以協助設定文件格式，瞭解 HTML/CSS 的基本知識，並可協助改善文件網頁的外觀，例如新增側邊導覽列。如果流程圖有助於使用者進一步瞭解關係，我可以協助您使用 Visio 或 Mermaid 繪製一些流程圖。
里程碑 / 時間 / 目標
- 第 1 週：與專案團隊討論並確定目標、工作流程和工作計畫。
- 第 2 週：完成文件大綱，並撰寫「總覽」部分。
- 第 3 週至第 4 週：撰寫「構成性關係」部分。
- 第 5 週至第 6 週：編寫「其他」和「網域」關係部分。
- 第 7 週至第 8 週：編寫角色關係部分。
- 第 9 週：撰寫剩下的三個關係，並更新詞彙表。
- 第 10 週：視需要翻譯中文版本。
- 第 11 週：修訂文件格式。
- 第 12 週：進行最後檢查並總結本專案。