29 Aug
2001
29 Aug
'01
4:22 p.m.
各位，
在下想問一問，現時將 Gnome 中所有名稱為 zh_TW.Big5.po 的翻譯檔
改名為 zh_TW.po，是否可行？當然，原有檔案的 encoding 本身不應修改，但檔案名稱
改為 zh_TW 就不必擔心將來使用 UTF8 encoding（Gnome 2.0 好像已決定儘量統一
為 UTF8）時混亂。若大家覺得沒有問題，在下就可以開始改名的了（實際上在下已
將 gtk 2.0、libgnome 等一部份將會在 gnome 2.0 出現的 CVS module 都改了名）。
Abel
29 Aug
29 Aug
7:43 p.m.
On Wed, 29 Aug 2001, Chinese GNU/LI List wrote:
在下想問一問，現時將 Gnome 中所有名稱為 zh_TW.Big5.po 的翻譯檔
改名為 zh_TW.po，是否可行？當然，原有檔案的 encoding 本身不應修改，但檔案名稱
改為 zh_TW 就不必擔心將來使用 UTF8 encoding（Gnome 2.0 好像已決定儘量統一
為 UTF8）時混亂。若大家覺得沒有問題，在下就可以開始改名的了（實際上在下已
將 gtk 2.0、libgnome 等一部份將會在 gnome 2.0 出現的 CVS module 都改了名）。
其實我(個人)實在是不太贊成 utf8,
因為 X 的 utf8 (cjkv) 環境還不成熟
不過潮流所趨, 就先改檔名吧, 再次謝謝您的努力 ...
--
Pofeng "informer" Lee, 李柏鋒, 886-928-554-335 ( 20:00-23:00 GMT+8 )
pofeng at linux.org.tw, an_evil_anti-opensource_nerd at PDAology.com.tw
Chang Gung Children's Hospital
9:46 p.m.
Pofeng Lee 寫道：
On Wed, 29 Aug 2001, Chinese GNU/LI List wrote:
> 在下想問一問，現時將 Gnome 中所有名稱為 zh_TW.Big5.po 的翻譯檔
> 改名為 zh_TW.po，是否可行？當然，原有檔案的 encoding 本身不應修改，但檔案名稱
> 改為 zh_TW 就不必擔心將來使用 UTF8 encoding（Gnome 2.0 好像已決定儘量統一
> 為 UTF8）時混亂。若大家覺得沒有問題，在下就可以開始改名的了（實際上在下已
> 將 gtk 2.0、libgnome 等一部份將會在 gnome 2.0 出現的 CVS module 都改了名）。
我贊成。也該如此...!
KDE 的部份我也早想改成 zh_TW,
但先前跟 KDE 的人員討論還是暫不改名，
畢竟 CVS 要改目錄名並不方便...:(
其實我(個人)實在是不太贊成 utf8,
因為 X 的 utf8 (cjkv) 環境還不成熟
不過潮流所趨, 就先改檔名吧, 再次謝謝您的努力 ...
其實我們現在討論的只有 po 檔的部份，
跟其它的(X, environment, ...)關係並不大。
以 glibc 2.2 來說不管你 po 檔用什麼編碼，
程式實際執行時 glibc 會 on fly 幫你轉成
程式所用的編碼(LC_CTYPE).
這表示你不必在意 po 檔的編碼與程式
run-time 使用的 encoding 是否相同。
我就是我一直提倡使用一個與 encoding
無關的名稱(zh_TW)的原因。 :-)
也就是，如果我們現在就用 zh_TW,
不管是繼續用 Big5, 將來要改用 UTF-8
或其它編碼，我們都不必再改名啦。
--
~ Chih-Wei Huang (cwhuang(a)linux.org.tw)
'v' CLDP Project : http://www.linux.org.tw/CLDP/ (Coordinator)
// \\ CLE Project : http://cle.linux.org.tw/CLE/ (Developer)
/( )\ I18N Project : http://i18n.linux.org.tw/ (Translator)
^`~'^ HomePage : http://www.cwhuang.idv.tw/
31 Aug
31 Aug
9:52 a.m.
On Wed, 29 Aug 2001, Chinese GNU/LI List wrote:
以 glibc 2.2 來說不管你 po 檔用什麼編碼，
程式實際執行時 glibc 會 on fly 幫你轉成
程式所用的編碼(LC_CTYPE).
這表示你不必在意 po 檔的編碼與程式
run-time 使用的 encoding 是否相同。
我就是我一直提倡使用一個與 encoding
無關的名稱(zh_TW)的原因。
:-)
贊成 po 檔名不含 Big5
po 裡面會描述 encoding
但希望 po 檔用 Big5
因為這樣可以在 win32 下 cvs co & cvs commit
( 而不需要 iconv )
不贊成 $LANG 一下就用 zh_TW ( 最少先用 zh_TW.utf8 zh_TW.Big5 )
因為不是所有語言都支援 nl_langinfo()
( 好像只有 C & Perl, 但我相信不是每個 distro 的 perl package 都裝齊 )
當然, 如果不會有 utf8 big5 混用的時期, 直接用 zh_TW 也無仿啦 :-)
--
Pofeng "informer" Lee, 李柏鋒, 886-928-554-335 ( 20:00-23:00 GMT+8 )
pofeng at linux.org.tw, an_evil_anti-opensource_nerd at PDAology.com.tw
Chang Gung Children's Hospital
10:13 a.m.
On Fri, 31 Aug 2001, Pofeng Lee wrote:
但希望 po 檔用 Big5
因為這樣可以在 win32 下 cvs co & cvs commit
( 而不需要 iconv )
可是那始終是 unix 的世界嘛。cross platform 來工作本來就比較煩，試
想想，以往使用 samba 來建立 PDC 不也是頭疼不已？本來使用 Windows NT/2000
可以輕輕鬆鬆做好的工作，在 unix 不見得方便；反過來說也一樣呢。
不贊成 $LANG 一下就用 zh_TW ( 最少先用 zh_TW.utf8 zh_TW.Big5 )
因為不是所有語言都支援 nl_langinfo()
( 好像只有 C & Perl, 但我相信不是每個 distro 的 perl package 都裝齊 )
當然, 如果不會有 utf8 big5 混用的時期, 直接用 zh_TW 也無仿啦 :-)
其實，還有一個 variable 是 redhat 未用過的： $LANGUAGE。$LANGUAGE
是 GNU 的 extension，其中可以定義多個 locale 一起使用，例如：
LANGUAGE=zh_TW:zh_TW.Big5:zh
這樣程式就應該先找 zh_TW 中的 mo 檔，跟著是 zh_TW.Big5，最後才到 zh。
只有在這個變數未定義的情況下才看看 $LANG，最後才到 LC_*。
Mandrake 是會用到這個變數的；但是 redhat 沒有，這比較麻煩。
Abel
2 Sep
2 Sep
9:31 a.m.
Sender: "R.I.P. Deaddog"
<maddog(a)linuxhall.org>
但希望 po 檔用
Big5
因為這樣可以在 win32 下 cvs co & cvs commit
( 而不需要 iconv )
可是那始終是 unix 的世界嘛。cross platform 來工作本來就比較煩，試
想想，以往使用 samba 來建立 PDC 不也是頭疼不已？本來使用 Windows NT/2000
可以輕輕鬆鬆做好的工作，在 unix 不見得方便；反過來說也一樣呢。 不贊成 $LANG 一下就用
zh_TW ( 最少先用 zh_TW.utf8 zh_TW.Big5 )
因為不是所有語言都支援 nl_langinfo()
( 好像只有 C & Perl, 但我相信不是每個 distro 的 perl package 都裝齊 )
當然, 如果不會有 utf8 big5 混用的時期, 直接用 zh_TW 也無仿啦 :-)
其實，還有一個 variable 是 redhat 未用過的： $LANGUAGE。$LANGUAGE
是 GNU 的 extension，其中可以定義多個 locale 一起使用，例如：
LANGUAGE=zh_TW:zh_TW.Big5:zh
11:13 a.m.
On Sun, 2 Sep 2001, Pofeng Lee wrote:
But gtk/gimp had been ported onto win32, if we use
utf8 as the defualt
encoding of zh_TW.po, we will take the risk that the end user will get
confused with utf8 and big5 ...
For gtk/gimp specific case, yes. Win32 users may not see utf8 encoded
translation at all. But if I recall correctly, no more then a few gtk
applications have been natively ported to win32? I haven't tried gimp
win32 port, so can't comment much. But can win32 gimp handle translation
files at all ? If yes, what version of glibc is it linked against ?
yes, but for an AP developer, I must know the encoding
( at the run time )
If we use zh_TW, a perl programmer could use nl_langinfo() to look up the
encoding name only when the distro shipped with the perl package.
Of course, if all of the AP had been gettextized and all of the
widget had been internationalized(?), we can forget the concept of
encoding. However, the world is not perfect :-)
Have many of perl programs been i18n'ed ?
Abel
5 Sep
5 Sep
12:26 a.m.
On Sun, 2 Sep 2001, Chinese GNU/LI List wrote:
sorry, no idea :-)
--
Pofeng "informer" Lee, 李柏鋒, 886-928-554-335 ( 20:00-23:00 GMT+8 )
pofeng at linux.org.tw, an_evil_anti-opensource_nerd at PDAology.com.tw
Chang Gung Children's Hospital
Sender: "R.I.P. Deaddog"
<maddog(a)linuxhall.org>
For gtk/gimp specific case, yes. Win32 users may not
see utf8 encoded
translation at all. But if I recall correctly, no more then a few gtk
applications have been natively ported to win32? I haven't tried gimp
win32 port, so can't comment much. But can win32 gimp handle translation
files at all ? If yes, what version of glibc is it linked against ?
gimp/win32 did not depend on glibc
( it depend on gdk/win32 )
M$ MSVCRT.DLL support wide character natively
http://msdn.microsoft.com/library/devprods/vs6/visualc/vccore/_crt_locale.h…
and iconv & gettext had been ported onto the win32
Of course, if
all of the AP had been gettextized and all of the
widget had been internationalized(?), we can forget the concept of
encoding. However, the world is not perfect :-)
Have many of perl programs been i18n'ed ?
8501
days inactive
8507
days old
zh-l10n-archive@lists.slat.org
7 comments
3 participants
participants (3)
-
Chih-Wei Huang -
Pofeng Lee -
R.I.P. Deaddog