l10n-merge へのフィードバック

登録日: 2006年9月 25日 記事: 693

# 本当は本家バグにコメントすべきなんですが、dynamis さんとは日本語で話したいのでとりあえずこちらに。

trunk で言語リソースに追加があったので、これは l10n-merge の出番だと思って試してみたんですが、バグを見つけました。

region.properties で、en-US よりも ja の方が多く定義されているのですが、多い分が obsolete としてコメントアウトされてしまいます。

両方にあれば、 enTmp と l10nTmp から削除。
l10nTmp に残ってしまったものは、en-US にはないということなので、obsolete とする。

というロジックだと思うのですが、
L10nMerge.py の 225行目から

Code:

if not __dont_ignore((mod, path, k)):
if enTmp.has_key(k):
del enTmp[k]
del l10nTmp[k]
continue

例外扱いして無視するのであれば、enTmp にあるかどうかに関わらず、l10nTmp からは削除する、つまり

Code:

if not __dont_ignore((mod, path, k)):
if enTmp.has_key(k):
del enTmp[k]
del l10nTmp[k]
continue

ではないかと思うのですがどうでしょう？
これで、正しく動作しているように見えます。

登録日: 2003年10月 05日 記事: 1744

むむむむむぅ。はい。ご指摘通りです。

出力されたリソースが compare-locale をパスできるものとなること
マージ後にもう一度マージしても当然何も変化しないこと
マージされた後の出力が望み通りのフォーマットになること
entity のソート、挿入に拡張できるコードにすること
構文チェック機能も果たすこと

だけしか考えておらず、過不足比較対象から除外されているものについての取り扱いはちゃんと確認していませんでした。

テスト中に一度検索エンジンの順序がおかしい減少に出会っていたのですが、今考えてみれば、l10n-merge したものを使って作った JLP を使ってたときだったんですね。
そのときにすぐ気づくべきでした。むぅ。(^^;

当該バグにもパッチとして添付しておきました。はい。
バグ発見ありがとうございます。また何かありましたらお知らせください。

なお、entity のソートとか en-US only = new entity の(ファイル末尾追加ではなく)挿入、構文チェック機能などについては手元でやりかけて時間なくなって放置してるんですが、また時間ができて気が向いたら実装予定です。
# 取り敢えず compare-locale へのマージを待とうかな気分ですが
# compare-locale の方も色々修正されてるようですし

登録日: 2006年9月 25日 記事: 693

mozilla.dev.l10n でもアナウンスされている DTD の追加

Code:

<!ENTITY % netErrorAppDTD SYSTEM "chrome://global/locale/netErrorApp.dtd">
%netErrorAppDTD;

ですが、これは merge できないみたいですね。
完璧に merge するのは無理だとしても、warning を出すとかはできないものでしょうか？

登録日: 2006年9月 25日 記事: 693

Re: Sunbirdソースから移動。

dynamis wrote:

cvs での共同作業用に作り直し中の lot を今月中には Fx だけでなく Tb/Sb でも使える形にまとめます。

dynamis wrote:

ja/ja-JP-mac の Nightly JLP (en-US 更新による過不足は英語のコピーでマージ)

l10n-merge を Tb/Sb にも使うということですよね。
最初に dynamis さんが出してきたバージョン(+ 自分の修正)を使っているのですが、Sb に使ってみて気づいたのが、outlookCSVDateParseConfirm みたいに行を分割しているものがあるとうまく merge してくれないみたいです。

Tb/Sb ではこういうのがいくつかありますから、対応させる必要がありそうです。
# Axel さんの new compare-locale ベースにすれば直っているのでしょうか。追いかけてないのでわからないのですが

あと、「過不足」のうち「不足」はコピーしないといけないのは間違いないですが、「過」については削除してしまうと、タイミングによってはどの nightly ビルドにも対応していない JLP になってしまいます。
nightly ビルドのソース取得の時刻にあわせた en-US リソースを使うか、あるいはテスト用ということで「過」もそのまま含めるか、あるいは hourly くらいのタイミングで作り続けて使う人が使うビルドに合わせて選ぶか、タイミングが悪かったときはあきらめることにするか、のいずれかが必要になると思います。

# 自分は nightly 追っかけ用に毎日手元で merge してますが、タイミングを合わせるのは面倒なので「過」もそのまま含めるように改造しています。

登録日: 2003年10月 05日 記事: 1744

dynamis@取り急ぎ

いくつか不完全なところがあるのは把握しています。Axel さんに手元の最新バージョンをもらってそれをチェックした上で、可能な範囲で残ってる問題に対応やカスタマイズした上で使おうと思っています。

merge 周りについてはまだ詳細詰めていませんが、

ja latest そのままで普通に JLP ビルド
ja latest に en-US latest をマージした JLP ビルド
en-US latest に en-US 1 week ago の追加マージした en-US を生成
ja latest に ja 1 week ago を追加マージした merged ja を生成
後者に前者を追加した余分なものいっぱいのリソースで JLP ビルド

を全部作ってしまっても良いかもなぁと漠然と思っています。

いずれにしても Nightly JLP は本当にテスト用に過ぎないので、当面ある程度割り切ります。Nightly ビルドのチェックをしたいが、どんな形でも良いから取り敢えず日本語になってるのが必要って人、場合向けです。(^^;

いろいろ不完全でもとにかくやり始めてみてから随時改善していくつもりです。
# merge スクリプトの QA の意味も込めて、ですので

動かしはじめたらツッコミよろしくお願いします。

登録日: 2006年9月 25日 記事: 693

dynamis wrote:

いずれにしても Nightly JLP は本当にテスト用に過ぎないので、当面ある程度割り切ります。Nightly ビルドのチェックをしたいが、どんな形でも良いから取り敢えず日本語になってるのが必要って人、場合向けです。(^^;

l10-merge を利用して、trunk 用お試し版 JLP を作ってみました。
お試し版 JLP 置き場
追記: JLP は Firefox 用 Thunderbird 用に移動しました。
機械的に merge しているだけなので、Fx3 や Tb2 以降に追加されたものは英語のままで、訳は追加されていません。
JLP のタイムスタンプと、同じ頃のソースからビルドされた、Fx や Tb の trunk ビルドで使ってください。
とは言っても、たまたま変更とぶつかってしまったとき以外は、たいていは数日くらいは大丈夫だと思います。
動作確認等はまったくなしに公開しますので、おかしくても文句は言わないでください。
ただし、報告があれば、修正するかもしれませんししないかもしれません。

dynamis wrote:

いろいろ不完全でもとにかくやり始めてみてから随時改善していくつもりです。
# merge スクリプトの QA の意味も込めて、ですので

merge スクリプトがそのままではうまく動かなかったので、一部修正して使っています。
パッチは上記置き場に置いています。
修正点

過不足比較対象外の扱い(報告済)
entity 名に - が使われているとマッチしなかったのを、許容するように。
obsolete なものをそのまま残すオプションを追加(これがないと、余分なものいっぱいのリソースを作れないので)
properties ファイルで、\ を使って次の行に続いているものを、無理矢理なんとか処理できるように。

なお、ベースは dynamis さんが添付していた、最初のバージョンです。
(その後 Axel さんが変更したものは、その後のビルドシステム変更で動かなくなってしまったので。)

登録日: 2006年9月 25日 記事: 693

l10n-merge に修正を加えました。

修正点:

content handler を無視リストに加えました。

パッチは上記 JLP 置き場内に置いています。
# compare-locales は対応済だったりするので、最新版と merge してしまえば、こういった個別対応は不要になるはずなんですが…

あと、おかしいのには気付きつつ修正していないのですが、en-US 側で新たにディレクトリを 2 階層以上掘ってファイルが追加された場合、ja 側でそれに相当するディレクトリを掘るのに失敗します。
os.mkdir を os.makedirs にすれば良いのかも。

登録日: 2006年9月 25日 記事: 693

また l10n-merge のバグを見つけました。

修正点:

無視する対象のはずなのに、l10n 側に多くあるものが削除されてしまうバグは修正済だったのですが、逆に少ないものが追加されてしまうバグが残っていたので直しました。

パッチは上記 JLP 置き場内に置いています。

登録日: 2006年9月 25日 記事: 693

あ wrote:

l10-merge を利用して、trunk 用お試し版 JLP を作ってみました。
お試し版 JLP 置き場

JLP を ftp-developer に置くようにしました。
Firefox 用
Thunderbird 用

ディレクトリ名に含めている日時は、本家と同様の PST/PDT です。
nightly ビルドのディレクトリ名や、ビルド ID 等との比較がしやすいと思います。

登録日: 2006年9月 25日 記事: 693

あ wrote:

JLP を ftp-developer に置くようにしました。
Firefox 用
Thunderbird 用

SeaMonkey 用と Sunbird 用も用意してみました。
例によってノーチェックなので、ぶっ壊れていることもあるかもしれません。
というか Thunderbird 用 JLP が今朝ぶっ壊れてました。

SeaMonkey については、ダウンロードマネージャやパスワードマネージャがおかしいですが、これは Bug 381157 – Make SeaMonkey download manager use toolkit backend や Bug 390025 – Move to LoginManager and remove wallet from SeaMonkey 待ちのはず。
あと、SeaMonkey 用 langpack には Venkman や ChatZilla 等の locale は含まれないようですが、このへんどうするのかとかは知りません。

ゲスト

"seamonkey and chatzilla localization"
http://groups.google.co.jp/group/mozilla.dev.l10n/msg/2503c26b08b7fce4

Robert Kaiser wrote:
"... The localized files are supposed to go into extensions/irc/ in your
locale's hg repository. To have it built into nightlies, please file
another bug in SeaMonkey Build Config, assigned to me, asking for
inclusion into ChatZilla's all-locales file. ..."

とのことで、リクエストする必要があります。

登録日: 2006年9月 25日 記事: 693

カスベァ wrote:

To have it built into nightlies, please file
another bug in SeaMonkey Build Config, assigned to me, asking for
inclusion into ChatZilla's all-locales file. ..."

とのことで、リクエストする必要があります。

このトピックに返信されているということは

あ wrote:

SeaMonkey 用 langpack には Venkman や ChatZilla 等の locale は含まれないようですが、このへんどうするのかとかは知りません。

への返信かと思うのですが、まだ日本語版 nightly すらビルドされていない状態なので、nightly に ChatZilla のリソースを入れてもらうなんて、まだ考えてみてもいませんでした…

そうではなくて SeaMonkey 用 langpack の話なんですが、たとえばドイツ語版の場合、ChatZilla's all-locales file にはちゃんと de が含まれていて、ドイツ語版 SeaMonkey で ChatZilla を開けばちゃんとドイツ語化されています。
一方、英語版 SeaMonkey にドイツ語 langpack を入れてドイツ語化しても、ChatZilla はドイツ語化されません。

SeaMonkey 用 langpack に ChatZilla のリソースは入れる予定とかはあるのか？それとも、ChatZilla 用 langpack とかが別にあるのか？あるいは、ChatZilla の langpack なんて作るつもりはないのか？
そのへんを、私は知りません。という話です。

登録日: 2006年9月 25日 記事: 693

あ wrote:

SeaMonkey 用 langpack に ChatZilla のリソースは入れる予定とかはあるのか？それとも、ChatZilla 用 langpack とかが別にあるのか？あるいは、ChatZilla の langpack なんて作るつもりはないのか？
そのへんを、私は知りません。という話です。

本家の意図は知りませんがソースツリー的にはビルド可能なので、Seamonkey Nightly Japanese Langpack 的には ChatZilla 用 JLP と Venkman 用 JLP も生成して、SeaMonkey 用と同じところに置くようにしました。

DOM Inspector については、本家のソースツリー的に langpack 生成できるようにはなっていないのと、l10n-merge が未対応のため放置中。
アクセスキーが二重に表示される件については bug 6459 – [ChatZilla] intl.menuitems.alwaysappendaccesskeys を true にするとアクセスキーが二重に表示されると bug 6460 – [Venkman] intl.menuitems.alwaysappendaccesskeys を true にするとアクセスキーが二重に表示されるを立てました。
誰かが根本的になんとかしてくれるとうれしいのですが、もし望み薄ならば、アクセスキーを削除する等 L10N 的に Workaround が必要になるかも。