松浦です。
このMLで、どちらかに統一するという見解がはっきりしていれば、どちらでも 問題ないと考えています。ある範囲内で統一美を追求するのであれば、誰が翻 訳しても (理想的には) 同一の翻訳文が出来上がるよう、翻訳ポリシーを文書 としてまとめておく必要はあると思います。
ただ、man-pages-jaのマニュアルをいくつか見てみたり、日本語のメッセージ を出力するコマンドのいくつかを見た限りでは、長音なしの方が優勢との印象 を持ちました。また、google trendsでserverの長音の有無を比較したところ、 長音無しの方がやや優勢のようです。printer, computer, directoryの場合、 長音なしが優勢でした。 例: 「サーバ,サーバー」の場合 http://www.google.com/trends?q=%E3%82%B5%E3%83%BC%E3%83%90%E3%83%BC%2C%E3%82...
06/07/20 に Tadashi Jokagi ml@elf.no-ip.org さんは書きました:
ちなみに定時された JIS の資料では「-er」「-or」「-ar」で長音記 号を用いても略しても誤りではないとされています(PDF でいう 64/92)
上鍵さんが引き合いに出された部分はG.6.2-cの「なお…」の部分だと思われ ます。これは、「-er, -or, -arなどの場合は、ア列の長音であるから、この 規定 (G.6.2-c) に則って取り扱う」という意味であり、長音記号をつけても よいと規定している訳ではないと思います。G.6.2-c-1が適用されるか否かは、 私は情報系の専門分野に身を置いた事がないので解かりません。また、 G.6.2-c-2を適用すると、表G.3の「3音以上の場合、語尾に長音を付けない」 等の規定により、語尾に長音はつきません。さらに、G.6.2-c-3についても、 先ほどのgoogle trendsの結果等から、慣用的には長音なしとなると考えられ ます。
ちなみに Sun は口語に近い表記をするようにしているとのことです(例 えばほとんどの場合「こんぴゅーたー」「めーらー」など伸ばして話を します)
手許のTru64 Unixのマニュアルは長音省略派でした。 メーカーによっても異なるようですし、私としては上に述べましたように、 Fedoraが提供するプログラム群につける日本語訳はFedoraとしてポリシーが決 まっていれば、私としては問題となりません。
ディストリビューション全体の統一美を追求するのであれば、他のプログラム や文書の体裁と合わせるという選択肢もあるのではないかと思いますし、 Fedora提供プログラム群内の統一美を求めるのであれば、このMLで見解をまと めたり、どこかに文書化して提示されていると分かり易いと思います。
上鍵さんの変更に対し疑問を呈しているのは私だけのようですし、このMLに参 加されている多くの方が長音ありでよいという見解であれば、Fedora提供プロ グラム群に日本語訳をつける際には、それにしたがいます。
長文、失礼致しました。
松浦
上鍵です.こんにちは.
MATSUURA Takanoriさんの6f27515e0607192016p44a03d51h26d41ad350ad4ba3@mail.gmail.comから
このMLで、どちらかに統一するという見解がはっきりしていれば、どちらでも 問題ないと考えています。ある範囲内で統一美を追求するのであれば、誰が翻 訳しても (理想的には) 同一の翻訳文が出来上がるよう、翻訳ポリシーを文書 としてまとめておく必要はあると思います。
ただ、man-pages-jaのマニュアルをいくつか見てみたり、日本語のメッセージ を出力するコマンドのいくつかを見た限りでは、長音なしの方が優勢との印象 を持ちました。また、google trendsでserverの長音の有無を比較したところ、 長音無しの方がやや優勢のようです。printer, computer, directoryの場合、 長音なしが優勢でした。 例: 「サーバ,サーバー」の場合 http://www.google.com/trends?q=%E3%82%B5%E3%83%BC%E3%83%90%E3%83%BC%2C%E3%82...
06/07/20 に Tadashi Jokagi ml@elf.no-ip.org さんは書きました:
ちなみに定時された JIS の資料では「-er」「-or」「-ar」で長音記 号を用いても略しても誤りではないとされています(PDF でいう 64/92)上鍵さんが引き合いに出された部分はG.6.2-cの「なお…」の部分だと思われ ます。これは、「-er, -or, -arなどの場合は、ア列の長音であるから、この 規定 (G.6.2-c) に則って取り扱う」という意味であり、長音記号をつけても よいと規定している訳ではないと思います。G.6.2-c-1が適用されるか否かは、 私は情報系の専門分野に身を置いた事がないので解かりません。また、 G.6.2-c-2を適用すると、表G.3の「3音以上の場合、語尾に長音を付けない」 等の規定により、語尾に長音はつきません。さらに、G.6.2-c-3についても、 先ほどのgoogle trendsの結果等から、慣用的には長音なしとなると考えられ ます。
ちなみに Sun は口語に近い表記をするようにしているとのことです(例 えばほとんどの場合「こんぴゅーたー」「めーらー」など伸ばして話を します)手許のTru64 Unixのマニュアルは長音省略派でした。 メーカーによっても異なるようですし、私としては上に述べましたように、 Fedoraが提供するプログラム群につける日本語訳はFedoraとしてポリシーが決 まっていれば、私としては問題となりません。
ディストリビューション全体の統一美を追求するのであれば、他のプログラム や文書の体裁と合わせるという選択肢もあるのではないかと思いますし、 Fedora提供プログラム群内の統一美を求めるのであれば、このMLで見解をまと めたり、どこかに文書化して提示されていると分かり易いと思います。
上鍵さんの変更に対し疑問を呈しているのは私だけのようですし、このMLに参 加されている多くの方が長音ありでよいという見解であれば、Fedora提供プロ グラム群に日本語訳をつける際には、それにしたがいます。
長文、失礼致しました。
松浦
---- inline file
Fedora-trans-ja mailing list Fedora-trans-ja@redhat.com https://www.redhat.com/mailman/listinfo/fedora-trans-ja
上鍵です.こんにちは.
MATSUURA Takanoriさんの6f27515e0607192016p44a03d51h26d41ad350ad4ba3@mail.gmail.comから
このMLで、どちらかに統一するという見解がはっきりしていれば、どちらでも 問題ないと考えています。ある範囲内で統一美を追求するのであれば、誰が翻 訳しても (理想的には) 同一の翻訳文が出来上がるよう、翻訳ポリシーを文書 としてまとめておく必要はあると思います。
明文化されるにこしたことはないと思います.ハイ.最後にも書き ますが,もし今無くて困ってるなら Sun の翻訳メモリを使うといいん じゃないかと思います.
ただ、man-pages-jaのマニュアルをいくつか見てみたり、日本語のメッセージ を出力するコマンドのいくつかを見た限りでは、長音なしの方が優勢との印象 を持ちました。また、google trendsでserverの長音の有無を比較したところ、 長音無しの方がやや優勢のようです。printer, computer, directoryの場合、 長音なしが優勢でした。
技術系のところは技術者が主に書いているので,長音記号を省くのが 常識の世界でもあるので,どちらが多いかは自明でしょう.で,Google Trend ですが,残念ながら少なくとも日本語での評価としてはまだまと もに使えるクオリティではありません.
■Google Trendで「フォルダー」「ワープロ」 http://www.google.com/trends?q=%E3%83%95%E3%82%A9%E3%83%AB%E3%83%80%E3%83%BC http://www.google.com/trends?q=%E3%83%AF%E3%83%BC%E3%83%97%E3%83%AD&ctab...
■Google( Search)で「フォルダー」「ワープロ」 http://www.google.co.jp/search?q=%E3%83%95%E3%82%A9%E3%83%AB%E3%83%80%E3%83%... http://www.google.co.jp/search?q=%E3%83%AF%E3%83%BC%E3%83%97%E3%83%AD&st...
#余談ですけど Google ではヒット数の違いはありますが「サーバー」は「サー バ」も引っかかりますし,「サーバはサーバーも引っかかります」ので, Google で評価したいなら「サーバー -サーバ」「サーバ -サーバー」で比べ る方がいいでしょう
ちなみにオンラインに存在する英和辞書では長音付きのものが多いよ うです.私は API リファレンスなど開発物でもなければ一般向けを意識 したいので,仮に比率なら Google の比率より辞書の比率を尊重したい です.
■Excite(三省堂) http://www.excite.co.jp/dictionary/english_japanese/?search=user&match=b... http://www.excite.co.jp/dictionary/english_japanese/?search=printer&matc... #Server はいわゆる C/S の意味がなかったので排除しています
■Infoseek(EXCEED) http://dictionary.www.infoseek.co.jp/?ii=1&sm=1&sc=1&gr=ml&q... http://dictionary.www.infoseek.co.jp/?spa=1&sc=1&se=on&lp=0&... http://dictionary.www.infoseek.co.jp/?ii=1&sm=1&sc=1&gr=ml&q... #user がそのままだとカタカナがなかったので user-definable をいれてます
■goo(EXCEED) http://dictionary.goo.ne.jp/search.php?MT=user&search_history=&kind=... http://dictionary.goo.ne.jp/search.php?MT=server&search_history=user&... http://dictionary.goo.ne.jp/search.php?MT=printer&search_history=server&... #英和じゃなくて国語時点にある(苦笑
■スペースアルク http://www2.alc.co.jp/ejr/index.php?word_in=user&word_in2=%82%A0%82%A2%8... http://www2.alc.co.jp/ejr/index.php?word_in=server&word_in2=%82%A9%82%AB... http://www2.alc.co.jp/ejr/index.php?word_in=printer&word_in2=%82%A9%82%A... #英辞郎のところでしたっけ
上鍵さんが引き合いに出された部分はG.6.2-cの「なお…」の部分だと思われ ます。これは、「-er, -or, -arなどの場合は、ア列の長音であるから、この 規定 (G.6.2-c) に則って取り扱う」という意味であり、長音記号をつけても よいと規定している訳ではないと思います。G.6.2-c-1が適用されるか否かは、 私は情報系の専門分野に身を置いた事がないので解かりません。また、 G.6.2-c-2を適用すると、表G.3の「3音以上の場合、語尾に長音を付けない」 等の規定により、語尾に長音はつきません。さらに、G.6.2-c-3についても、 先ほどのgoogle trendsの結果等から、慣用的には長音なしとなると考えられ ます。
前述通り Google Trend は無視します.JIS 規格で言うと,-ry で終 わる物以外(「-er, -or, -ar〜」など)はおおよそ伸ばしても問題ないと とらえられると思いますがいかがでしょうか? 正直何でも置換的に 100% 伸ばすのは違和感があります(感覚的には例えば「データー」とか)
ちなみに Sun は口語に近い表記をするようにしているとのことです(例 えばほとんどの場合「こんぴゅーたー」「めーらー」など伸ばして話を します)
まだ問題がいくつかあるため,可能性だけの話ですが,
・日本には doc-ja プロジェクトという翻訳プロジェクトがある http://openlab.ring.gr.jp/doc-ja/cgi-bin/fswiki/wiki.cgi ・そこで Sun Microsystems は自社の翻訳メモリを解放するので使わない か? という提案をしている http://jp.sun.com/communities/users/0602/feature03.html など ・導入実績に(ある意味当たり前ですけど)OpenOffice.org がある模様 ・いくつかの OSS プロジェクト関係者が興味を持っている 場合によっては採用される可能性がある ・アカウントさえ作成すればアクセス不能にならない限り辞書はいつでも アクセスできる http://developers.sun.com/techtopics/global/technology/translation/ja-index.... http://developers.sun.com/techtopics/global/technology/translation/ja-SunGlo... ・懸案事項はライセンスなどの問題(GNU プロジェクトのデータを取り込 んだ翻訳メモリは他のライセンスで使用していいのか? など)多少ある
このプロジェクトには Fedora Project 関係者も参加をしているようです (自分的にプロジェクトなど立場とと関係なく一個人として参加している 人もいるとは思いますが)
個人的には上記だらだら書いてますけど,最近 Fedora Project 自体 での翻訳に積極的に参加できていないため(upstream でやってますが)意 見を強く尊重して欲しいとは思ってません.が,おそらく数年見てきた 中では対訳などのデータベースなど既訳的な物は
・作るのが大変.作ってる内に挫折 ・ボランティアベースでは長年継続して維持するのはかなり困難.結局 放置みたいなのが多い(Fedora JP 含む)
が多いと思います.その辺様子を慎重に見なければいけませんが,Sun の翻訳メモリは既に充実していること,それを使用した翻訳環境も充実 していることなどから慎重に様子見をする必要がありますがメインに参 照するようにすると手っ取り早いと思います.
#興味がある人は賛否ともに簡単にでも出してもらえるといいんじゃないかと
最後に一応 Sun のツールの実行画面のキャプチャーです.
http://elf.no-ip.org/~elf/junk/sungloss-01.png
#キャプチャーしたことで苦情が来たら削除するかもしれません.あしからず
trans-ja@lists.fedoraproject.org