[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Description-ja (Re: いくつかの訳語および表記の統一について)
岡＠奈良先端です。-doc でしたが -devel にもクロスポスト(?)です。
### ここから
"鵜飼"すなわちFumitoshi UKAIさんより:
> Packages.gz の生成はどういう過程を経ているんでしょうか。これ
鵜飼> dpkg-scanpackages を使っています。
鵜飼> 基本は dpkg-deb -I の出力ですね。
なるほど。
> 鵜飼> debian を mirror して 原文は自動 import できるといいかなぁ とか
> 鵜飼> 思いますが…
>
> 原文は、cvs に入れるべきなのかどうかちょっと悩んでいます。
> あるバージョンを確実に押えておかないと、頻繁に変わってしまう
> のでは翻訳が大変だという点からは入れておくべきですよね。
鵜飼> まぁ Description の場合、それほど頻繁には変わらないとは思うんですが…
cvs 的には、作業が楽になるのであればあってもいいと思います。
# それはまた後々でいいですが...
### ここまでは -doc な話です
Description.${LANG}.gz 的には、過去の Packages.gz の情報が無
いと変更を察知できないようでは駄目なので、Packages.gz にある
Description: フィールドの md5sum を Description.${LANG}.gz
の方に記録するようにして、例え Packages.gz にあるパッケージ
のバージョンが上がったとしても、md5sum に変化が無ければ自動
追従できるようにしておくとかなり労力を軽減できそうです。 -- #1
さて、LANG な情報をシステムがどう扱うべきかを考えてみました。
二つ考えられます:
* system available LANGs(SAL). (少なくとも C はデフォルトで
入るべきですが、/usr/share/locale にも無いのでいちいち記
述する事はないと思います)。複数指定可能であるべきなのでリ
スト記述します。
ex. SAL = {en_US, de_DE, ja_JP.ujis}
* system default LANG (SDL).
¬(SDL ∈ SAL) → SDL = C (1)
デフォルト言語は用意しとけば、まあ何かに使えるんじゃない
かと思います(例えば、何も環境設定していないユーザの LANG
のデフォルト値にするとか)。
ex. SDL = ja_JP.ujis
これに対応する設定ファイルを例えば、
/etc/locale.available
/etc/locale.default
って事にしておきます。
* * *
次に、パッケージシステムのどこかのレイヤで上記の SAL を調べ
て対応する
∀ description.${L}, L ∈ SAL (2)
を構築する必要があります(鴨志田さんによると[*1]
description-ja ですがいろいろ見ていると `.' の方が好まれそう
です)。
[*1] http://www.debian.or.jp/Documents/users/kamop/chdesc.ja.html
それで、どのレイヤがこの処理を行うのか考えると、apt では駄目
な感じがします。apt は dpkg に置き代わるものでは無いと書かれ
ていますし[*2]、この手のフォーマットを直接いじるようにはでき
ていないからです(apt は独自のバイナリキャッシュフォーマット
を持っていて、主にこのキャッシュの上で作業します[*2])。やは
り整合性を考えると dpkg レベルで処理した方がうまく馴染みます。
それで、description.${LANG} は[*2]で鴨志田さんがされているよ
うに /var/lib/dpkg 下に置くものとします。
[*2] /usr/doc/apt/design.text.gz
そこで、/var/lib/dpkg/available 辺りの構築を dpkg 系のプログ
ラムが行うのと同じように /var/lib/dpkg/description.${LANG}
も構築してやらねばなりません(install 時と purge の時)。
問題点は二つあります。
* (2) にあるように全ての SAL について構築するためのオーバ
ヘッドです。遅いコンピュータだと結構高く付くかもしれませ
ん(今でさえ dpkg は遅いんですから)。
* SAL が追加ないしは削除された時の挙動について。整合性をど
う保つべきなのか考えていく必要があります。同期を取るコマ
ンド dpkg-sync とか考えられそうですが、破綻しても構わな
いものにしておく方が無難かつ安全です(所詮表示言語が違う
だけのものですから)。あとは、設定ファイルは visudo や
vipw のように専用のツールを介して編集してもいいかもしれ
ません、cron によって更新してもいいかもしれません。
表示機構等は鴨志田さんの考え方[*1]をベースにすれば dpkg でも
apt でも dselect でも同じように扱える筈です(という事で省略)。
* * *
今度は開発サイドから考えていく必要が、大いにあります。まだ考
えが纏まっていないので途中までの説明と問題点を挙げるに留めま
す。
* ソースパッケージと Description の翻訳物は分離可能にすべ
き。ソースパッケージに含まなければならない、では、現実的
に翻訳追従は不可能です。
ただし、特定の LANG についての Description を含めてもい
いようにすべきか、完全に外すべきかは議論が必要です。
* バイナリパッケージと Description の翻訳物も同じ理由で分
離すべきです。ただし、近い将来全てのバイナリパッケージが
サーバ側で自動的にビルドされるようになり、メンテナ側はソー
スパッケージのみの upload になるのであれば、この限りでは
ありません。
いずれにしても、特定の LANG について例外的に Description
の翻訳物だけを含むべきではありません。バイナリパッケージ
は複雑化するべきではないからです(全て入るか全て外すかの
いずれか)。
* 外された Description の翻訳物はサーバのどこに配置される
べきか。ソースパッケージの近くのディレクトリに置いてしま
うとバイナリパッケージにもほとんど同一のものが置かれる事
になり冗長かもしれません。絶対必要なものではないので、バ
イナリパッケージ付近に突然発生するかの如くに置かれてもい
いかもしれません。とは言え、changelog は必要か、翻訳物自
体の md5sum を取ったものや翻訳者の pgp は、となると、課
題は山積みです(実質 *.deb と同じ作業になる)。
ディレクトリのレイアウトはどうすべきか。
dists/${DIST}/${COMPONENT}/binary-${ARCH}/${SECTION}
の下にバイナリパッケージと並ぶように置くとファイルが増え
すぎて嫌がられそうです。その下にディレクトリを切るのも考
えものです。そこで、
dists/${DIST}/${COMPONENT}/description/${SECTION}
の下に置くというのはいかがでしょうか。ファイル名は
${PACKAGE}.${LANG}
です(何か拡張子を付けた方がいいかもしれません)。バイナリ
パッケージサイドに突如置くという仮定の元では、パッケージ
バージョン番号は付けません[*3]。
[*3] 話が分岐してしまうので、バージョン番号を付ける場合をこ
こで書きます。付けるとすれば、自動生成によるものであるべき
で、ソースパッケージ層で作られた翻訳物から自動的に生成され
るべきです(先にも書いたようにほとんど内容の変更は無いので
すが)。ソース→バイナリを義務化すると、ディスクを沢山消費
してしまう欠点はあるものの、pgp や md5sum を付ける事の問題
点を解消してくれる可能性があります。また、この過程で #1 の
処理を自動的に行えます。description 翻訳物中にソースパッケー
ジのバージョン番号(Version: **-*) を記述する必要も無くなる
ものと思われます。
* apt-get は、この新しいファイルのダウンロード作業をサポー
トするべきです(この段階でもSALを参照する)。dpkg はこれを
インストールします。
しかしながら、先に書いた dpkg-sync なる機能を実装できな
い問題は残っています。apt-sync ですかねぇ...。
眠くなってきたので、ここまで。御意見下さい。
--
岡 充 (Mitsuru Oka)
奈良先端科学技術大学院大学