[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Description-ja
岡@奈良先端です。
# 一応整理しておくと、Description-${LANG} 側における Md5sum
# フィールドの必要性についての議論、です。
"鴨志田"すなわちAtsushi KAMOSHIDAさんより:
鴨志田> 鴨志田です.
鴨志田> # うーん,何カ月前に同じ説明を書いたような記憶がある.....
すみません、気が付かなかった...。
鴨志田> 以下の例については,((a)部分は修正してください)
> (例) glut-dev パッケージ
> Package: glut-dev
...
鴨志田> 上の例では 3.3-3 までは (c)を,3.3-4 は(b),3.3-5と3.3-6(最新版)は
鴨志田> (a)といった具合です.もしも,3.3-7 がリリースされて description に変化
鴨志田> がなければ,(a)のバージョンを修正します.
おおまかに分かりましたが、
このフォーマットの欠点は(翻訳作業上の便宜的なフォーマットで
あればこれはこれでいいかもしれませんが、配布フォーマットとし
て言及します)、同じフィールド名が何度も繰り返されている点、
各フィールドが持つ性質が文脈依存になっている点です。
これは、RFC822的 じゃないと思います。
鴨志田> 更新については,今考えている(している)方法は,
鴨志田> description原文
鴨志田> description.ja
鴨志田> を比較して,バージョンアップに伴い内容に変更が出た場合には
鴨志田> description.jaを更新(原文と新しいバージョンを入れる),翻訳する人が翻
鴨志田> 訳する,です.
> ここもいまいち分かりません。「内容に変更が出た場合」とありま
> すが、description.ja には原文が入っているのでしょうか。
鴨志田> 『description原文』にあります.私がアップロードしたものは
鴨志田> description-en.tar.gz です.
これも、翻訳スタイルとしては構いませんが、配布時には「原文の
Description との対応」を description原文を参照しないと確定で
きないのでは、いろいろ弊害があります:
→ 翻訳作業形態として、「対応する原文の保管」を強要している。
翻訳作業は誰でも参加できる必要があるので(誰でもソースパッケー
ジをリビルドできるのと同じことです)、
* 最新のソースパッケージ
* (パッケージとの対応が古いかもしれない)最新のdescription-*
の二つのみがあれば改訂作業ができる必要があると考えています。
そのために必要な情報として最小限に抑えたのが、ソース側の
Description の md5sum 化です。
# フォーマットは、(開発|翻訳)形態に依存してはならない、です。
鴨志田> description.enは,Packages.gz などから新しいパッケージ情報がえられたと
鴨志田> きにdescription を比較して,内容が異なるならば description.en を修正し,
鴨志田> description.ja は description.en のバージョン付けに従うように自動的に
鴨志田> 修正します. description.en は普通はいじりません.
もちろん翻訳形態としてはこのモデルに習う所はありますが、純粋
なフォーマット定義に際しては、実際の作業スタイルとの依存性を
完全に排除しなければならないと考えます。
--
岡 充 (Mitsuru Oka)
奈良先端科学技術大学院大学