Thunderbird 0.9 日本語リソースのテスト作成

登録日: 2004年11月 06日 記事: 45 所在地: Japan

Pink 版 0.2.4 を置きました。

http://pink.skillup.jp/tb/thunderbird-0.9.ja-JP.langpack-pink-0.2.4.xpi

dynamis さんにサーバスペースをお借りしたので、zip からの拡張子変更はなくてよくなりました。

作業履歴・問題点・愚痴 Sad

はこちらに

http://pink.skillup.jp/tb/ChangeLog_Pink.txt

軽い全面チェックの作業途中ですが、日をおくのも良くないので置くことにしました。
Releace Announcement の方にも書いてトピックを移すつもりだったのですが、UI チェックをしたら見落としがぼろぼろ Sad

明日にでも気がついたところを直してから、contribute 版として改めて出します。

# 0.9 リリースからもう 10 日...

登録日: 2003年10月 09日 記事: 69 所在地: 東京

Pink さん、池田です。作業おつかれさまです。

Pink wrote:

作業履歴・問題点・愚痴 Sad

はこちらに

http://pink.skillup.jp/tb/ChangeLog_Pink.txt

一点だけ。

Pink wrote:

- encoding, charactor encoding は「文字コード」でいいんでないかのぉ。
=== OE 見たら「エンコード」だった。

私が Netscape 7.2 非公式 JLP を作成したときも、この点で悩みました。
7.1 と 7.2 （Mozilla だと 1.4 と 1.7) の差分ファイルを見ていただければわかりますが、
この間に coding が全て encoding に変わっています。

JLP 作成中には余裕がなかったので、今回 Bugzilla を検索してみたところ、この変更の元になったバグは、
change 'character coding' to 'character encoding' で、
2004-03-01 に FIXED になってますから、1.7b あたりで入った修正だと思います。

そもそもこの提案がなされた理由は；
1. W3C が 'character encoding' という用語を使用している。
2. MS IE、Opera、Konqueror/Safari が 'encoding' を使用しているので、乗り換えユーザにフレンドリー。
という事のようです。

# ざっと見ですが、元 Netscape US の桃井さんが反対していたけど、押しきられたような感じ。

これを踏まえて；
日本語として、また他メーラ使用者の乗り換えという要素を考慮に入れた上で、
「文字コード」と「文字エンコード」のどっちが適切か、という問題になるかと思います。

個人的には、「エンコード」というと「エンコード・デコード」のバイナリデータとテキストデータの変換、
という印象が強く、「文字コード」のほうがしっくり来ます。
（N7.2 JLP でも、あえて「文字コード」のままにしました）

また、Google の検索結果でも
「文字コード」：452,000 件
「文字エンコード」： 5,630 件
で、「文字コード」の圧勝です。 Smile

Pink さんも御存知のように IE/OE は「エンコード」ですけど、Opera とか Safari の日本語版、
あるいは、Becky! とか Eudora はどうなってるんでしょうかね？

登録日: 2003年10月 11日 記事: 228 所在地: 内地

池田 wrote:

Pink さんも御存知のように IE/OE は「エンコード」ですけど、Opera とか Safari の日本語版、
あるいは、Becky! とか Eudora はどうなってるんでしょうかね？

Apple標準アプリのSafari / Mail.appでは"テキストエンコーディング"、MacIEでは"文字セット"となっていました。

登録日: 2004年11月 06日 記事: 45 所在地: Japan

一通り UI の見直し出来たと思うので Release Announcement に出しました。
http://moz.skillup.jp/jlp/viewtopic.php?t=275
今後は報告など Main Products の方でお願いします。
http://moz.skillup.jp/jlp/viewtopic.php?t=276

池田 wrote:

Pink wrote:

- encoding, charactor encoding は「文字コード」でいいんでないかのぉ。
=== OE 見たら「エンコード」だった。

私が Netscape 7.2 非公式 JLP を作成したときも、この点で悩みました。

情報ありがとうございます。
悩みますねぇ...一度は「文字コード」にしたんですが、いまのところ、Firefox との整合性も考えて「文字エンコード」のままにしています。皆さんの情報や dynamis さんと相談してどちらにするか決めたいと思います。

池田 wrote:

Pink さんも御存知のように IE/OE は「エンコード」ですけど、Opera とか Safari の日本語版、あるいは、Becky! とか Eudora はどうなってるんでしょうかね？

Joker wrote:

Apple標準アプリのSafari / Mail.appでは"テキストエンコーディング"、MacIEでは"文字セット"となっていました。

Becky! だと "言語" "キャラクタセット名"
Edmax だと "文字コードセット"
これらだと、エンコーディングは "7bit" とか "Quoted-Printable" などの送信形式に使われています。
メールだと結構ばらばらな印象です。

Opera 7.21(古いですが) だと "エンコード" ただしフォント選択では "文字コードセット" のようです。

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

Pink wrote:

一通り UI の見直し出来たと思うので Release Announcement に出しました。
http://moz.skillup.jp/jlp/viewtopic.php?t=275
今後は報告など Main Products の方でお願いします。
http://moz.skillup.jp/jlp/viewtopic.php?t=276

ということで、ローカライズセンターにもミラーしました。
http://www.mozilla-japan.org/jp/l10n/thunderbird/

0.9- というのは単にまだ公式リリースが出ていないという意味で、開発版が+で貢献版が-だなどという話ではありません。念のため。

Pink wrote:

池田 wrote:

Pink wrote:

- encoding, charactor encoding は「文字コード」でいいんでないかのぉ。
=== OE 見たら「エンコード」だった。

私が Netscape 7.2 非公式 JLP を作成したときも、この点で悩みました。

情報ありがとうございます。
悩みますねぇ...一度は「文字コード」にしたんですが、いまのところ、Firefox との整合性も考えて「文字エンコード」のままにしています。皆さんの情報や dynamis さんと相談してどちらにするか決めたいと思います。

池田 wrote:

Pink さんも御存知のように IE/OE は「エンコード」ですけど、Opera とか Safari の日本語版、あるいは、Becky! とか Eudora はどうなってるんでしょうかね？

Joker wrote:

Apple標準アプリのSafari / Mail.appでは"テキストエンコーディング"、MacIEでは"文字セット"となっていました。

Becky! だと "言語" "キャラクタセット名"
Edmax だと "文字コードセット"
これらだと、エンコーディングは "7bit" とか "Quoted-Printable" などの送信形式に使われています。
メールだと結構ばらばらな印象です。

Opera 7.21(古いですが) だと "エンコード" ただしフォント選択では "文字コードセット" のようです。

このあたりって何処行っても統一性がないんですよねぇ。
個人的には Firefox の時点で異論が出てこないことの方が不思議だったんですが、ここの訳について意見を毎回求めていたらきりがなくて処理しきれないため、特にフィードバックで意見のこなかったものについては私の判断でどんどん進めていたものの一つです。

"文字コード" が一番良く聞かれる語であるのは自明であるのに敢えてそれを外したのは、技術的な用語として間違ってるんじゃないかと思ったからです。専門じゃないですし間違ってるかも知れませんが私の理解の範囲で順に関係用語を整理してみます。

まず "キャラクタセット" はカタカナ語であること、"文字集合" は表現可能な文字の一覧を定義してい
るだけの用語であろうということから却下しました。
初心者向けに "言語" と言ってしまう気持ちも分かりますが、少なくとも複数言語を UI で選択できるソフトでは使っちゃダメです。

"文字コード" というのは個々の文字と対応する数値ラベルとの対応関係を規定する規則であり、Shift_JIS とか EUC-JP などを区別する語としては適切なものと言えるかと思います。

じゃぁ、"文字コード" とすれば良いじゃんって話なのですが、話が Unicode に及ぶとややこしくなってきます。Unicode は一つの文字集合定義を表すものですが、実際のデータファイルでの表現方式はかなり多数あります。Firefox で扱える範囲だけでも UTF-7/UTF-8/UTF-16(LE,BE)/UTF-32(LE,BE) と 6種。細かく分ければまだ方式としては存在していたはずです。
で、これらをも区別するためには文字コードというだけでは不適切なんじゃないかと思ったわけです。
ISO-2022-JP を 7bit/8bit/Base64/Quoted-Printable から選ぶという場合には普通 "文字コード" を選ぶとは言わないと思いますが、UTF-8/UTF-16 などを選ぶ場合にも "文字コード" を選ぶという意識じゃないと思うわけです。

符号化方式も含めた意味合いで、一般的に "文字コード" と呼ばれてしまうことが多いものとの連想の良さも考えると "文字エンコード" が妥当じゃないかと考えたわけです。

私の判断というのは時間との折り合いも含めた仮決定であるものも多いですので、用語対照表などに書かれたものについてもどんどん意見下さい。というか、用語対照表を作成しているのは、用語についての意見のフィードバックを得るためという意味合いが強いですので。(^^;
# Firefox で見ると崩れるという件については本日帰宅後に対応…

ちなみに、私の用語選択の方針としては技術的に正しい用語をベースに検討します。
初心者がしょっちゅう触れる部分はある程度世間の認知に合わせて技術的な間違いも許容し、初心者はあまり触らないところについては厳密性を優先して妥協はしないということ。
これは微妙でずっと悩んでいるラインです。

登録日: 2003年10月 11日 記事: 228 所在地: 内地

dynamis wrote:

このあたりって何処行っても統一性がないんですよねぇ。
個人的には Firefox の時点で異論が出てこないことの方が不思議だったんですが、ここの訳について意見を毎回求めていたらきりがなくて処理しきれないため、特にフィードバックで意見のこなかったものについては私の判断でどんどん進めていたものの一つです。

ブラウザの場合、特に指定しなくても問題なく表示できたりしますし、あまり触る所でも無いかなと思う一方、メールの場合、初めてセットアップする時は必ず触る(目にする)所ですからね。

Quote:

符号化方式も含めた意味合いで、一般的に "文字コード" と呼ばれてしまうことが多いものとの連想の良さも考えると "文字エンコード" が妥当じゃないかと考えたわけです。

Outlookでは、"エンコード方法"とか"エンコードする"等、やはり"エンコード"で揃えてました。

登録日: 2004年9月 07日 記事: 113

http://moz.skillup.jp/jlp/viewtopic.php?p=2024#2024

dynamis wrote:

文字コードについては、その辺りについてあまり詳しい分けじゃないのですが、"文字コード" というのは理論的な文字に対応する数値で、Shift_JIS や UTF-8 などというデータとして表す方式ではないような気がしたからです。

私もその様に思います。
"文字コード" と言うと、なんか難しい漢字を入力する時に使う物というイメージが…

登録日: 2004年11月 06日 記事: 45 所在地: Japan

dynamis wrote:

ということで、ローカライズセンターにもミラーしました。
http://www.mozilla-japan.org/jp/l10n/thunderbird/

0.9- というのは単にまだ公式リリースが出ていないという意味で、開発版が+で貢献版が-だなどという話ではありません。念のため。

ありがとうございます。0.3.7 も出しましたのでよろしく Razz

コンピュータ上の"文字"という概念がきわめてややこしく、歴史的にも七転八倒している状況は(いいかげんながら)理解した上で、方針が何かあるのかなと思ってお聞きした次第です。

私自身の印象としては文字集合+符号化方式=文字コードみたいな理解をしていて文字エンコードだと、文字集合はどこいったんだ？と感ずるところがあります(一般的ではないと思います、はい)。

まぁ Unicode が一般化してきた頃から、この辺の概念もだいぶ変わりつつあるとは思っています。

dynamis wrote:

ちなみに、私の用語選択の方針としては技術的に正しい用語をベースに検討します。
初心者がしょっちゅう触れる部分はある程度世間の認知に合わせて技術的な間違いも許容し、初心者はあまり触らないところについては厳密性を優先して妥協はしないということ。
これは微妙でずっと悩んでいるラインです。

方針と言うか方向性はわかりました。"文字エンコード" についてはそのままでいいかなと思います。
線をひくのは難しい(というよりほとんど無理)というか用語選択そのものが経験次第(専門的な用語の場合、意味を損なわないためそのままにするか、うまい用語を見つけられるか)なのでしょうから。

# そういえば、迷惑メールの "正規メール" "適応フィルタ" はやっぱりよくないと思うのですが、いい用語ありませんかねぇ...

登録日: 2004年9月 07日 記事: 113

Pink さん、お疲れ様です。

Thunderbird にも、手を出してみました。 Very Happy

Tb や MS-OE のような、高機能なメールソフトは初めてなのですが、
うーん… いまいちよく分からない… ^^;

早速、訳について。 (ここで良いのかな？)

Pink wrote:

# そういえば、迷惑メールの "正規メール" "適応フィルタ" はやっぱりよくないと思うのですが、いい用語ありませんかねぇ...

"適応フィルタ" → "学習フィルタ" と言うのはどうでしょうか？
IME の辞書の学習のようなイメージで。

"ツールバーのカスタマイズ" 内の "絵" という表記
Firefox では "絵" から "アイコン" に変更されていますので、
Thunderbird でも同様にお願いします。

オプション → 作成
"Composition" の訳が、左のアイコンでは "作成" 、右側上のバーでは "編集" になっています。

オプション → 作成 → アドレス自動補完
"ディレクトリを編輯" となっています。変換ミスですね。

オプション → 添付 → "添付ファイル毎に保存場所を指定する"
Firefox では "ファイルごとに保存場所を尋ねる" となっています。

"添付ファイルごとに~" の方が良いと思いますが、
"指定する" か "尋ねる" かは、検討が必要そうですね。
# "指定する" の方がいいかも。

登録日: 2003年10月 09日 記事: 69 所在地: 東京

池田です。一点だけ。

Pink wrote:

# そういえば、迷惑メールの "正規メール" "適応フィルタ" はやっぱりよくないと思うのですが、いい用語ありませんかねぇ...

迷惑メールの反対語はないんですよね。 Smile

私も悩んだあげく、「通常メール」としました。
ご参考まで。

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

Pink wrote:

私自身の印象としては文字集合+符号化方式=文字コードみたいな理解をしていて文字エンコードだと、文字集合はどこいったんだ？と感ずるところがあります(一般的ではないと思います、はい)。

感覚としてはそれで良いと思います。
狭義の文字コードは Makoto さんの書くように文字に対応する数値など。
広義の文字コードはそれに加えて Shift_JIS/EUC-JP などの区別
ということじゃないかと思っています。

コンテクストとしては文字集合が何であるかというのではなく符号化方式の、Shift_JIS/EUC-JP などの区別と Unicode の中での UTF-8/UTF-16 などの区別を含めているものを表しているので、文字集合(表現できる文字のリスト)が何であるかということは気にしなくて良いかと。

Pink wrote:

まぁ Unicode が一般化してきた頃から、この辺の概念もだいぶ変わりつつあるとは思っています。

ですね。
https://bugzilla.mozilla.org/show_bug.cgi?id=232722
を印刷して電車などで読みましたが、Unicode 関連などの影響で charcter encoding という用語が一般化していく方向に感じました。少なくとも英語圏では確実に。

Pink wrote:

方針と言うか方向性はわかりました。"文字エンコード" についてはそのままでいいかなと思います。
線をひくのは難しい(というよりほとんど無理)というか用語選択そのものが経験次第(専門的な用語の場合、意味を損なわないためそのままにするか、うまい用語を見つけられるか)なのでしょうから。

これだけ書いておいて何ですが、Thunderbird JLP 開発版で用語を変えてみました。(^^;
"文字エンコード" だとどうしても何か動詞の印象が強く(というか辞書ではencodeに動詞はない)、文字を変化するかのような印象があるため、"文字エンコーディング" と変えました。
"文字コード" との親和性から選んでいた "文字エンコード" ですが、そもそも用語が違うと思えば無理して合わせるよりも原文の選択(character code ではなく character encoding)に合わせて "文字エンコーディング" にした方が良いかと思ったので。
なお Google のヒット数については "文字エンコーディング" が "文字エンコード" の倍弱であり、Java などの公式文書でも "文字エンコーディング" で揃えられています。Unicode 関連文書では "文字エンコード" が多いです。

Pink wrote:

# そういえば、迷惑メールの "正規メール" "適応フィルタ" はやっぱりよくないと思うのですが、いい用語ありませんかねぇ...

迷惑メールの反対語はないんですよね。 :)
私も悩んだあげく、「通常メール」としました。
ご参考まで。[/quote]

困ったところですよねぇ。
"通常メール" が普通な感じなんですが余りに一般的すぎて、重要度・HTML/Plain などについての用語にもなってしまうために意図的に別にしたものです。半ば意見募集のテストみたいな感じ…
# 旧 "ジャンク <-> 非ジャンク" はこの辺やりやすかったんですけどね…
not junk だけでなく junk status についても関わってきたり…

"適応フィルタ" は Adaptive Filter についての最も無難な直訳に過ぎません。

Makoto wrote:

"適応フィルタ" → "学習フィルタ" と言うのはどうでしょうか？
IME の辞書の学習のようなイメージで。

その方が良さそうですね。
adaptive and learning systems: 適応学習システム
などという言葉もあったりしますが、これもそもそも同義語が並んでるだけだと思えば adaptive の訳語として "学習" を持って行きてもよいと考えられますからね。
意見ありませんかぁ？

Makoto wrote:

"ツールバーのカスタマイズ" 内の "絵" という表記
Firefox では "絵" から "アイコン" に変更されていますので、
Thunderbird でも同様にお願いします。

Firefox との共通部の対応は全て一気にやりました。
非共通部の修正は進行中。

因みに、最初から"アイコン"としていないこと、現在でも"テキスト"ではなく"文字"であることは画面サイズに依るものです。OS のフォント設定次第ですが、収まりきらない環境の人も少なくないはずであり、"アイコン" に変えたのはデフォルトサイズがそれまでより微妙に大きくなったため。
# でも、Thunderbird では "ツールバーを追加" が無いため、"テキスト" にしても良さそうですね。
# といっても CVS 導入されたら区別できなくなる予感なので取りあえず放置…

Makoto wrote:

オプション → 作成
"Composition" の訳が、左のアイコンでは "作成" 、右側上のバーでは "編集" になっています。

編集に揃えます。

Makoto wrote:

オプション → 添付 → "添付ファイル毎に保存場所を指定する"
Firefox では "ファイルごとに保存場所を尋ねる" となっています。

"添付ファイルごとに~" の方が良いと思いますが、
"指定する" か "尋ねる" かは、検討が必要そうですね。
# "指定する" の方がいいかも。

"ごと" についてはまだ統一できていませんが、ひらがなで揃える方向での検討中。
ダイアログウィンドウがでるので "尋ねる" にしていますが、"チェック/尋ねる" については全面的に "確認する" へと変更していっているところで、ダイアログウィンドウがでる場合の文章についても "指定する" で統一していきますかね…