各位，
在下想問一問，現時將 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
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 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 或其它編碼，我們都不必再改名啦。
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 也無仿啦 :-)
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
Sender: "R.I.P. Deaddog" <maddog@linuxhall.org>
但希望 po 檔用 Big5 因為這樣可以在 win32 下 cvs co & cvs commit ( 而不需要 iconv )
可是那始終是 unix 的世界嘛。cross platform 來工作本來就比較煩，試 想想，以往使用 samba 來建立 PDC 不也是頭疼不已？本來使用 Windows NT/2000 可以輕輕鬆鬆做好的工作，在 unix 不見得方便；反過來說也一樣呢。
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 ...
不贊成 $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
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 :-)
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
On Sun, 2 Sep 2001, Chinese GNU/LI List wrote:
Sender: "R.I.P. Deaddog" <maddog@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.ht...
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 ?
sorry, no idea :-)
zh-l10n-archive@lists.slat.org
-
Chih-Wei Huang -
Pofeng Lee -
R.I.P. Deaddog