大塚 玲子
Reiko****@uniad*****
2006年 2月 21日 (火) 12:33:41 JST
大塚です。 > 中黒だけ、ちょっと気になっています。 > 個人的には結構使っていたりしますので > （例：リレーショナル・データベース） > > 中黒に関しては、ガチガチに厳守というのではなく用語集で吸収する > という方法にしてもらえると助かります。 > （「Sun の日本語スタイルガイド」にはそう書いてあります） 私も気になってました。用語集で吸収に賛成です。 > OpenOfficeのほうはエンドユーザ使うツールを扱っています。 > 我々はJava EEのサーバやライブラリですから、扱っている物や > ユーザが全然違います。 > > 我々が扱うのはエンドユーザマニュアルではなく、どちらかというと > 技術文書であり、多くのの背景知識を要求されます。内容の間違いは、 > 読者のミスリードにつながるので、こまかな翻訳ルールよりは内容の > 間違いがない・少ないことを重視すべきだと思っています。 > > ですから、Ja-Jakarta翻訳スタイルガイドのような最低遵守のルール > を守った上で、ML上では、英語の話だけではなく、技術内容の確認や > 議論ができるといいかな、と思っています。原文が悪くて意味不明なら > JBoss技術者にどんどん質問メールを送っても良いでしょう。 了解です。 確かに扱っているものが違うので、内容の間違いは許されませんよね。 この件は、精神論にとどめておきましょう。 # 内容１番、ルール２番、納期３番、って感じですかね。 ********************************************* 大塚玲子 <Reiko****@uniad*****> ユニアデックス株式会社 ソフトウェアプロダクト統括部 (A13-S) サーバソフトウェア２部 第３グループ TEL: 03-4329-1770 FAX: 03-5546-7842 ********************************************* Fusayuki Minamoto wrote, On 2006/02/21 12:15: > 皆本です。 > >>> Ja-Jakarta翻訳スタイルガイド: >>> http://www.jajakarta.org/site/rules.html >> とりあえずこれは全部（Apache Software License以外）採用で >> いいのでは。そんなに難しいことでもありませんし。 >> （「HTMLファイル内の改行位置」が面倒そうですが。） > > 私としては原則OKです。 > > JBossサーバに取り込まれるサービス(ex. Tomcat)はJakarta > のルールでリソースが書かれていますので、整合性を保つ上 > でも好ましいでしょう。 > > -- 以下細かな話です -- > > 中黒だけ、ちょっと気になっています。 > 個人的には結構使っていたりしますので > （例：リレーショナル・データベース） > > 中黒に関しては、ガチガチに厳守というのではなく用語集で吸収する > という方法にしてもらえると助かります。 > （「Sun の日本語スタイルガイド」にはそう書いてあります） > >>> Sun の日本語スタイルガイド - Sun Japanese Style Guide: >>> http://jp.sun.com/communities/users/0602/feature03.html >> こちらも参考になりますが、あまり決めすぎると大変そうなので >> あくまでも参考が良いかと思います。 > > もちろん「参考」です。 > > でも、たいへん得るものが多いので時間のあるときに一読をお勧めします。 > （これを読んで、自分が文語調で書いていたことに気づきました..) > >>> 私のイメージはOpenOffice翻訳プロジェクトに近いです。 >>> http://ja.openoffice.org/tr/index.html >> ここで気になったのは以下の２点です。 >> >>> ・ベース翻訳作成時に分からなかったところは，訳注を付けておく。 >>> （査読の時は基本的にその訳注の付いた部分をチェックし， >>> その他については日本語として問題ないか程度のチェックをする。） >> 採用したいです。 > > そうしましょう。 > > 技術文書ではわからないところを無理やり訳すのは読む人の迷惑です。 > 訳注に、「原文」or「原文へのポインター」も残してもらえるといいかと > 思います。 > >>> ・翻訳の速度重視で。完璧な資料を作るよりは，同じ時間で8割方完成の >>> 資料をより多く作る方向で。 >> これはどうですか？なるほど、と思ったのですが。 >> （完璧は所詮無理なのですが）あまり悩まずとりあえず公開を >> 目指すのはいいと思いました。 >> 個人差がありますので、精神論っぽいですけど。 >> ただ、今は試行錯誤でやり始めたところなので、個人的には >> 軌道に乗るまではきっちりやりたいです。 >> いずれこれも採用したいな、と思いました。 > > ゴメンなさい、OpenOfficeの引用をしたのは、精神論的な > ところで共感するところが多いというだけで、これを100% > 踏襲しましょう、というつもりではありませんでした。 > > 速度か品質かというのは、議論のポイントだと思います。 > 以下、とりとめの無い話になってしまいますが... > > OpenOfficeのほうはエンドユーザ使うツールを扱っています。 > 我々はJava EEのサーバやライブラリですから、扱っている物や > ユーザが全然違います。 > > 我々が扱うのはエンドユーザマニュアルではなく、どちらかというと > 技術文書であり、多くのの背景知識を要求されます。内容の間違いは、 > 読者のミスリードにつながるので、こまかな翻訳ルールよりは内容の > 間違いがない・少ないことを重視すべきだと思っています。 > > ですから、Ja-Jakarta翻訳スタイルガイドのような最低遵守のルール > を守った上で、ML上では、英語の話だけではなく、技術内容の確認や > 議論ができるといいかな、と思っています。原文が悪くて意味不明なら > JBoss技術者にどんどん質問メールを送っても良いでしょう。 > >>>>> 校正者をどう確保するかが課題ですね。 >>> このMLメンバに校正を期待しています（駄目?)。 >>> すくなくとも私はすべてのドラフトに目を通します（キッパリ）。 >> 私も（できる限り）見ます。 >> >> # 今、OSC2006のメール見ました。3/17,18目標にがんばります！ >> > > 頼もしいです。私もがんばります。 > でも、無理せずにご自分のペースでお願いしますね。 > > > > 皆本 房幸 <miki.****@nifty*****> > http://d.hatena.ne.jp/neverbird/about > _______________________________________________ > Japan-jbug-translators mailing list > Japan****@lists***** > http://lists.sourceforge.jp/mailman/listinfo/japan-jbug-translators >
