# iOSDC 議程翻譯心得

之前寫了篇 iPlayground 2025 的心得，
在後面的離題部分，正好寫到「不知怎麼就考到了 N2 」。

沒多久 Hokila 就說他開了個 side project ，是翻譯 [iOSDC](https://www.youtube.com/@iOSDCJapan) 的部分議程，問我有沒有興趣來幫忙。

雖然我又開始過度思考的老毛病，大型研討會欸，純日文欸，我會不會翻不好，會不會翻太慢來不及⋯⋯

不過想這麼多也沒用，反正就先試試看吧，不行再溝通。

### 工具
既然是 side project，那多嘗試新工具也是很正常的。
起動會議時 Hokila 介紹了一下他目前摸索出來的方式，
關鍵的就是 [Spokenly](https://spokenly.app) 這套工具，支援安裝多模型，進行語音辨識轉逐字稿的工具，還能直接給提示詞、調整關鍵參數，直接輸出 srt 字幕檔。

於是這條從起步就是魔王關的路，就變成新手村了。

剩下就是各人按照自己順手的方式進行，不時交換一下心得，各自持續改進流程。

> 😇好聽一點的講法：大家都是有獨立解決問題能力的 senior。
> 😈簡單粗暴的講法：[然後就讓大家自生自滅](https://hokilajan.medium.com/iosdc-翻譯組-14fa7e603fe8) by Holika
> 

## 總之，開始 🤡

所有檔案直接上 github 協作，一頓作業以後就推上去送 PR。
居然還有作 CI 驗證和 Gemini Bot 協助 review commit，幫助很大，完全的工程師作風，
我也藉此改進了幾次本機端的驗證流程。
隨著時間經過，看著 repo 裡各分支流動交會，自己也貢獻了一部分，蠻有成就感的。

### 工具選擇

大家的~~求生意志堅強~~ 工具選擇其實都不太相同，有人用 capcut（剪映），有人直接進專業剪輯軟體。

我這次的工作流程使用三套軟體處理：cursor、IINA、Aegisub。
- 時間軸調整使用開源的 [Aegisub](https://aegisub.org)。
（但時間軸對齊會有小誤差和自動寫入 UTF-8 BOM 的問題）
- 文字調整使用 [cursor](https://cursor.com/zh-Hant)，搭配 chatGPT 或 Claude Pro 做批次處理。
- 字幕品質驗證、人工過片用 [IINA 播放器](https://iina.io)。

Vincent 是用 [DaVinci Resolve](https://www.blackmagicdesign.com/products/davinciresolve)，或許之後有空可以跟 FCP 一起試試。
~~畢竟 Adobe Pr 實在太貴啦~~

我則是連非線性剪輯軟體都沒用到，所以解決方案其實比想像中多，
像 Vincent 甚至試作了專用工具，這表示流程上能最佳化的地方其實還很多。

## 開始動工🔨
我翻譯第一門講座「[給軟體工程師的作曲入門](https://www.youtube.com/watch?v=ENhCImNEHXE&t=1004s)」的時候，花了兩天才完成初稿與校對。
初次還是太習慣用人工處理，這樣太累了，也一定來不及。

之後隨著流程中出現各種錯誤、疏漏，
一邊修正、一邊考慮能否給 AI 代工和驗證，
就開始寫提示詞給 AI 處理，看過沒問題就納入流程。

### 語音轉逐字
- 來源越清晰、音質越好，提示詞越詳細，逐字稿就越準確。
講起來很多餘，但很重要。
- MP3 128k 和 320k 當然有差，要是無損音質辨識準確率差更多。
- 在前兩項盡量完備的前提下，Whisper v3 Large 模型的辨識準確度很驚人，體感上高達九成。
- 但是是在確定並指定好語言種類給模型，以及只有一些英文術語的情況下。
- 遇到像日英文混用的講座，辨識準確度可能會瞬間下降，必須分開處理。

### 日文字幕校正
接下來用 cursor 搭配 Claude Pro 對日文字幕檔作初次處理，像是設定字數條件，進行簡易斷句，
因為產出逐字稿時，會盡量要求與原話相同以方便比對，所以很多字幕都會超出顯示範圍。

接下來用 IINA 人工過片一次，開始初次校正，我也在這時候感覺到 Whisper v3 Large 的神奇：
- 日文辨識精度很高，有時候講者口乾舌燥會含滷蛋，幾乎都能準確辨識。
- 只要提示詞夠詳細，專有術語、人名正確率也有大約八成。
- 含設定、寫提示詞、開始翻譯，頂多十～二十分鐘結束，產生字幕檔。

我在人工過片的時候會作這些事情：
- 比對日文字幕與原音（辨識準確度超高，超級省事）
- 確認專有名詞如術語、人名的翻譯，修正後寫在日翻中提示詞，
像是指定譯名，哪些維持原文名稱、指定大小寫。
- 日文字幕過完以後，日翻中提示詞也差不多好了。

之後就開始著手日翻中。

### 日文轉中文
這部份當然最花時間。
AI 工具可能會搞錯慣用語、字元語系，所以條件要明確。
首先是格式驗證，例如：
- 確保字幕頭尾沒有標點符號
- 指定字元語系
- 標注英文術語時的括號要半形，中文則是全形
- 中文夾雜英文、數字時，前後增加半形空格
- 被提醒後才知道 srt 有命名規則，必須要 zh 或 zh_TW

這些用 Vibe coding 叫 Claude code 做，很快就能產出修改與驗證工具，卻能大量節省時間與確保品質，而我一開始沒想到。

> 以後事前可以先了解有沒有什麼既定規格或流程驗證點，
> 先把這些規則叫 AI 做成工具，事半功倍。

### 人工處理部分
再來是 AI 難以替代的部分，花更多時間和 token 應該能做到一定程度，
就像是 82 法則的那 20%，能作，但成本偏高。

**首先是斷句。**
初期只用最簡易的字數判定作檢測，不要超出畫面就好，所以可讀性差，
就算叫 AI 批次解讀後斷句，還是很耗 token，成果也不夠穩定。
所以這部份還是人工處理為主。

**再來是要與斷句一起考慮的通順度問題。**
這部份應該就會是技術翻譯類的人力部分，在這裡就需要一點知識儲備，也要查資料並理解講者的意思。

講座上的投影片是日文，講者也不一定會特別提及，如果只照講者原話翻譯，很容易缺失上下文脈絡，造成理解困難。

於是在重複看講座的過程中，同時也開始吸收知識了，是很充實的過程，
同時還能作三件事：日文聽解、語意判斷、中文字幕比對。

**最後是字幕銜接。**
AI 翻出來的字幕越接近原音時，就會出現過於零碎的狀況。
例如出現「我認為，我認為是這樣的」，
或是「有沒有遇到」、「有沒有遇到什麼很困難的地方」的重複狀況。
「耗電量是差不多，我是這樣認為的」的句型倒裝狀況。
要同時考量上下文、中文與日文的句型結構，
進而整合零碎字幕或調整字幕切換的銜接通順度，這部份 AI 還是不太行。

另外某些術語名稱也需要在地化考量，最明顯的例子是：
- 愛德蒙·哈雷 (Edmond Halley)
- 愛德蒙·哈雷（哈雷彗星發現者）

後者當然能更快速被中文圈觀眾理解。

在幾次校正的過程中，一邊查資料、確認史料、吸收知識，
一邊讓字幕更通順，更容易被觀眾看懂，其實意外的有收穫。

### 聊聊我接觸到的講座

**先給[整張播放清單](https://www.youtube.com/@iOSDCtranslate)**，大家辛苦了⭐️

「[邊做邊學 WebP 入門](https://www.youtube.com/watch?v=IqsRLDzUBuE)」
在校對時，完全沒想過我得因此去了解 RIFF 格式的結構定義、二元樹與霍夫曼編碼，
於是一路校對完也大致理解講者在教什麼了，真的有硬，也能體會到講者的用心。

這場講座的現場問答環節鴉雀無聲，沒人提問，大多表示知識量密集。
也就是說，光看一次無法完全了解。

這種底層知識都需要額外花時間反覆理解、確認，而且照講者所說，
WebP 官方文件跟天書差不多，範例就是一大坨 code 丟給你。

現在這些成果可以反覆觀看到懂為止，彰顯了翻譯影片的價值。
雖然跟專業譯者比起來還差得遠，但我真的學到了點東西。

「[Swift Build 微導覽——建構 Swift 新生態系的關鍵技術](https://www.youtube.com/watch?v=Jzzx2-rltEI)」
這門講座也算偏硬。
就是講解大多數開發者最頭痛的建構系統 (Build system)。
主要講述 Build system 的基礎結構與流程，與解釋那些在編譯錯誤時看到有陰影的名詞，
像是 ld、Linker、Symbol。

再來是講解官方開源社群即將推出的 Swift Build 會統一 iOS 建構系統，
之後能在 Linux 編譯，或是編譯 Android app 也是有可能實現的事情。

「[軟體工程師的作曲入門](https://www.youtube.com/watch?v=ENhCImNEHXE&t=1007s)」
事後才知道這門講座好像是迴響前幾名的大熱門，當時正巧在讀基礎樂理，
覺得「如果能互相印證會很有趣」就選了，感謝其他成員願意讓我翻譯這門講座。

如果喜歡日系流行音樂或經典金曲，會想知道怎麼做出好聽的歌，
而且那些熱門歌都有某種規律和公式可遵循、套用，那很推薦這門講座。

最後講者直接現場放了[自製的 iOS 開發者職業傷害之歌](https://youtu.be/ENhCImNEHXE?t=1005)，應該引起很多共鳴😂

>有興趣進一步了解和弦進行的話
>延伸閱讀：「[檸檬卷的 J POP 分析系列](https://www.youtube.com/playlist?list=PL9WvwTIAywaARnMeTMPqJjYOYrCSnM47g)」

「[來寫一個列車行程追蹤演算法](https://www.youtube.com/watch?v=BcpuweC7F1Y)」
講者是美國人，努力用初級日文講完整場，
他做了五支 app ，自己去搭電車，收集各種定位資料，
自幹一個簡易的電車行程演算法出來，然後做成電車行程提示工具
可以在 iPhone 動態島上提示列車動態，不用一直切換 App。

一般提到演算法，大多人會想到一堆奇怪數字、圖表、Leetcode 地獄。
他用比較和善的方式說明「演算法也是不斷累積錯誤，一步步修正結果的評分系統」，
講者如何將日本鐵路資料結構化到能做成演算法的思路過程很有趣。

「[探索時間與定位的奧秘——從大航海時代到近未來科技](https://www.youtube.com/watch?v=Pr7ay57G7zQ)」
與 iOS 開發完全無關，但是很有趣的歷史講古。
GPS 導航現在就像是吃飯喝水一樣自然的存在，
好像它一直都在，但其實只存在這十多年，是很新的技術。
在那之前，是幾百年無盡的卡關、海上事故和人性利益衝突。
如果正好不想看技術，那推薦這門講座。

## 總結
回頭看了一下 git commit，大約 10/28 第一次 commit，11/13 在 Youtube 公開。

不到三週的時間，完成翻譯、校對協作，並公開了 14 門日文 iOS 技術講座。

雖然超過了 Hokila 預估的兩週，但以初次接觸翻譯的人，
又是倉促召集的六人小隊來說，我覺得算是很驚人的時間了。

再想到傳統發包翻譯模式，幾年後翻譯行業也出現初階人力斷層，應該也不意外。
~~軟體業：First Time?~~

不過人工處理的時間，還是比起預期的要長很多。
雖然在短短的兩週多，單一影片的處理時間，
從兩天變成約 10 小時能完成一門講座的翻譯＋初次校對，
但仍然覺得有很多可以整理好，嘗試轉由 AI 代勞的部分。

在深夜一邊忍著頭痛（真的是久坐的頭痛），一邊嗑二元樹和霍夫曼編碼，
理出概述、翻譯，順利完成，這次的體驗能讓我記很久。

總之是一次很寶貴的經驗，感謝這次的成員。
- [@dannypang1113](https://x.com/dannypang1113)
- [@dsxsxsxs](https://x.com/dsxsxsxs)
- [@hokilaj](https://x.com/hokilaj)
- [@usagi_0__0](https://x.com/usagi_0__0)
- [@vince78718](https://x.com/vince78718)