English page

Debconf の国際化 - テンプレート翻訳のための基礎

目次


ニュース


最新版のダウンロード

debconf-1.3.0 (またはそれ以降のバージョン) は、Debian Sid (unstable, 不安定版) に含まれています。 debconf-english または debconf-i18n をインストールするように求められますが、 debconf-i18n をインストールしてください。

libtext-charwidth-perl と libtext-wrapi18n-perl は、Debian Sid (unstable, 不安定版) に含まれています。 libtext-wrapi18n-perl は libtext-charwidth-perl に依存 (Depends:) しているため、 apt-get update; apt-get install libtext-wrapi18n-perl だけで両方をインストールできます。

debconf に対する私のパッチは、もはや不要ですが、 最後のパッチ (1.2.42.i18n.1, 2003-06-20) が、以下でダウンロードできます。


はじめに

ここでは、なぜこの改良が必要かを説明します。

Debconf は、Debian パッケージのための標準の設定ツールです。 それには、数種類の「フロントエンド」があります。 そのなかには、Unicode や東アジアの文字コードのような マルチバイト文字の改行処理に問題があるものや、日本語を まったく表示できないものもあります。

改行処理に問題が生じる理由は、雑に言うと、以下の通りです:

  1. Debconf は、Perl 標準の単純な改行モジュールである Text::Wrap を使っていますが、これはマルチバイト文字をサポートしていません。 このため、マルチバイト文字の1バイト目と2バイト目の間で改行して しまうといったことが起きます。また、文字数を正しく数えることが できないため、改行位置を正しく計算できません。
  2. Text::Wrap は、すべての文字が画面上で1カラムを占有するという 仮定に基づいていますが、これは全角文字 (2カラムを占有) や結合文字 (0カラムを占有) においては正しくありません。 この誤った仮定のため、文字列が画面上で占める幅を正しく計算 することができず、改行位置を誤ってしまいます。
  3. Text::Wrap は、中国語や日本語のような、単語の間に空白を用いない 言語をサポートしていません。適切な位置に改行のための空白を 見つけることができないために、醜い改行位置になってしまいます。
ドイツ語やフランス語のように、非 ASCII 文字 (UTF-8 においては全てマルチバイト文字となる) を少ししか使わず、単語の間に空白を用いる言語の場合は、 これはほとんど問題になりません。なぜなら、(1) 画面上での幅や文字数の計算における誤差がわずかで済み、 (2) ほとんどの改行が空白位置で起こるために マルチバイト文字 (UTF-8 では非 ASCII 文字全て) が改行文字によって分割されることがめったに起こらないからです。

以下で、本改良がない状態だとどんな不具合が出るのかを、 スクリーンショットを用いて説明します。 これらのスクリーンショットは debconf 1.2.36 を用いました。


Dialog フロントエンド

dialog interface in ja_JP.eucJP locale
「ja_JP.eucJP」ロケールです。うまく動作しています。 Debconf テンプレートの日本語への翻訳者は、Debconf の改行がうまく働くように日本語訳の適切な位置にに空白を挿入 しなければならないこと、そして翻訳者たちは実際にそうしてきた ということに注意してください。この方法は、80 桁以外の端末ではうまく動作しません。

dialog interface in ja_JP.UTF-8 locale
「ja_JP.UTF-8」ロケールです。文字幅の計算がうまくいっていません。 UTF-8 では日本語文字のほとんどが 3 バイトで 2 カラムを占有するため、 ほとんどの行で、本来の1行の幅の約 2/3 の位置で改行が起きています。 同様の問題が、東アジア言語のみならず、ロシア語やギリシア語のような 非ラテン文字を大量に使う言語でも起こると思われます。

ずっと短い位置で改行が起こっている行があることに注意してください。 これは、文中に空白文字が現れたときに起こります。日本語文は ほとんど空白を使わないので、Debconf (正確には Text::Wrap) はたまたま空白を見つけるとそこで改行をしようとします。

さらに、マルチバイト文字のいくつかは、行の最後と 次の行の先頭に分割されることで壊れてしまっています。 このような文字は、失われてしまいます。 この場合、壊れたマルチバイト文字の断片バイトは、 「?」となって表示されています。


Readline フロントエンド

readline interface in ja_JP.eucJP locale
「ja_JP.eucJP」ロケールです。うまく動作しています。 「ja_JP.eucJP」ロケールにおける Dialog フロントエンドと 同様の注意事項が適用されます。

readline interface in ja_JP.UTF-8 locale
「ja_JP.UTF-8」ロケールです。Dialog フロントエンドと同様、 うまく動作していません。ここでは、マルチバイト文字の断片は まったく表示されていません (赤矢印の位置)。不正なバイト列に 対する応答は、ターミナルエミュレータによって異なる可能性があります。


Gnome Interface

gnome interface in ja_JP.eucJP locale
「ja_JP.eucJP」ロケールです。うまく動作しています。

gnome interface in ja_JP.UTF-8 locale
「ja_JP.UTF-8」ロケールです。まったく使い物にならない ことは明らかです。これは、フォント選択が適切でないからです。 GTK は日本語を表示する潜在能力があるにもかかわらず、 デフォルトのフォント設定が悪いために日本語が表示できません。 これはおそらく、GTK 開発者がデフォルト設定を十分に テストしていないことが原因です。

error when gnome interface is invoked in ja_JP.UTF-8 locale
これは、「ja_JP.UTF-8」ロケールで Gnome フロントエンドを用いた ときに現れるエラーです。Gnome フロントエンドの問題の 原因を上記のように推測した理由は、このエラーメッセージです。


解決策

本改良は、Text::Wrap モジュールの代替として Debconf::Wrap モジュールを作りました。

Perl 5.8 の標準の「Encoding」モジュールの利用は避けるべきです。 これは、「perl」パッケージをインストールしていない状態でも Debconf が正しく動作するようにするためです。言い換えれば、「perl-base」 パッケージだけでも最低限の動作ができるべきです。同様に、 wcwidth() が Perl から使えないので、実装する必要があります。

さらに、さまざまなエンコーディングで動作する必要があります。 UTF-8 に変換し、内部処理をすべて UTF-8 で行うという方法が考えられます。 しかし、この場合、言語によって差別するということがあってはなりません。 「大きな文字コード変換テーブルを必要とするので、東アジア言語 サポートは省略します」といったことが、ときどき起こっていますが、 Debconf はそんな差別をしてはいけません。(そもそも、本改良は、 大きな文字コード変換テーブルを必要としません)。

Gnome フロントエンドについて言えば、Gnome1 の代わりに Pango に基づいた Gnome2 を用いれば問題は解決するものと思われます。 しかし、これには Perl のための Gnome2 モジュールが必要なため、 まだできていません。


久保田智広 Tomohiro KUBOTA <debian at tmail dot plala dot or dot jp>