11 Sep
2000
11 Sep
'00
11:25 a.m.
嗨！大家好：
不知各位在翻譯時，有沒有遇到以下問題
大家應該都知道有些中文字會有脫逸字元(\)的問題
在我使用
bg5cc filename.pox filename.po
轉換檔案後，再使用
msgfmt -v -o /dev/null filename.po
就會出現很多出現重大錯誤的訊息
檢查後，就發現全部的錯誤都是在有脫逸字元的地方
bg5cc 似乎會把脫逸字元(\)轉成(\\)
而 msgfmt 卻又把(\\)當成錯誤字元
有人有遇到類似的問題嗎？
^_________^
Allen Huang
lancelot(a)pchome.com.tw
11 Sep
11 Sep
12:06 p.m.
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(a)pchome.com.tw
12:18 p.m.
其實問題不是在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
1:36 p.m.
基本上就是在翻譯檔案前, 先用 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(a)pchome.com.tw
14 Sep
14 Sep
3:59 p.m.
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 的轉碼。
--
~ Chih-Wei Huang (cwhuang)
'v' E-Mail : cwhuang(a)linux.org.tw
// \\ CLDP Project : http://www.linux.org.tw/CLDP/ (Coordinator)
/( )\ CLE Project : http://cle.linux.org.tw/CLE/ (Developer)
^`~'^ HomePage : http://www.cwhuang.idv.tw/
8 p.m.
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
15 Sep
15 Sep
6:29 p.m.
shyue(a)sonoma.com.tw 寫道：
現階段當然是兩者並存沒錯。
我的意思是，我們在 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.
而且 KDE menu 也已全部改為 UTF-8 了(用 big5 已經不行了)
或者說我們也同時提供一份繁體中文的 UTF-8 編碼的檔案
而且同時接受 Big5 與 UTF-8 的檔案
也就是說現階段 UTF-8 與 Big5 二者並存? Sure, 這是弟的工作 ^_^
只是, 用 UTF-8 時的 locale name 應該是
No, no. 這個地方還沒有去動到 locale.
只是 po 檔的 Header 這行改成:
"Content-Type: text/plain; charset=UTF-8\n"
就行了。(若用 KBabel 存檔選用 UTF-8 會自動加上)
--
~ Chih-Wei Huang (cwhuang)
'v' E-Mail : cwhuang(a)linux.org.tw
// \\ CLDP Project : http://www.linux.org.tw/CLDP/ (Coordinator)
/( )\ CLE Project : http://cle.linux.org.tw/CLE/ (Developer)
^`~'^ HomePage : http://www.cwhuang.idv.tw/
16 Sep
16 Sep
8:45 p.m.
On Fri, 15 Sep 2000, Chih-Wei Huang wrote:
弟的意思是指檔名的命法
目前在source code中會有一個 zh_TW.Big5.po 的檔案
當我們換成 UTF-8 之後, 這個檔案應該要叫做啥?
Shyue
我的意思是，我們在 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 會自動加上)
18 Sep
18 Sep
12:19 a.m.
New subject: [zh-l10n] Unicode encoding
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(a)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)
站 在 巨 人 的 肩 膀 向 前 眺 望
11:55 a.m.
shyue(a)sonoma.com.tw 寫道：
但沒有這個必要...!
Commit 兩份內容一樣但只是編碼不同的東西
只會造成 user 的困擾而已...
而且到時還會有同步的問題(萬一兩邊不一樣怎麼辦?)
我的意思是，我們在 commit 到 CVS 時要用 Big5 or UTF-8
encoding?
因為轉換到 UTF-8 encoding 是遲早的事，我建議
乾脆現在就都換成 UTF-8.
其實也可以二個版本都 commit 出去
[理論上]只要再建一個目錄(KDE)/檔案(Gnome)就行了... 弟的意思是指檔名的命法
目前在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
--
~ Chih-Wei Huang (cwhuang)
'v' E-Mail : cwhuang(a)linux.org.tw
// \\ CLDP Project : http://www.linux.org.tw/CLDP/ (Coordinator)
/( )\ CLE Project : http://cle.linux.org.tw/CLE/ (Developer)
^`~'^ HomePage : http://www.cwhuang.idv.tw/
8853
days inactive
8860
days old
10 comments
4 participants
participants (4)
-
allen -
allen -
Chih-Wei Huang -
shyue＠sonoma.com.tw