前兩天有個做藥品注冊的朋友找我聊天，說她最近被eCTD翻譯文件的格式要求折磨得夠嗆。光是為了搞清楚文件命名的規矩，就查了好幾個小時的資料，結果越看越懵。她跟我說："這些要求怎么寫得跟天書似的，看完感覺懂了，下手做的時候又不知道從哪兒開始。"
我完全能理解她的感受。說實話，eCTD本身就不是一個簡單的東西，再加上翻譯文件這個環節，復雜度直接翻倍。但轉念一想，這些要求之所以存在，肯定有它的道理。藥品申報關系到人命馬虎不得，格式統一了，審評人員看起來才省力，出錯的風險也才更低。
既然朋友問了，我干脆把eCTD電子提交中翻譯文件的格式要求系統地整理一下。這篇文章不會照本宣科地把法規條文直接搬上來，而是用我自己的理解，把這些要求拆解開來，用人話講清楚。文章里提到的內容主要基于ICH和各國藥監部門的相關規定，實際操作的時候還是要以目標市場的具體要求為準。
在聊具體格式要求之前，我覺得有必要先說說eCTD到底是什么。eCTD的全稱是"Electronic Common Technical Document"，翻譯過來就是"電子通用技術文檔"。簡單理解，它就是一套用來規范藥品申報資料提交格式的國際標準。
以前各國都有自己的申報格式，藥企要向不同國家遞交資料的時候，往往需要把資料重新整理一遍，費時費力還容易出錯。eCTD的出現就是為了解決這個問題——只要按照統一的標準準備資料，就能同時滿足多個國家藥監部門的要求。
那翻譯文件和eCTD是什么關系呢？舉個例子，如果你的目標市場是日本或者韓國，申報資料必須用當地語言提交。這時候你就要把原來的英文資料翻譯成日語或者韓語，但翻譯完之后的內容不是隨便放進去就行的，它必須符合eCTD的格式規范。換句話說，翻譯只是第一步，保證翻譯內容以正確的格式集成到eCTD文檔結構中，才是真正麻煩的地方。
在說翻譯文件格式之前，得先弄清楚eCTD的整體結構。eCTD資料不是一堆文件簡單地堆在一起，而是按照一定的層級關系組織起來的。ICH把申報資料分成了五個模塊，每個模塊下面又有不同的章節。
具體來說，模塊一是地區行政信息，模塊二是CTD概要，模塊三是質量研究報告，模塊四是非臨床研究報告，模塊五是臨床研究報告。翻譯工作通常集中在模塊二到模塊五，因為這些模塊包含大量的技術內容，需要翻譯成目標語言。
每個模塊下面又細分成很多章節和子章節，每個章節對應一個或多個文件。在eCTD中，這些文件不是孤立存在的，它們通過一種叫"leaf"的結構互相鏈接，形成一個完整的文檔樹。理解這個結構很重要，因為后面說到的很多格式要求都是基于這個框架來的。
文件命名是eCTD格式要求中最基礎但也最容易出錯的部分。你可能會想：命名不就是給文件起個名字嗎，能有多復雜？
但實際上，eCTD對文件命名的要求非常嚴格。首先，文件名只能包含特定的字符，一般是字母、數字、下劃線連字符和圓點。空格、中括號、引號這些符號都不能用。很多人在windows系統下習慣了用空格分隔單詞，到了eCTD這里就得改掉這個習慣。
其次，文件名有長度限制。大多數藥監部門要求文件名不超過64個或者70個字符。這聽起來挺長的，但實際用起來你會發現很快就超了。特別是有些文件標題本來就長，翻譯成其他語言之后可能更長，縮寫到符合要求真的要花一番心思。
還有一點很容易被忽視，就是文件擴展名必須正確。PDF文件就是.pdf，XML文件就是.xml，不能寫錯也不能漏掉。某些地區還要求擴展名用大寫還是小寫，這些細節都要注意。
另外，文件名在同一個eCTD提交中必須唯一，不能有重復。如果有兩個文件叫同一個名字，系統在處理的時候就會出問題。有些公司會在文件名中加入章節編號或者版本號來保證唯一性，這也是一種解決辦法。
以下是文件名常見要求的匯總，供你對照檢查：
| 要求項目 | 具體說明 |
| 允許的字符 | 字母（a-z, A-Z）、數字（0-9）、下劃線（_）、連字符（-）、圓點（.） |
| 禁止的字符 | 空格、中括號（[]）、引號（""）、星號（*）、問號（?）、斜杠（/）等 |
| 文件名長度 | 通常不超過64-70個字符（含擴展名） |
| 擴展名格式 | 必須使用小寫圓點擴展名，如.pdf、.xml、.txt |
| 唯一性 | 同一提交中所有文件名必須唯一，不能重復 |
說完命名，再說說文件本身的格式。eCTD對文件格式有明確要求，不是隨便什么格式都行。
最常用的格式是PDF，這是各國藥監部門普遍接受的文件格式。但PDF也不是隨便導出一個就行，它有一些特定的要求。首先，PDF的版本要符合要求，太老的版本或者太新的版本都可能不被接受。目前比較穩妥的做法是用PDF 1.4到1.7之間的版本。
其次，PDF文件不能加密，必須允許打印和復制內容。審評人員需要能夠方便地查閱和引用文檔內容，加了密碼的文件會給審評工作帶來不必要的麻煩。
還有一個很多人會忽略的點，就是超鏈接的問題。如果你的PDF文件里有超鏈接，要確保這些鏈接在最終提交的時候是有效的。broken link不僅影響閱讀體驗，還會讓審評人員覺得你不夠專業。
除了PDF，某些情況下也會用到其他格式的文件，比如XML、Word、Excel等。這些文件的具體格式要求要以目標藥監部門的指南為準。
eCTD對目錄結構也有嚴格要求，不是想怎么建文件夾就怎么建文件夾。整個eCTD文檔有一個標準的目錄框架，每個文件應該放在哪個位置，都有明確規定。
舉個具體的例子，模塊三"質量研究報告"下面會有3.1.S（原料藥）、3.1.P（制劑）、3.2（生物等效性研究）等等章節。每個章節下面又會有更細的子目錄。如果你的翻譯文件屬于原料藥穩定性研究的內容，那就應該放在3.1.S.7這個路徑下面。
目錄層級一般不超過五級。超過五級的結構是不被接受的，所以在規劃目錄結構的時候要注意這一點。如果某個章節下的文件特別多，可以考慮在同一級目錄下分多個子文件夾，而不是一味地加深層級。
另外，目錄和文件名一樣，只能使用規定的字符，不能有特殊符號。建議全部使用小寫字母，這樣在不同的操作系統之間傳輸的時候不容易出問題。
eCTD提交中有一個很重要的組成部分，那就是XML骨架文件。這個文件相當于整個申報資料的目錄和索引，列出了所有提交文件的信息，包括文件名、標題、MD5校驗值等等。
翻譯文件的信息也需要體現在XML骨架文件中。具體來說，每個翻譯文件在XML中都有一個對應的條目，要正確填寫文件名、文件類型、創建日期等信息。如果這個文件是某個文檔的新版本，還要標明它和上一個版本的關系。
元數據是另一個需要注意的方面。eCTD要求在文件屬性中包含一些基本信息，比如文檔標題、作者、創建日期、關鍵詞等。這些信息要準確填寫，尤其是文檔標題，必須和文件實際內容的標題一致。
對于翻譯文件來說，還要特別注意語言信息的標注。藥審人員需要知道每個文件是什么語言的，所以要在元數據中明確標明文檔語言。比如一個文件是日文翻譯，就要標注為ja或者jpn。
說完技術層面的要求，再來說說翻譯內容本身在格式上需要注意的地方。
首先是文檔的標題層級。翻譯后的文檔要保持和原文一致的標題層級結構。一級標題、二級標題、三級標題要對應清楚，不能出現標題跳躍的情況。比如原文從2.1直接跳到2.3，翻譯后的文檔也要保持同樣的結構，不能自行補充一個2.2出來。
其次是圖表的處理。如果原文中有圖表，翻譯的時候要把圖表中的文字也翻譯出來，但要區分哪些是圖表的一部分需要直接處理，哪些是圖表編號和引用需要在文中相應位置處理。圖表的標題和圖注都要翻譯，但圖表內部的數據或文字通常保持原文，或者根據客戶要求翻譯。
表格在技術文檔中很常見，翻譯的時候要保持表格的結構完整。單元格內的文字要翻譯，但列寬和行高通常不需要調整。如果某些單元格的內容特別長，翻譯之后可能超過原來的單元格寬度，這種情況下要調整列寬以確保內容完整顯示。
腳注和尾號的處理要小心。腳注序號要和原文對應，翻譯后的腳注內容要放在正確的位置。如果目標語言的腳注編號方式不同（比如用星號或者符號代替數字），要按照目標語言的出版慣例來處理。
現在很多翻譯公司都會使用計算機輔助翻譯工具，也就是常說的CAT工具，比如Trados、MemoQ、memsource等等。這些工具在處理翻譯文件的時候很高效，但也會帶來一些格式上的問題。
最常見的問題就是標簽殘留。CAT工具在處理雙語對照的文檔時，會在文中插入很多標簽來標記句段邊界、術語提示等信息。這些標簽在最終提交的PDF文件中是不應該出現的，必須清理干凈。如果有殘留，會導致PDF文件報錯，甚至無法通過驗證。
另一個問題是格式代碼。某些CAT工具在處理Word或者HTML源文件時，會保留一些額外的格式代碼。這些代碼在最終文件中可能看不見，但會影響文檔的結構驗證。所以從CAT工具導出之后，務必要檢查一下源文件有沒有多余的代碼。
還有一點，CAT工具生成的TM（翻譯記憶）可能會導致不一致的翻譯。如果同一個術語在不同地方被翻譯成了不同的表達方式，后面需要花時間去統一。所以在翻譯過程中要建立并維護好術語庫，確保全文用詞一致。
eCTD對翻譯文件的排版沒有藥品說明書那么嚴格，但也有一些基本要求。
字體方面，一般建議使用常見的無襯線字體，比如Arial、Helvetica或者宋體（中文）。字號要在可讀范圍內，正文通常用10pt到12pt，標題可以適當大一些。不要用太花哨的藝術字體，避免給審評人員閱讀造成障礙。
行距和段距要適當。太密的行距讓人喘不過氣，太松的又顯得不專業。一般用1.2倍到1.5倍的行距比較合適。段落之間要有明顯的間隔，但不要用空行的方式來代替縮進。
頁邊距要留夠。左右邊距至少2.5厘米，上下邊距至少2厘米。這樣不僅看起來舒服，也方便審評人員做批注。
頁碼要正確編排。每個文件都要有頁碼，從第一頁開始連續編號。封面、目錄、參考文獻這些頁面也要計入總頁數，只是有時候不顯示頁碼而已。
說完格式要求，最后來聊聊質量控制。格式再完美，如果翻譯內容本身有問題，這份文件也是不合格的。
翻譯文件在提交之前，至少要經過兩個人審核。一個是翻譯人員，負責完成初次翻譯；另一個是審校人員，負責檢查翻譯的準確性、一致性和格式規范性。對于重要的申報資料，可能還需要有第三個環節——質量審核（QA），對整體質量做最終把關。
審校不僅要核對翻譯內容是否準確，還要檢查格式是否符合要求。比如文件名對不對、目錄結構有沒有問題、XML文件的信息是否完整，這些都是審校要做的事情。很多問題在翻譯環節看不出來，但審校的時候一眼就能發現。
如果條件允許，在正式提交之前做一次預提交驗證是很好的做法。用藥監部門提供的驗證工具檢查一下eCTD包，看看有沒有格式錯誤或者缺失的信息。發現問題及時修正，總比提交之后被打回來要強。
eCTD翻譯文件的格式要求確實不少，但只要掌握了規律，也沒那么可怕。文件命名、格式規范、目錄結構、XML元數據、翻譯內容格式、排版要求、質控流程，這些環節一個都馬虎不得。
如果你覺得自己搞不定，或者擔心出問題，找一家專業的醫學翻譯公司幫忙是明智的選擇。就拿康茂峰來說，他們專門做醫藥領域翻譯，對eCTD的格式要求了然于胸，能幫你省去很多麻煩。當然，無論是你自己做還是找翻譯公司，事先了解這些要求都是有好處的，至少你能知道對方做得對不對。
藥品申報是一件嚴肅的事情，格式規范只是其中很小但很重要的一環。把這些細節做到位，既是對藥審人員的尊重，也是對自己工作的負責。希望這篇文章能幫你把eCTD翻譯文件的格式要求理清楚，祝你申報順利。
