そのうち何か書こうと思っているうちに、1年以上放置していました。いろいろ思うことはあるのですが、大体は過去に書いたことなんですよね。最近も、ある案件のフィードバックに書かれていた推奨訳が「柔軟性を提供します」式の逐語訳でした。こちらはあれこれ考えてそれらしい日本語にしたのに……1年前も同じことを書いていますね。
それだけならともかく、「原文に忠実に訳せ」というご指導があったのでびっくりしました。そういう訳し方をする人がいるのは知っていますが、そう訳せと明言されたのは初めてです。英語と日本語はまったく違う言語なのに、単語単位で置き換えたところで「忠実に」訳せるわけがありませんよね。日本語には定冠詞も不定冠詞も前置詞も関係代名詞もないし、日本語の助詞は英語にはありません。さすがに言っていることがナンセンスすぎるので抗議したら、翻訳会社の人は理解してくれたようですが、どうもそういうレビュアーは一人だけではないらしいのでこの先も不安です。そういう訳し方ってどこで教わったのだろう？
中間ベンダーによるレビューの意義
最近では、私のところにくる翻訳の仕事のかなりの部分が、ソースクライアント→MLV→日本国内の翻訳会社→私という流れになっています。間にMLVが入っても入らなくても、直接の取引先である翻訳会社との仕事のやり方はほとんど変わらないのですが、時々MLVからのフィードバックというのを見せられて、これに合わせてくださいと言われて困ってしまうことがあります。なぜなら、フィードバックに書かれている推奨訳が変な訳だったりするからです。どのように変かというと、これまでにここに書いたような感じのものです。
MLVのレビュアーといっても、特別なスキルがあるとは限りません。日本オフィスのシニアトランスレーターといった肩書きの人ならば、それなりにスキルが高く、レビューにも責任を持てるでしょう。しかし最近では、外部の翻訳者にレビューを委託していることもあるようです。なぜなら、私もそのような仕事を頼まれたことがあるから。日本語へのローカライズ案件であっても、そのMLVの日本オフィスを通さず、MLVの海外オフィスから日本国内の翻訳会社に翻訳作業を委託することも最近は多いようです。MLVとしては、完全に丸投げというわけにもいかないので、レビュアーを探してきてサンプルチェックをさせるわけですね。でも限られた時間でのサンプルチェックで、本当に品質を保証できるのでしょうか？
レビュアーに与えられる時間はせいぜい2〜3時間なので、背景情報などを知る余裕はありません。それでドキュメントの一部だけを読んで、訳が正しいかどうかを判断できるのでしょうか。こちらがあれこれ考えて決めた訳が、「原文にcanがあるのに訳は『できる』になっていない」だの「afterの訳が『〜の後』でない」だのといった理由でエラー扱いされているとがっくりします。推奨訳が明らかな誤訳だったこともあります。
二次ベンダーとしては、一次ベンダーであるMLVが「お客様」なので、「お客様の好み」に合わせるのは当然だし、一度指摘されたエラーを繰り返してペナルティをくらったら大変です。だから二次ベンダーをやっているような翻訳会社は、フィードバックの内容が多少変でもそのまま受け入れるのでしょう。いつも疑問に思っていた、変な訳が流行する理由は、この辺にあるのかもしれません。でも私自身は、理不尽なエラー判定を黙って受け入れるわけにはいかないので、反論の機会があればきっちり反論します。間に入る翻訳会社には手間をとらせて申し訳ないと思いますが。
MSスタイルのカタカナ複合語表記と分かち書き
http://news.mynavi.jp/articles/2012/09/28/ms/001.htmlに
続いてSpecial Keynoteでは米マイクロソフト コーポレートバイスプレジデント サーバー＆ツール マーケティンググループの＊＊＊氏が登壇。
という文章がありました（お名前を晒すのが目的ではないので「＊＊＊」で置き換えました）。写真のキャプションも
となっています。
これをMSスタイル（カタカナ複合語をスペースで区切る）で表記してみると、
となってしまって、どこが区切りなのかよくわからないことになってしまいます。
こんなこと、IT翻訳に関係ないだろうと言われるかもしれませんが、ソフトウェアの事例紹介のドキュメントに人名と会社名や組織名が並べて書かれていることはよくあります。会社名や人名は原文ままで良いことがほとんどですが、組織名や役職名はそうもいかないので、そのままカタカナ表記することになります。私が仕事で受け取る「スタイルガイド」って、ほとんどはマニュアルのことしか想定していないので、こういうときに困るんですよね。
役職や組織名は固有名詞なので、本人の名刺での表記が「コーポレート バイス プレジデント」になっているのであればそれに合わせるという考え方もありますが、元々日本語にない表記を取り入れるのは、個人的には反対です。
やっぱりカタカナ複合語の区切りはいらないと思う
オンサイトの仕事をしていると、小さめの案件が次々にやってきますが、相変わらず表記スタイルをはじめとする、細々とした指示に振り回されてばかりです。こんな細かいことをいったい誰が気にしているのか。「もうやめよう」と言いたい。
なかでも面倒なのが、カタカナ複合語の区切りです。ご存じのとおり、IT翻訳業界には
という3通りの表記スタイルがあります。後の2つは基本的に、英語の単語の区切りに合わせてスペースまたは「・」を入れるというものですが、それだけで済まないのがIT翻訳業界です。「原文で2語がハイフンでつながれていたら日本語でも区切りは入れない」という規則に従った結果、訳文の中で「エンド・ユーザー」と「エンドユーザー」が混在していたということはよくあります。さらに、「お客様の好み」で、特定の複合語は区切りなしで表記することになっていたりします。たとえば、「メール・アドレス」ではなく「メールアドレス」という指示ですが、それが用語集に反映されていればまだましで、MS Word形式の翻訳指示書の中やExcel形式の「フィードバック集」に書かれていたりします。それをうっかり見落とすと、クライアントのQAでエラー扱いされて翻訳会社の評価にかかわるという話もあるそうですが、このようなことに費やすエネルギーが、正直いってもったいないと思います。
日本翻訳連盟の標準スタイルではそこのところがどうなっているかと思って『JTF 日本語標準スタイルガイド（翻訳用）第 1.1 版』を見てみたら、
JTF スタイルガイドを作成するにあたり、カタカナ複合語の上記 3 種類の表記方法のうち、現時点では「(3)*1何も挿入しない」表記方法を使用しないことにしました。理由は、語に区切りを入れないと、機械翻訳時に未知語を判定しづらい場合があるからです。
となっていましたが、「機械翻訳時に未知語を判定しづらい場合がある」という理由にびっくりしました。この仕事を10年以上やっていますが、現場でこのようなことを聞いたことは一度もありません。私が扱うのは英語から日本語への翻訳ですので、日本語に訳したものをさらに機械翻訳にかけるということは考えにくいです。もし「機械翻訳時に未知語を判定しづらい」ことが本当に問題になるのであれば、日本語で文章を書く人全員がカタカナ複合語に区切りを入れなければなりません。私が書いているようなことは、スタイルガイドを決める前の議論の場でも出ていると思われますので、これ以上は書きませんが、やっぱり区切りはいらないと思いますよ。外国語のカタカナ表記である（カタカナ語として定着していない）場合だけ入れれば十分だと思います。だって、上記のルールが書かれているドキュメント自体も「スタイルガイド」ですし。
*1:本来は丸付き数字
「モバイルスタイル」をいつまで続けるのか
http://www.microsoft.com/Language/ja-jp/StyleGuides.aspxでダウンロードできる日本語スタイルガイド（Windows Phone用）に
Do not use spaces between double-byte and single-byte characters.
Do not use spaces between katakana words.
という規定があります。これは一体、何のためでしょうか。
私自身の経験では、マイクロソフトではないクライアントからの「モバイル」案件で、これと同じような指示を受けたことがあります。通常のWebページでは
この Web ページは、携帯電話 (スマートフォンを含む) でも表示されます。
と表記しますが、モバイル用の場合は
このWebページは、携帯電話(スマートフォンを含む)でも表示されます。
と表記しろということです。なんでも、モバイルデバイスは表示領域の大きさの制限があるので、不要なスペースは入れるなということです。いつもスペースを入れているのは見やすさのためらしいのですが、モバイル向けでは見やすさはどうでもいいのでしょうか。
「表示領域の大きさの制限」が問題になるのは、スマートフォン以前の携帯電話まででしょう。今時のスマートフォンでは、文字間のスペースを削除したところで表示できる情報量は大して変わらないはずです。モバイルデバイスのサイズも最近ではいろいろあり、タブレットも「モバイル」に該当するとなると、同じぐらいの画面サイズのウルトラブックがPCに分類されるのはナンセンスな感じもします。
それ以前に、モバイルでの表示用の調整をテキストデータ作成の時点で人力でやるという、馬鹿馬鹿しい作業をいつまでも続けているのが不思議です。このブログも、スマートフォンからアクセスすると、PC版とは異なるレイアウトで表示されますが、別に私が特別なことをしているわけではありません。コンピューターで自動化できることはどんどん自動化するのが当然ですが、その逆を行くのはローカリゼーション業界ぐらいなものでしょう。モバイルに限らず、全角文字と半角文字の間にスペースを入れるだのという「スタイル」の指示に振り回されるのも相変わらずですし。
IE9の「アドオンを無効にすることで、閲覧の速度を上げます」
Internet Explorer 9を使っていて腹の立つことの一つが、いきなりウィンドウの一番下に現れる「アドオンを無効にすることで、閲覧の速度を上げます。」というメッセージです。二度と現れないように設定できるのですが、オンサイトの仕事で真新しいPCをあてがわれることがあり、何度も遭遇してしまいます。私の嫌いな「することで」が使われているというのもありますが、何を言いたいのかわからないのでいらいらします。「速度を上げます」という述語に対応する主語がないので、これではただのひとりごとです。速度を上げるという動作の動作主は誰なのか。
http://www.microsoft.com/Language/ja-jp/Search.aspxでこのストリングを検索してみましたが、英語では「Speed up browsing by disabling add-ons.」です。ブラウザの動作が遅かったらアドオンのせいかもしれないのでオフにしてみてねということですよね。by ...ingを後ろから「〜することで」と訳しているケースはIT翻訳の世界ではよく見かけますが、いつまでこういう「忠実な訳しかた」に縛られないといけないのでしょうか。ITの英語は特殊という説もあったようですが、IEには特殊な英語が使われているのでしょうか。そんなことはありませんよね。
Visual Studio 2012の日本語ドキュメントが何となく変
調べ物をするためにGoogleで検索していたら、http://msdn.microsoft.com/ja-jp/library/vstudio/ee847415.aspxの
依存関係グラフを最初に生成すると、Visual Studio は、検出されたすべての依存関係のコード インデックスを作成します。
という文章がヒットしました。これを見て最初に思ったのは、最近のマイクロソフトは堂々と無生物主語＋能動態を使うようになったんだなあということです。人間の操作に応じてソフトウェアがどう動くかを述べるときに「Visual Studioは〜を作成します」と表現するのは、やってはいけないことの筆頭としてスタイルガイドに書かれていたりするものですが、時代が変わったのだろうか。
しかし、他の部分も見てみると、何だか全体的に変です。たとえば、前述の文の段落全体を見てみると
依存関係グラフを最初に生成すると、Visual Studio は、検出されたすべての依存関係のコード インデックスを作成します。 このプロセスにかかることがあります。ただし、多くのリンクを含む大規模なソリューションまたはグラフの時間、特に、インデックス、新しい操作のパフォーマンスが向上します。 コードが後で変更すると、Visual Studio は、更新されたコードだけにインデックスが付け直されます。
などとなっています。他のページでも
http://msdn.microsoft.com/ja-jp/library/vstudio/fda2bad5
ツールのスイートを Visual Studio 2012で使用する、Visual Studio Team Foundation Serverとこれらのツールを組み合わせることによって、理解の顧客ニーズのコード設計および実装に配置することで、アプリケーションのライフ サイクルを管理する認定練習を適用できます。 これらのツールにチェックインされたコード、および条件に基づいてテスト結果を追跡するにはインストルメンテーションを使用できます。 これらの練習は、チームが評価される顧客によってより迅速により、信頼性、ソフトウェアを作成することができます。次の結果を満たすためにこれらのツールを使用できます:
といった調子です。
これはどうみても、日本語ネイティブが書いたものではありませんね？ 機械のしわざではないかとにらんでいますが、機械翻訳の免責が見当たりません。こんなのを掲載したままだと企業イメージダウンになりそうですが、大丈夫でしょうか。それどころか、読んでいるほうの頭がおかしくなりそうです。
