K's Web Diary

SGML (その 3)

以前に SGML ではオブジェクト指向的な記述が必要となるということを書きましたが、これは翻訳においても要求されることがあります。

例えば、Follow the instruction in the step above.  という文章があった場合、「上記ステップの指示に従ってください。」と訳すと、ここで言う「上記ステップ」必ず上に出ているというわけではなく、前ページであるかもしれないため、「前述したステップの指示に従ってください」というような意識が必要になります。

もちろん、元の英語が、例えば、Follow the instruction in the previous step. という具合になっているべきなのですが、なかなかそれが徹底されるのは難しいのが現状です。

つまり、SGML の Source Document を翻訳する場合には、翻訳する側にも特別な意識が必要になるということかと思います。

Posted at 12:05午後 8 13, 2007 by layla in Sun  |  投稿されたコメント[0]

SGML (その 2)

SGML でマニュアルを記述することの利点のひとつに、他のフォーマットへの変換が比較的容易にできるということがあります。

Solaris の場合も Java ES の場合も、SGML は所謂 Source Document であり、Jave ES の場合であれば、pdf, Online Help, xml, html に変換して publish されています。この中で、pdf については、xpp という処理系を使用するためかなり複雑なことが行われるのですが、その他については、比較的容易に変換することが可能です。

このため、以前は別々に翻訳を行っていた (もちろん、Translation Memory は使用していましたが) のですが、現在では、翻訳そのものは SGML に対して行うだけであり、その他のフォーマットについては機械的な作業によって生成されるようになりました。

このことは翻訳コストの削減だけでなく、表現の統一という側面でも良い結果をもたらしていると考えています。

Posted at 03:11午後 8 06, 2007 by layla in Sun  |  投稿されたコメント[0]

SGML

今日はマニュアルのフォーマットについて少し書いてみます。

現在、Solairs  と  Java ES  のマニュアルは、SGML で書かれています。これは、数年をかけて移行してきたのですが、英語版の Technical Writer にとって、これまでの WISWIG の環境からの変更には大変大きな努力が必要でした。しかし、結果として、検索性の向上、再利用性の向上など、多くの利点があります。その一方で、最終的にどのように読者に見えるかがわからないという問題もあります。結果として、プログラミングに例えると、オブジェクト指向の記述が要求されることになりました。

これを Globalization という観点からとらえると、理屈の上では、翻訳の再利用性が高まることになります。マニュアルサイドだけではどうにもなりませんが、例えば、インストールの手順が統一されれば、それに対するマニュアルの説明も常に同じになることが可能になり、しいては、翻訳も毎回同じになるわけです。

今後の課題はソフトウェア開発者と Technical Writer とのコミュニケーションを活性化し、いかにして、統一された手順を提供できるようにするかということかと考えています。

Posted at 01:59午後 7 30, 2007 by layla in Sun  |  投稿されたコメント[0]

どのマニュアルを翻訳対象とするか

さて、製品の Globalize を考える際には、翻訳の範囲をどこまでとするかが大きな課題の一つになります。極端な話にしてみると、

• 英語のまま製品として出す
• GUI のみ翻訳する
• マニュアルのみ翻訳する
• 全て翻訳する
  

などという場合もあります。

上記のようなはっきりとしたケースでは良いのですが、「一部のマニュアルを翻訳する」というような場合にはユーザーの方々の要求度合いを知った上で翻訳対象を選択したいものです。

ここで利用しているのが Sun のオンラインドキュメントサイトである

    http://docs.sun.com

です。

このサイト上で各英語マニュアルが、どこの地域 (国) からどのくらい参照されているかを調査し、その数値を翻訳対象選択の目安の一つとしています。

実際のところ、翻訳版を docs.sun.com に載せると、元の英語版への参照が減るということも見受けられますので、それなりに実用性のある指標かと考えています。

今後の方針としては、マニュアルだけでなく、マーケティング関連の情報や、White Papar 等についてもこの手法を取り入れて、ユーザーの方々がより必要としているものから優先的に翻訳してゆきたいと考えています。

Posted at 06:21午後 7 23, 2007 by layla in Sun  |  投稿されたコメント[0]

日本語は難しい？（その 2）

前回、日本語の翻訳は難しいということを書きましたが、そのあたりをもう少し考えてみたいと思います。

まず、文法的に英語と大きく異なるという点では、他の主要言語に比較すると、日本語と韓国語が飛びぬけて英語との差が大きいように思います。これは、語順もさることながら、読者に対するアプローチの仕方も異なるようです。

さらに、日本語と韓国語を比較すると、日本語の翻訳にはカタカナを訳語にあてることが多いです。これは、日本語から韓国語への機械翻訳の実験を通してわかったことなのですが、日本語ではカタカナを訳語にあてた場合に引き起こされる問題が多く見つかりました。

こういう状況をふまえて、日本語には最も長くかつ、多くの工程が「レビュー」として割り当てられています。

Posted at 10:11午前 7 17, 2007 by layla in Personal  |  投稿されたコメント[0]

日本語は難しい？

最初の頃に書きましたが、私の部署では日本語の翻訳だけでなく、英語から他の言語への翻訳を担当することもあります。実際のところ、Java 関連の翻訳は、全ての言語を日本で担当しています。

そういう経験から言えることは、「日本語の翻訳は最も難しいかもしれない」ということです。もちろん、アラビア語など、記述方向の異なる言語もあり、技術的な側面まで考慮すると一概には言えません。ただ、Linguistic  な側面に焦点をあてると、他の言語と比較した場合、日本語特有の問題が多々あることに気づきます。

文法上の差異が英語と比較した場合に大きいこともさることながら、英語と日本語の混在を許したり（私のこの前の文でも "Linguistic" という単語を挿入していますが）、カタカナの用語を訳語としてあてたりすることも、複雑さを助長しているのかもしれません。

現在は、このような言語間の差異を考慮して、翻訳レビューのガイドラインを各言語別に用意し、同時にレビューの工程も個別に対応するなどして品質の安定を図っています。

Posted at 01:58午後 7 09, 2007 by layla in Personal  |  投稿されたコメント[0]

翻訳とテクノロジー (Machine Translation その 2)

Machine Translation (MT) につていは、もう一つ別のアプローチの調査もしています。それは、日本語から韓国語への翻訳に利用することです。

この 2 つの言語は文法構造が似ており、英語からの翻訳に比較すると、かなり品質の良い翻訳結果を得ることができます。現在、Sun の多くの製品では、日本語に翻訳されていて、韓国語には翻訳されていないというものが多々ありますので、こういったドキュメント、情報の翻訳に、日韓機械翻訳を利用することによって、少しでもローカライズされた情報が増やせればと考えております。

もちろんこれは、日本語と韓国語に限った話しではなく、Simplified Chinese と Traditional Chinese であるとか、Spanish と Italian というのも視野に入れて検討されています。

MT と言うと、どうしてもコストの削減ということに主眼が置かれがちですが、私が主に考えているのは、ローカリゼーションの拡大とスピードアップへの使用ということになります。

Posted at 10:07午前 7 02, 2007 by layla in Sun  |  投稿されたコメント[0]

翻訳とテクノロジー (Ｍａｃｈｉｎｅ　Ｔｒａｎｓｌａｔｉｏｎ)

以前にこのブログで Control English のことを書きましたが、やはりその先には Machine Translation (MT) を可能にしたいという希望があります。一般的には、Corpus と呼ばれる翻訳データベースを利用した MT と、構文解析を主とする MT とがあります。Sun の場合には、Translation Memory を既に導入しており、ある程度の翻訳データベースが存在しますので、Corpus ベースの MT に注目しています。

といいましても、最も注目している利用方法は、現在の翻訳に代わるものとしてではなく、現在翻訳できていない情報の翻訳に利用できないかということです。すぐに考えられるものとしては、Sun のマニュアルサイトである http://docs.sun.com/ に、On-The-Fly で翻訳できる翻訳スイッチを組み込んで、不完全ながらもなんらかの翻訳を提供できるようにすることなどです。

とりわけ、最近の調査では、「タイムリーに情報が欲しい」という要求が多く寄せられていますので、http://docs.sun.com/ に限らず、その他の情報発信サイトにもこのようなしくみを搭載できればと考えています。

Posted at 01:02午後 6 25, 2007 by layla in Sun  |  投稿されたコメント[0]

翻訳とテクノロジー (Control English)

私の所属している Globalization Group では、SunProof というツールを開発し、これを英語版のテクニカルライターに使用してもらうよう、働きかけを続けています。

SunProof というのは、簡単に言うと、英文をチェックするツールなのですが、そのチェックが「翻訳のしやすさ」という側面にも重点を置いて設計されていることに特徴があります。基本的には解りやすい英文であれば英語マニュアルのユーザーにとっても、翻訳者にとっても理解しやすいわけですが、

• 長い英文
• 辞書に無い単語
• 複雑な構文
• 関係代名詞の使用
• 曖昧な形容詞の使用
  
• Spelling ミス
• 文法的誤り

などを認識した際に、テクニカルライターに対して Warning を出すものです。現在では Solaris  を中心に、徐々にその使用が拡大しています。

将来的には英文が翻訳しやすくなり、機械翻訳にも耐えられるまでになれば良いのですが、それにはまだまだ時間がかかりそうです。

Posted at 11:35午前 6 18, 2007 by layla in Sun  |  投稿されたコメント[0]

翻訳とテクノロジー (Glossary)

用語の統一というのは、翻訳において重要な要素の一つであり、品質という側面からも効率という側面からも日々改善が必要となります。理想としては、一つの英語の用語に対して、一つの翻訳を決定できれば良いのですが、ソフトウェアだけを見ても、Solaris, Jave, Sun Studio など、様々なユーザーを対象として製品があり、さらにハードウェア製品もありますので、全ての製品ラインで同じ翻訳をあてるということは困難です。

Sun では、SunGloss という用語管理ツールを開発しており、これを使用することで、できるだけ用語の管理を容易に正しく行いたいと考えています。( SunGloss について興味のある方は http://developers.sun.com/global/technology/translation/ja-SunGlossTips.html を参照してみてください)

新しい技術が開発されると、必ずそれにまつわる新しい用語が出現します。また、その新しい技術は、複数のプロジェクトから利用されるため、複数のプロジェクトのドキュメント等に同時期に出現します。

このような場合、個別に動いているプロジェクト間で用語の統一をするためには、SunGloss のようなツールの存在だけでなく、その内容をできるだけ迅速に更新していくことが必要です。このあたりの対応をどうするかが現在の課題となっています。

Posted at 09:57午前 6 11, 2007 by layla in Sun  |  投稿されたコメント[0]

翻訳とテクノロジー (Translation Memory)

ほとんどの場合、翻訳には改訂がついてまわります。従来は、差分を探して、その部分を翻訳して、旧版を変更してということを、「手仕事」で行っていたわけです。しかし今では、いわゆる Translation Memory (TM)
を使って、翻訳の再利用を自動化しています。

Sun では自社開発した TM と市販の TM とが共存する形で運用していますが、将来的には一つに統合できればと考えています。

現在の TM はかなり信頼性が上がっており、作業効率的に見た場合、もはやなくてはならないツールになっています。しかし、各種の新しいファイル形式への対応、Context Sensitive ではないために発生する誤訳 (特に日本語の場合には問題が大きいことがあるのですが) など、メインテナンスや、再利用の品質を考えた場合には、まだまだ改善の余地があります。

日本語の場合に限って言えば、「より良い翻訳」を「より早く」、「より多く」ということが期待されているわけですが、最近の傾向では 1. より早く 2. より多く 3. より良くという期待順になっているようです。

 こういった要望に応えるべく TM も導入、拡充させていくわけです、現段階では「英語を素直に翻訳する」という方向にそって、TM の利用を行っています。

Posted at 11:27午前 6 04, 2007 by layla in Sun  |  投稿されたコメント[0]

翻訳の品質管理 (その 3)

翻訳に限らず、品質を管理するにはあらかめ目標値を設定する必要があります。これが翻訳の場合、一般に基準書などと呼ばれるものになるわけですが、Sun ではこれを Style Guide と呼んでおり、各言語毎にあります。

日本語の場合、当初、書き下ろしマニュアルを作成することに主眼を置いて作成した「マニュアル基準書」というものがありました。そして、それに手を加えることで Style Guide の第一版を作成しました。このため、翻訳の目標品質という見方をした場合、内容が複雑、多岐になってしまいました。その結果、達成不可能な期待値を設定し、それを参照しながら翻訳品質を判断するという無理が生じてしまいました。

そこで、ある時期に、Style Guide を翻訳の品質基準を設定するものとして見直し、従来あったものに比較して、大幅に簡略かつ明確にしました。この結果、「英文の内容を忠実に翻訳する」という目的に近づいた Style Guide を翻訳者さんに対して提示することが可能になり、翻訳品質のばらつきを抑えることが可能になりました。

Style Guide そのものは常に更新される Live Document ですので、どうしても複雑、多岐になりがちなのですが、「英文の内を忠実に翻訳する」という目的から大きく逸脱することがないように心がけて、改訂、改良を継続しています。

Posted at 01:22午後 5 28, 2007 by layla in Sun  |  投稿されたコメント[0]

翻訳の品質管理 (その 2)

翻訳の品質管理ということで言えば、もうひとつ力を入れていることがあります。以前は、印刷した紙に赤入れすることで翻訳のチェックを行っていたのですが、現在では、ほとんどの場合、原文、修正前、修正後をスプレッドシートに入力して、翻訳会社さんへフィードバックするようにしています。

これには主に二つの理由があります。

一つは、前回書きましたように、翻訳で発生したエラーを数値化していますので、数値化のための集計に都合が良いこと。

もう一つは、チェック結果を翻訳会社さんだけでなく、実際の翻訳者さんまで届けるためです。

この二番目は特に重要で、実際に翻訳にあたる翻訳者さんのスキルを高めると同時に、こちらがどんな翻訳を望んでいるかを明確にすることができます。

紙に赤入れすることに比較すると、スプレッドシートに記入する方法は手間がかかるため、チェックの効率だけを考えた場合には、大変になるのですが、元々の翻訳の質を高め、継続的に翻訳の品質を安定させるためには有効かつ必要なことであると考えています。

また、翻訳エラーの中には、元の英語に問題がある場合も少なくなく、そういったケースを後で検証し、英語版のテクニカルライターにフィードバックすることにも役だっています。

Posted at 10:29午前 5 21, 2007 by layla in Sun  |  投稿されたコメント[0]

翻訳の品質管理

翻訳の全てを外部に発注している場合、一番の問題はいかに一定の品質の翻訳を、外部の翻訳会社さんに提供してもらえるかということになります。

全ての翻訳に目と通すことが理想ではあるのですが、それは現実的に不可能です。

そこで、部分検査（サンプルチェック）ということになるのですが、Sun では、日本語に限らず、ここの工程に一工夫しています。簡単に説明しますと、翻訳エラーの出現した箇所の重要性と出現頻度を数値化して、納品された翻訳全体にどの程度の翻訳エラーリスクがあるかを計算して、その値によって、そのまま製品化して良いか、さらにチェックが必要かを判定しています。

確かにこの方法ですと、翻訳エラーの可能性は常に存在することになるのですが、膨大な量の翻訳を一定の品質で提供するためにはやむを得ないところかと考えています。

 現在の課題は、「どのくらい悪い翻訳か」を評価するだけでなく、「どのくらい良い翻訳か」も評価する方法を取り入れて行くことかな？と考えています。

Posted at 03:39午後 5 14, 2007 by layla in Sun  |  投稿されたコメント[0]

Prologue (プロローグ)

Blog を始めようと手をつけてはみたのですが、さて、何から書こうかと考えました。
私は Sun で Globalization という組織に所属しているのですが、日本においてどのような業務が行われているかについては、社内外を問わず、案外知られていないのではないかと思います。
そこで、私が主に担当しているドキュメントの Localization (ローカリゼーション) あたりから、あれこれと書いて行こうかと思います。

私の所属している部署は、Globalization の中の、TLIS (Translation and Language Information Services) と言う部署です。ここでは、Sun の製品に付属しているマニュアル、ソフトウェアの Localization に必要なメッセージファイル、一部のマーケティング資料等の翻訳を主な業務としています。翻訳と言っても膨大な量になりますので、社内での仕事は、工程管理、品質管理、コスト管理、工程の改善が中心です。

あまり知らせていない点としては、TLIS という組織そのものが Globalize されている (世界の各地に拠点があり、それらの拠点の担当者が連携して Localization を行っている) ため、日本で日本語以外の翻訳プロジェクトを動かしている場合も、他国の拠点で日本語の翻訳プロジェクト (正確には日本語の翻訳を含むプロジェクト) を動かしている場合もあるということです。いずれの場合でも品質管理については、その言語に最もふさわしい場所 (日本語であれば日本) で行います。

 このような状況の中で出てくる様々な事についてこれから書いて行こうと思いますので、「こんな事が知りたい」ということがありましたら、コメントをお寄せください。

つたない文章ですが、今後ともよろしくお願いします。

Posted at 05:32午後 5 07, 2007 by layla in Sun  |  投稿されたコメント[0]