[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debian-devel:10361] Re: [japo:00021] Re: textutils



久保田です。

From: Mitsuru Oka <oka@debian.or.jp>
Subject: [debian-devel:10357] Re: [japo:00021] Re: textutils
Date: Sat, 11 Sep 1999 03:51:24 +0900

> msgidは英語ですからASCII
じつは、msgid に 0x80 以上の文字を使っているソフトウェアがあるのです。
それは minicom なのですが、そのおかげで、EUC と共存できないので
バージョンアップのたびに該当部分をエスケープシーケンスを使って
手動で書き直さないといけなくなっています。
これは、minicom のソースの書き換えを要求すべきですかね?

それとも、もし msgid に 0x80 以上の文字が含まれていたら、
エスケープシーケンスを使うように xgettext および msgmerge が
書き直されるべきなんでしょうか。じつは、minicom はソースでは
エスケープシーケンスを使っているのに、xgettext と megmerge が
ベタの 0x80 以上の文字へと、悪い方向に変換してしまうのです。

ちなみに、その文字は罫線文字です。コードセットはよくわからない
のですが、\263 です。




> 初めて翻訳する時にはmsgmergeは使わないので文字が切れるような
> 事が起きません。問題が発生するのは改訂する時です。古いバージョ
> ンの、例えばja.poのmsgstrから新版のja.poへ書き換える際に整形が
> 起こります。

もし見栄えということが重要なのなら (行の折り畳みって要するに
そういうことでしょう?)、msgstr が見栄えよく書かれているという
ことは、翻訳者の責任なのではないでしょうか。とくに、その言語の
ことをよく知っているのは msgmerge プログラムではなくて翻訳者
なのだから、せっかく翻訳者が書いたものに msgmerge が手を加えるのは
おせっかいにも程がある、と思います。

結論としては、msgmerge は翻訳者が書いたものに対して手を
加えるべきではない。つまり、行の折り畳みはするべきではない。




> どうやらワイドキャラクタに一回変換しておいて、文字のバイト数
> チェックのためにマルイバイトに落としながら変換していく方法に
> なりそうです。

行の折り畳みは、バイト数を基準にするのではなくて、カラム数を
基準にすべきだと思うのですが。それとも、この「行の折り畳み」は、
見た目の美しさではなく、1行が80バイトまでしか使えないような
エディタを使っている人のことを考慮して、なされているのでしょうか?

「行の折り畳みを無効にする」だとだめな理由ってなんでしょう?
そんなパッチだと受け入れてもらえそうにないから?

たぶんそんなことはさんざん議論されたことなのでしょうから、
どこか、メーリングリストのアーカイブが見れるところを紹介
していただければ、と思います。


/***********************************************************
 * 久保田智広  Tomohiro KUBOTA
 * tkubota@xxxxxxxxxxx / kubota@debian.or.jp
 ***********************************************************/