IT翻訳者の疑問 RSSフィード

2016-03-10

[]10年前と比べて

このブログの最初の記事を書いてから、10年以上たっていました。早いものですね。最近は1年以上放置していたので「10周年」とはいえませんが、10年前と今を比べてみたいと思います。

私自身はIT専門の英日翻訳の仕事をしていることに変わりはありませんが、仕事の内容はかなり変化しました。翻訳支援ツールを使ってバイリンガルファイルを納品することは10年前と同じですが、さすがにTrados Workbench+Wordの案件は絶滅し、TagEditorを使うことも少なくなりました。かといって使うのはTrados Studioばかりというわけでもなく、新しい翻訳メモリーツールやクライアント企業が独自に開発したツールが増えました。

私自身に限っていえば、仕事の内容が大きく変わったのはワークフロー自動化が登場したときからだと思います。コンテンツ管理システムのせいかもしれませんが、少量短期の案件が増えました。もちろんそんなのを在宅でやっていたら儲からないので、オンサイトでしかやりませんが。かつては、製品のUIにしてもWebサイトのコンテンツにしても、クライアント企業はある程度まとまった量で翻訳会社に委託していたと思いますが、最近ではファイルを変更するそばから次々翻訳ベンダーにハンドオフしているプロジェクトも多くなりました。もちろん翻訳メモリー100%マッチ分は作業対象外なので、下手すると1ファイル当たりの作業対象ワード数が1桁ということもあります。機械翻訳を使うプロジェクトだと、MTの出力は大して使えないくせに単価を割り引いてくるし。

もちろん数万ワード単位のまとまった量の翻訳案件は今でもあるので、在宅では主にそちらをしていますが、いつまでフリーでやっていけるのだろう。10年後も今と同じように仕事ができていたら、結構幸せなのではないのかなと思います。

トラックバック - http://d.hatena.ne.jp/jacquelinet/20160310

2014-08-26

[]「原文に忠実に訳せ」という指示

そのうち何か書こうと思っているうちに、1年以上放置していました。いろいろ思うことはあるのですが、大体は過去に書いたことなんですよね。最近も、ある案件のフィードバックに書かれていた推奨訳が「柔軟性を提供します」式の逐語訳でした。こちらはあれこれ考えてそれらしい日本語にしたのに……1年前も同じことを書いていますね。

それだけならともかく、「原文に忠実に訳せ」というご指導があったのでびっくりしました。そういう訳し方をする人がいるのは知っていますが、そう訳せと明言されたのは初めてです。英語と日本語はまったく違う言語なのに、単語単位で置き換えたところで「忠実に」訳せるわけがありませんよね。日本語には定冠詞も不定冠詞も前置詞も関係代名詞もないし、日本語の助詞は英語にはありません。さすがに言っていることがナンセンスすぎるので抗議したら、翻訳会社の人は理解してくれたようですが、どうもそういうレビュアーは一人だけではないらしいのでこの先も不安です。そういう訳し方ってどこで教わったのだろう?

トラックバック - http://d.hatena.ne.jp/jacquelinet/20140826

2013-07-23

[]中間ベンダーによるレビューの意義

最近では、私のところにくる翻訳の仕事のかなりの部分が、ソースクライアント→MLV→日本国内の翻訳会社→私という流れになっています。間にMLVが入っても入らなくても、直接の取引先である翻訳会社との仕事のやり方はほとんど変わらないのですが、時々MLVからのフィードバックというのを見せられて、これに合わせてくださいと言われて困ってしまうことがあります。なぜなら、フィードバックに書かれている推奨訳が変な訳だったりするからです。どのように変かというと、これまでにここに書いたような感じのものです。

MLVのレビュアーといっても、特別なスキルがあるとは限りません。日本オフィスのシニアトランスレーターといった肩書きの人ならば、それなりにスキルが高く、レビューにも責任を持てるでしょう。しかし最近では、外部の翻訳者にレビューを委託していることもあるようです。なぜなら、私もそのような仕事を頼まれたことがあるから。日本語へのローカライズ案件であっても、そのMLVの日本オフィスを通さず、MLVの海外オフィスから日本国内の翻訳会社に翻訳作業を委託することも最近は多いようです。MLVとしては、完全に丸投げというわけにもいかないので、レビュアーを探してきてサンプルチェックをさせるわけですね。でも限られた時間でのサンプルチェックで、本当に品質を保証できるのでしょうか?

レビュアーに与えられる時間はせいぜい2〜3時間なので、背景情報などを知る余裕はありません。それでドキュメントの一部だけを読んで、訳が正しいかどうかを判断できるのでしょうか。こちらがあれこれ考えて決めた訳が、「原文にcanがあるのに訳は『できる』になっていない」だの「afterの訳が『〜の後』でない」だのといった理由でエラー扱いされているとがっくりします。推奨訳が明らかな誤訳だったこともあります。

二次ベンダーとしては、一次ベンダーであるMLVが「お客様」なので、「お客様の好み」に合わせるのは当然だし、一度指摘されたエラーを繰り返してペナルティをくらったら大変です。だから二次ベンダーをやっているような翻訳会社は、フィードバックの内容が多少変でもそのまま受け入れるのでしょう。いつも疑問に思っていた、変な訳が流行する理由は、この辺にあるのかもしれません。でも私自身は、理不尽なエラー判定を黙って受け入れるわけにはいかないので、反論の機会があればきっちり反論します。間に入る翻訳会社には手間をとらせて申し訳ないと思いますが。

トラックバック - http://d.hatena.ne.jp/jacquelinet/20130723

2013-04-15

[]MSスタイルのカタカナ複合語表記と分かち書き

http://news.mynavi.jp/articles/2012/09/28/ms/001.html

続いてSpecial Keynoteでは米マイクロソフト コーポレートバイスプレジデント サーバー&ツール マーケティンググループの***氏が登壇。

という文章がありました(お名前を晒すのが目的ではないので「***」で置き換えました)。写真のキャプションも

マイクロソフト コーポレートバイスプレジデント サーバー&ツール マーケティンググループ ***氏

となっています。

これをMSスタイル(カタカナ複合語をスペースで区切る)で表記してみると、

マイクロソフト コーポレート バイス プレジデント サーバー & ツール マーケティング グループ ***氏

となってしまって、どこが区切りなのかよくわからないことになってしまいます。

こんなこと、IT翻訳に関係ないだろうと言われるかもしれませんが、ソフトウェアの事例紹介のドキュメントに人名と会社名や組織名が並べて書かれていることはよくあります。会社名や人名は原文ままで良いことがほとんどですが、組織名や役職名はそうもいかないので、そのままカタカナ表記することになります。私が仕事で受け取る「スタイルガイド」って、ほとんどはマニュアルのことしか想定していないので、こういうときに困るんですよね。

役職や組織名は固有名詞なので、本人の名刺での表記が「コーポレート バイス プレジデント」になっているのであればそれに合わせるという考え方もありますが、元々日本語にない表記を取り入れるのは、個人的には反対です。

トラックバック - http://d.hatena.ne.jp/jacquelinet/20130415

2013-03-25

[]やっぱりカタカナ複合語の区切りはいらないと思う

オンサイトの仕事をしていると、小さめの案件が次々にやってきますが、相変わらず表記スタイルをはじめとする、細々とした指示に振り回されてばかりです。こんな細かいことをいったい誰が気にしているのか。「もうやめよう」と言いたい。

なかでも面倒なのが、カタカナ複合語の区切りです。ご存じのとおり、IT翻訳業界には

    • コントロールパネル
    • コントロール・パネル
    • コントロール パネル

という3通りの表記スタイルがあります。後の2つは基本的に、英語の単語の区切りに合わせてスペースまたは「・」を入れるというものですが、それだけで済まないのがIT翻訳業界です。「原文で2語がハイフンでつながれていたら日本語でも区切りは入れない」という規則に従った結果、訳文の中で「エンド・ユーザー」と「エンドユーザー」が混在していたということはよくあります。さらに、「お客様の好み」で、特定の複合語は区切りなしで表記することになっていたりします。たとえば、「メール・アドレス」ではなく「メールアドレス」という指示ですが、それが用語集に反映されていればまだましで、MS Word形式の翻訳指示書の中やExcel形式の「フィードバック集」に書かれていたりします。それをうっかり見落とすと、クライアントのQAでエラー扱いされて翻訳会社の評価にかかわるという話もあるそうですが、このようなことに費やすエネルギーが、正直いってもったいないと思います。

日本翻訳連盟の標準スタイルではそこのところがどうなっているかと思って『JTF 日本語標準スタイルガイド(翻訳用)第 1.1 版』を見てみたら、

JTF スタイルガイドを作成するにあたり、カタカナ複合語の上記 3 種類の表記方法のうち、現時点では「(3)*1何も挿入しない」表記方法を使用しないことにしました。理由は、語に区切りを入れないと、機械翻訳時に未知語を判定しづらい場合があるからです。

となっていましたが、「機械翻訳時に未知語を判定しづらい場合がある」という理由にびっくりしました。この仕事を10年以上やっていますが、現場でこのようなことを聞いたことは一度もありません。私が扱うのは英語から日本語への翻訳ですので、日本語に訳したものをさらに機械翻訳にかけるということは考えにくいです。もし「機械翻訳時に未知語を判定しづらい」ことが本当に問題になるのであれば、日本語で文章を書く人全員がカタカナ複合語に区切りを入れなければなりません。私が書いているようなことは、スタイルガイドを決める前の議論の場でも出ていると思われますので、これ以上は書きませんが、やっぱり区切りはいらないと思いますよ。外国語のカタカナ表記である(カタカナ語として定着していない)場合だけ入れれば十分だと思います。だって、上記のルールが書かれているドキュメント自体も「スタイルガイド」ですし。

*1:本来は丸付き数字

baldhatterbaldhatter 2013/03/26 06:03 お呼びでしょうか^^;

これねー、最終形の作成に至るまでの約2年間いろんな立場の方からいろんな話が出てきました。個人的には私も「区切りなんてなくても支障ない」と思っています。
区切りがないと誤読しそうな例、なども話し合いの中で出てきましたが、そんなの文脈があればほぼ問題ないはずですし。

機械処理云々というのも、翻訳エンジンなどの能力、というかカタカナ辞書が充実すれば、たぶん問題なくなる気がします。

jacquelinetjacquelinet 2013/03/27 00:09 2年もかかってましたか。なかなか決められないものですね。

tanakatanaka 2013/04/09 15:52 JTFの田中です。「機械翻訳時に未知語を判定しづらい場合がある」の記述は、「日本語に訳したものをさらに機械翻訳にかける」ではなく、対訳コーパスを機械翻訳で使用することを想定しての記述です。誤解をまねく文章になっていて申し訳ありません。改訂時に見直します。また、区切りの有無が(機械翻訳時の)解析にどのように影響するかは、最新の研究成果をウオッチしつつ、専門家に相談していかなければならないと思っています。
JTFスタイルガイドは、区切りなしの表記を認めていないわけではありません。引用していただいた箇所のすぐ下に「上記3種類のどの表記方法を採用するかは、使用者の判断に委ねます」と書いています。一般的には、さらにその下に書いている、「カタカナ語を安易につないで長くすることはできるだけ避ける」「語の区切りを入れる方が望ましいが、区切りを多用しない」あたりがポイントかと思います。
カタカナ複合語の区切りについては、残念ながら、どんなに悩んでもいっこうに結論が出ないような気がしています。業界標準スタイルガイドの目的は、統一ルールを決めることよりも、ルールのサブセットが増えるのを防ぐことではないかと思います。今後もご意見をお寄せいただければ幸いです。

jacquelinetjacquelinet 2013/04/09 23:31 コメントありがとうございます。いずれにしましても、機械翻訳のことは機械翻訳の側でなんとかしてほしいと思います。現場では(少なくとも私は)機械翻訳のことまで考える時間があまりありませんので。

トラックバック - http://d.hatena.ne.jp/jacquelinet/20130325