嗨！大家好：
不知各位在翻譯時，有沒有遇到以下問題
大家應該都知道有些中文字會有脫逸字元()的問題
在我使用 bg5cc filename.pox filename.po 轉換檔案後，再使用 msgfmt -v -o /dev/null filename.po 就會出現很多出現重大錯誤的訊息 檢查後，就發現全部的錯誤都是在有脫逸字元的地方 bg5cc 似乎會把脫逸字元()轉成(\) 而 msgfmt 卻又把(\)當成錯誤字元
有人有遇到類似的問題嗎？
^_________^ Allen Huang lancelot@pchome.com.tw
On Mon, 11 Sep 2000, allen wrote:
嗨！大家好：
不知各位在翻譯時，有沒有遇到以下問題 大家應該都知道有些中文字會有脫逸字元(\)的問題 在我使用 bg5cc filename.pox filename.po 轉換檔案後，再使用 msgfmt -v -o /dev/null filename.po 就會出現很多出現重大錯誤的訊息 檢查後，就發現全部的錯誤都是在有脫逸字元的地方 bg5cc 似乎會把脫逸字元(\)轉成(\\)
這就是bg5cc 的功能阿 因為在C與多數語言的定義中, ""會使得所連接的自原有特殊的作用 eg. "\n"為換行符號, "\t"為tab定位點, "\"為"" 偏偏有些中文字用到了""字元來組字.... complier 就錯亂了說, 所以要把中文字中的""變成"\" 然後在編譯的過程中"\"會被還原成正常的""
而 msgfmt 卻又把(\\)當成錯誤字元
其實問題不是在megfmt, 而是在bg5cc 🙁 bg5cc 的識別有點笨, 他只會找尋不是有效的""標記, 並增加一個""成為"\" eg. ""後面不是跟著"n","t","r",""...etc. 問題就來了, 當一個中文字含有這樣的符號時 eg. 珮n == [alt-175]\n bg5cc 便會將之變成 '珮\n' ([alt-175]\n), compiler 在將之還原成[alt-175]\n 但當您再做一次bg5cc 時, 他把 '珮\n' 又變成了 '珮\n' i.e. [alt-175]\\n 而編譯器會將之當作 [alt-175][換行] (第一個""來自"\", 將"\n"翻譯成換行字元) 這當然不是我們所預期的結果, 所以 msgfmt 才會回報錯誤
有人有遇到類似的問題嗎？
解決的方法 小虫 兄在cle-devel 上有提供過 (轉載於 http://i18n.linux.org.tw/howto.php3) 基本上就是在翻譯檔案前, 先用 sed 把 "\" 還原成 "", 指令如下 cat filename.po | sed 's/\\/\/g' > filename.pox 或是您可以使用 Plasma 兄所提供的 bg5cc.pl 來取代原本的bg5cc 便可以省掉還原的動作, 因為他的程式較聰明, 不會把 "\" 變成"\" 您也可以在前述網址找到這個script
Shyue
^_________^ Allen Huang lancelot@pchome.com.tw
其實問題不是在megfmt, 而是在bg5cc 🙁 bg5cc 的識別有點笨, 他只會找尋不是有效的""標記, 並增加一個""成為"\" eg. ""後面不是跟著"n","t","r",""...etc.
sorry, 記錯了 應該是屬於中文字中的""字元 就是前面是 ASCII code 160-247 的字元
問題就來了, 當一個中文字含有這樣的符號時 eg. 珮n == [alt-175]\n bg5cc 便會將之變成 '珮\n' ([alt-175]\n), compiler 在將之還原成[alt-175]\n 但當您再做一次bg5cc 時, 他把 '珮\n' 又變成了 '珮\n' i.e. [alt-175]\\n 而編譯器會將之當作 [alt-175][換行] (第一個""來自"\", 將"\n"翻譯成換行字元) 這當然不是我們所預期的結果, 所以 msgfmt 才會回報錯誤
解決的方法 小虫 兄在cle-devel 上有提供過 (轉載於 http://i18n.linux.org.tw/howto.php3) 基本上就是在翻譯檔案前, 先用 sed 把 "\" 還原成 "", 指令如下 cat filename.po | sed 's/\\/\/g' > filename.pox 或是您可以使用 Plasma 兄所提供的 bg5cc.pl 來取代原本的bg5cc 便可以省掉還原的動作, 因為他的程式較聰明, 不會把 "\" 變成"\" 您也可以在前述網址找到這個script
Shyue
基本上就是在翻譯檔案前, 先用 sed 把 "\" 還原成 "", 指令如下 cat filename.po | sed 's/\\/\/g' > filename.pox 或是您可以使用 Plasma 兄所提供的 bg5cc.pl 來取代原本的bg5cc 便可以省掉還原的動作, 因為他的程式較聰明, 不會把 "\" 變成"\" 您也可以在前述網址找到這個script
我找到了 bg5cc.pl 可是執行後會出現
Substitution replacement not terminated at ./bg5cc.pl line 35
的錯誤訊息 line 35 是 s{([xa0-xf7])\}{$1}g; 不曉得哪裏出錯了說 🙁
p ( ^_________^ ) q -----Allen Huang---- lancelot@pchome.com.tw
allen 寫道：
基本上就是在翻譯檔案前, 先用 sed 把 "\" 還原成 "", 指令如下 cat filename.po | sed 's/\\/\/g' > filename.pox 或是您可以使用 Plasma 兄所提供的 bg5cc.pl 來取代原本的bg5cc 便可以省掉還原的動作, 因為他的程式較聰明, 不會把 "\" 變成"\" 您也可以在前述網址找到這個script
看到大家在為這個問題困擾，正好問一下。 我們是否考慮將所有的 po 檔都轉換成 UTF-8 編碼呢? 用 UTF-8 encoding 的話就沒有這個可恨的反斜線問題了。 像在 KDE Translation HOWTO 中已經明確的提出， 希望所有的 language team 都改用 UTF-8 encoding. (雖然目前用 local encoding 仍行得通) 而且 KDE menu 也已全部改為 UTF-8 了(用 big5 已經不行了)
如果用我上次提過的 KBabel 來翻譯的話，只要在 存檔時選 UTF-8 就會自動轉成 UTF-8 來儲存了。 對翻譯的人來說根本沒差。 當然如果不用 KBabel 的話就比較麻煩， 畢竟現在可用的 unicode/utf-8 editor 還不多(yuedit ?). 但無論如何，這是一個趨勢。
KDE2 的部份我已經測過不管用 UTF-8 or Big5 編碼中文都出得來。至於 GNOME 則還沒試。 所以，至少我們可以考慮 KDE2 的部份先使用 UTF-8. 我會建議翻譯者(若不用 KBabel 的話)仍使用 Big5, 但送給 shyue 後再由 shyue 轉換成 UTF-8 後 commit.
對了，CLE 附的 utf-converter 這個工具可以做 big5 <-> utf-7/8, gb <-> utf-7/8 的轉碼。
On Thu, 14 Sep 2000, Chih-Wei Huang wrote:
看到大家在為這個問題困擾，正好問一下。 我們是否考慮將所有的 po 檔都轉換成 UTF-8 編碼呢? 用 UTF-8 encoding 的話就沒有這個可恨的反斜線問題了。 像在 KDE Translation HOWTO 中已經明確的提出， 希望所有的 language team 都改用 UTF-8 encoding. (雖然目前用 local encoding 仍行得通) 而且 KDE menu 也已全部改為 UTF-8 了(用 big5 已經不行了)
或者說我們也同時提供一份繁體中文的 UTF-8 編碼的檔案 而且同時接受 Big5 與 UTF-8 的檔案 也就是說現階段 UTF-8 與 Big5 二者並存?
因為相信有些人是在 Windows 下面翻譯檔案 (像我自己用 poedit for win ^_^)
但送給 shyue 後再由 shyue 轉換成 UTF-8 後 commit.
Sure, 這是弟的工作 ^_^ 只是, 用 UTF-8 時的 locale name 應該是 zh_TW.UTF8 還是 zh_TW.UTF-8 甚至是其他的?
對了，CLE 附的 utf-converter 這個工具可以做 big5 <-> utf-7/8, gb <-> utf-7/8 的轉碼。
哈哈, 這個工具頗為好用, 我們的簡體版基本上就是用這個工具轉的說.... 只是要編輯 GB 碼時, 不太方便.... 而且缺乏詞庫轉換的功能 eg. 軟體 -> 軟件 不過還相當的方便..... 比南極星那個好多了.....
Shyue
shyue@sonoma.com.tw 寫道：
而且 KDE menu 也已全部改為 UTF-8 了(用 big5 已經不行了)
或者說我們也同時提供一份繁體中文的 UTF-8 編碼的檔案 而且同時接受 Big5 與 UTF-8 的檔案 也就是說現階段 UTF-8 與 Big5 二者並存?
現階段當然是兩者並存沒錯。
我的意思是，我們在 commit 到 CVS 時要用 Big5 or UTF-8 encoding? 因為轉換到 UTF-8 encoding 是遲早的事，我建議 乾脆現在就都換成 UTF-8.
當然對您 coordinator 來說是用兩者都可以接受。 若是翻譯者寄來的是 Big5 的檔案，您再轉成 UTF-8 後再 commit.
至於您寄給翻譯者的檔案要用 Big5 or UTF-8 encoding? 我想大多數翻譯者還是習慣用 Big5, 因此最好還是寄 Big5 的。 所以流程應該是，您從 CVS checkout 出 UTF-8 編碼的 檔案，轉成 Big5 後再寄給翻譯者。 (同樣放在網站上的也用 Big5) 也就是說，除了 CVS 之外，其它的地方用的都是 Big5.
Sure, 這是弟的工作 ^_^ 只是, 用 UTF-8 時的 locale name 應該是
No, no. 這個地方還沒有去動到 locale. 只是 po 檔的 Header 這行改成: "Content-Type: text/plain; charset=UTF-8\n" 就行了。(若用 KBabel 存檔選用 UTF-8 會自動加上)
On Fri, 15 Sep 2000, Chih-Wei Huang wrote:
我的意思是，我們在 commit 到 CVS 時要用 Big5 or UTF-8 encoding? 因為轉換到 UTF-8 encoding 是遲早的事，我建議 乾脆現在就都換成 UTF-8.
其實也可以二個版本都 commit 出去 [理論上]只要再建一個目錄(KDE)/檔案(Gnome)就行了...
至於您寄給翻譯者的檔案要用 Big5 or UTF-8 encoding? 我想大多數翻譯者還是習慣用 Big5, 因此最好還是寄 Big5 的。 所以流程應該是，您從 CVS checkout 出 UTF-8 編碼的 檔案，轉成 Big5 後再寄給翻譯者。 (同樣放在網站上的也用 Big5) 也就是說，除了 CVS 之外，其它的地方用的都是 Big5.
Sounds good to me...
Sure, 這是弟的工作 ^_^ 只是, 用 UTF-8 時的 locale name 應該是
No, no. 這個地方還沒有去動到 locale. 只是 po 檔的 Header 這行改成: "Content-Type: text/plain; charset=UTF-8\n" 就行了。(若用 KBabel 存檔選用 UTF-8 會自動加上)
弟的意思是指檔名的命法
目前在source code中會有一個 zh_TW.Big5.po 的檔案 當我們換成 UTF-8 之後, 這個檔案應該要叫做啥?
Shyue
Hi guys,
今天與居士兄聊了一下關於志偉兄所提的 unicode 編碼的問題. 目前考慮使用 zh_TW 來放置 Unicode (UTF-8) 的版本, 而同時也沿用 zh_TW.Big5 來放置 Big5 的版本. 會這麼想是因為 zh_TW 才是標準的 locale name, 而 Unicode 也是未來的標準. 同時也保留既有(大家習慣的)Big5 encoding在老地方. 而對於現行的e-mail通知與網站內容, 仍保留 Big5 使用, 畢竟不是所有的平台都有 unicode, 不過都會有 big5.
不知道大家的想法如何? 弟會等到有共識之後再開始執行變動的部分.
Shyue
------------------------------------------------------------------- ~ Jing-Jong Shyue (薛景中) 'v' E-Mail : shyue@sonoma.com.tw // \ CLDP Project : http://www.linux.org.tw/CLDP/ (Translator) /( )\ CLE Project : http://cle.linux.org.tw/CLE/ ^`~'^ I18N Translate: http://i18n.linux.org.tw/ (Coordinator) 站 在 巨 人 的 肩 膀 向 前 眺 望
shyue@sonoma.com.tw 寫道：
我的意思是，我們在 commit 到 CVS 時要用 Big5 or UTF-8 encoding? 因為轉換到 UTF-8 encoding 是遲早的事，我建議 乾脆現在就都換成 UTF-8.
其實也可以二個版本都 commit 出去 [理論上]只要再建一個目錄(KDE)/檔案(Gnome)就行了...
但沒有這個必要...! Commit 兩份內容一樣但只是編碼不同的東西 只會造成 user 的困擾而已... 而且到時還會有同步的問題(萬一兩邊不一樣怎麼辦?)
弟的意思是指檔名的命法 目前在source code中會有一個 zh_TW.Big5.po 的檔案 當我們換成 UTF-8 之後, 這個檔案應該要叫做啥?
Hmmm... Good question.
如果照即將 release 的 glibc 2.2 的想法， 我們不需要再加 encoding 名稱上去了。 也就是只要用 zh_TW 就行了。 在裡面不管用什麼 encoding 都可以， glibc 會自動轉換。( 當然要有 Content-Type: text/plain; charset=UTF-8\n 之類的資訊 glibc 才能判斷它是何 encoding. )
其實現在 Qt2.2/KDE2 的做法也差不多， 只是它不是用 glibc 去轉，而是用 Qt 去處理 這些轉碼的問題。
不過若要將所有目錄都改為 zh_TW 的話又是工程浩大... 啊! 傷腦筋...:p
zh-l10n-archive@lists.slat.org
-
allen -
allen -
Chih-Wei Huang -
shyue＠sonoma.com.tw