文字與寫作 指南
Title Case vs Sentence case 差在哪？
大小寫轉換很容易，真正困難的是：你的用途到底採哪一套風格？
更新日期:
兩種最常見的英文標題風格：
Title Case
How to Write Better Online Content
Sentence case
How to write better online content
差異不是哪一個「比較正確」。
而是：
Style guide 不同。
Sentence case
基本概念：
- 第一個字大寫
- proper nouns 保留大寫
- 其他通常小寫
例如：
How to use Microsoft Excel for research
其中 Microsoft Excel 是專有名稱，所以仍保留。
Microsoft Style Guide 目前多數標題與 heading 偏好：
sentence-style capitalization。
Title Case
基本概念：
重要詞首字母大寫。
但麻煩在：
「重要詞」的規則沒有完全全球統一。
例如：
- articles
- prepositions
- coordinating conjunctions
- infinitive
to - phrasal verbs
不同：
- Chicago
- APA
- AP
- MLA
可能有不同細節。
所以一個 generic converter 不可能同時自動完全符合所有手冊。
FunnyTools Case Converter 的定位
目前 FunnyTools 可以把英文轉成：
- Title Case
- Sentence case
但工具頁本身也明確提醒：
轉換後仍需人工檢查冠詞、介系詞、連字號詞、品牌與程式名稱。
這是正確定位。
什麼情況選 Sentence case？
常見：
- 產品 UI
- Web headings
- Help center
- Technical documentation
優點：
- 視覺比較自然
- 本地化較簡單
- 不需要判斷每個小詞
但最終仍看品牌 style guide。
什麼情況選 Title Case？
常見：
- 書名
- 正式作品名稱
- 部分論文／引用格式
- 品牌風格
- 傳統 headline
但一定要先知道：
你遵循哪一本 style manual。
ALL CAPS 呢？
THIS IS A TITLE
適合：
- 少數 UI label
- 特定視覺設計
不適合把整段文案都拿來強調。
可讀性與 accessibility 通常都較差。
不能亂轉的字
Brand
- iPhone
- YouTube
- eBay
不能因 generic rule 變成：
- Iphone
- Youtube
- Ebay
Programming
- JavaScript
- macOS
- OpenAI API
也需要人工確認。
Acronym
- HTML
- GPA
不能變成：
- Html
- Gpa
如果情境要求保留正式縮寫。
實際流程
- 先確認 style guide。
- 用 Case Converter 做第一輪。
- 檢查：
- proper nouns
- brands
- acronyms
- short words
- hyphenated terms
- 和文件其他標題保持一致。
結論
Case Converter 最有價值的是：
快速建立一致起點。
而不是：
取代 editorial style guide。
工具
不能自動化的例外清單
大小寫轉換前應先找出品牌、產品、專有名詞、縮寫和程式識別字。像 API、URL、JSON、iOS 或產品自訂拼法，不能依一般英文規則任意改動。若標題含冒號、斜線或連字號，先確認 style guide 對分段的規則，再逐段轉換。完成後用搜尋比對關鍵名稱，並讓熟悉內容的人做一次人工校對。自動化適合處理大量一致的普通句子，但對少量重要標題，保留原文和人工審核通常更可靠。
實際編輯時的決策流程
先判斷文字的用途，再選 case。文章標題、按鈕與導覽通常需要一致的 editorial style；一般句子、說明段落和錯誤訊息通常保留 sentence case；變數、檔名、API 欄位和 CSS class 則不能交給一般大小寫轉換器處理。轉換前先複製原文，並把品牌名稱、產品名稱、縮寫、URL、email 和程式碼標記為不可任意改寫的片段。
Title Case 也有不同規則：有的 style guide 會把短介系詞和冠詞改成小寫，有的出版系統則要求每個主要字都大寫。Sentence case 同樣可能要求第一個字、專有名詞和縮寫保留大寫。因此工具只能提供起點，不能取代指定出版單位的規範。完成轉換後，逐項檢查冒號後文字、連字號片語、品牌拼法與技術符號，再用目標頁面預覽確認沒有改壞連結或程式片段。
延伸： camelCase、snake_case、kebab-case
交付前的風格一致性檢查
把同一頁的主標題、副標題、按鈕、導覽和圖說放在一起比較，確認大小寫規則沒有因元件來源不同而混用。再抽查連接詞、短介系詞、冒號後文字、破折號和含數字的標題；不同 style guide 的細節可能不一樣，最重要的是同一個產品或文件集合採用一致規則。若頁面有多語言版本，不要把英文大小寫規則直接套到中文或其他語言。
轉換結果若會影響 URL、SEO title、分享卡片或程式測試快照，先檢查這些介面是否依賴原始字串。建立少量固定案例，涵蓋品牌、縮寫、API 名稱、連字號和引號，然後跑渲染或快照檢查。這能把文案風格調整與功能相容性分開，避免看似單純的大小寫修改造成連結或整合測試失效。
專案風格指南的落地方式
先為每個內容集合指定一個主要規則，例如產品介面採 Sentence case、正式報告採出版單位要求的 Title Case，並列出不受一般規則影響的品牌和縮寫。規則應附上正例與反例，尤其是冒號、問號、連字號、括號、數字和專有名詞，讓不同編輯能做出一致判斷。
批次更新時先挑少量頁面預覽，再檢查搜尋結果、分享卡片、瀏覽器標籤和可及性名稱。若內容來自 CMS 或翻譯檔，確認儲存 key 沒有被誤改；若標題是公開 API 的輸入，也要保留舊值或提供遷移說明。完成後把規則版本與人工抽查結果寫進交付紀錄，日後才能解釋差異。