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

[Mitsuru Oka <oka@debian.or.jp>]

岡＠奈良先端です。

# gnomeのリストでちょっといい解決法が見出せそうですが、
  また後日。

At Sat, 11 Sep 1999 00:08:46 +0900,
Tomohiro KUBOTA <kubota@xxxxxxxxxxxxxxxxxxxxx> wrote:
> 
> 久保田です。

> > 一方で、本当に国際化するのは結構大変で、仮りにワイドキャラク
> > タに変換したとします。そうすると、文字ごとののカラム数を正確
> > に処理するための知識が足りないような気がしています(2カラムと
> > 1カラムの文字を、コードセット非依存に区別できるような標準化
> > されたAPIを知らないので)。
> 
> こんな API が存在すれば、その API は うそ ですね。
> カラム数にはそもそも標準など存在しないのですから。

もちろんそうです。

> すみません、いま気がついたんですが、gettext での行の折り畳みは、
> ソース中に長い文字列リテラルが存在する場合に起こるのですよね。
> .po ファイル中の msgstr が長い場合に行が折り畳まれてしまうような
> 場面って存在するのでしょうか？
> 
> というのは、.po ファイルには msgid と msgstr が共存します。
> msgstr はどんなコードセットでも許容しないといけないので、
> msgid は ASCII を使うべきです。それでも、msgstr に使われる
> コードセットに、ASCII と共存できるものでなければならない
> という制限を加えることになりますが、その制限を取り去れば
> .po ファイル自体が存在できなくなってしまうので、最小限の
> 制限として、これは必要です。
> 
> というわけで、msgid に来る文字列、すなわちソースコード中の
> 文字列リテラルは、ASCII の範囲で書かれなければなりません。
> そうすると、ASCII で書かれた文字列リテラルは、どこで改行
> しようと破壊されることはありえない。
> 
> したがって、EUC-JP が行の折り畳み処理によって壊れてしまう、
> という問題は、ソースコードに ASCII 以外のコードセットを
> 使うことによって生じたものであるので、解決法としては
> ソースコードを書き換えるのが正しく、gettext に EUC-JP パッチ
> が必要となるような状況そのものがおかしいのだ、という結論になります。

むろのmsgidは英語ですからASCII、msgstrのコードセットは頭のほ
うで

 "MIME-Version: 1.0\n"
 "Content-Type: text/plain; charset=ISO-8859-1\n"
 "Content-Transfer-Encoding: 8-bit\n"

のように指定するので必ず一つです(I18N)。ASCIIと、ASCIIに排他
的なコードセットが混在してもmsgidとmsgstrは独立しているので
問題ありません。その場合、直接ファイルをいじるのは面倒になり
ますが、Emacsのモードはそのへんよくできています。

 # でもiso2022-jpとかeuc-jpとか書くのにどうしてcodingset=じゃ
   なくて charset=なんだろう。

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

> > その他、日本語は単語の途中で改行が入っても許されますが、英語
> > やヨーロッパの言語はそうではありません。これをどう機械的に判
> > 断するかも悩み所です。
> 
> エンドユーザーには触れないプログラムだから、単語の途中で切って
> しまってもかまわない、というのは、なしでしょうか？

なしでしょうね、翻訳者はエンドユーザーです。

> やっぱり、一定のカラム数で改行するような動作はしないように
> する、というのがいちばんの解決法だと思います。そうすれば、
> 未知の文字コードに対する仮定とか一切なしにできます。
> 
> 途中で改行を加える、というのは、EUC ならともかく、シフト状態を
> 持つ ISO-2022-* のようなコードだと、wchar_t などを使わない
> かぎり、大変な作業になりますよ。

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

# 高々msgmerge一つに、やばいぐらい時間を使っている、
# というかやばい...。
--
岡 充 (Mitsuru Oka)
奈良先端科学技術大学院大学