IT翻訳者の疑問スマートフォン用の表示で見るIT翻訳者の疑問この広告は、90日以上更新していないブログに表示しています。2017-07-15田中千鶴香さん追悼このブログにコメントをくださったこともある(http://d.hatena.ne.jp/jacquelinet/20130325#c)田中千鶴香さんの訃報を数日前に知りました。ネットでの交流しかありませんでしたが、Tradosを使おうとするとPCがやたらとクラッシュしていた頃から活躍されていたのはよく知っています。翻訳会社に言われるまま仕事をするのではなく、翻訳者もきちんと意見を述べていくという流れができたのは田中さんの功績があるからだと思います。私などは自分のことで一杯一杯なのに、勉強会を開いたりJTFの理事を務めたり、幅広く活動なさっていて本当に頭が下がる思いでした。同業者と名乗るのは気恥ずかしくなるほど末端の存在の私ですが、田中さんが残してくださったものを忘れないようにしたいと思います。心からご冥福をお祈りします。00:00田中千鶴香さんTweet広告を非表示にするもっと読むコメントを書く2016-03-1010年前と比べて雑感このブログの最初の記事を書いてから、10年以上たっていました。最近は1年以上放置していたので「10周年」とはいえませんが、10年前と今を比べてみたいと思います。私自身はIT専門の英日翻訳の仕事をしていることに変わりはありませんが、仕事の内容はかなり変化しました。Workbench+Wordの案件は絶滅し、TagEditorを使うことも少なくなりました。Studioばかりというわけでもなく、新しい翻訳メモリーツールやクライアント企業が独自に開発したツールが増えました。私自身に限っていえば、仕事の内容が大きく変わったのはワークフロー自動化が登場したときからだと思います。コンテンツ管理システムのせいかもしれませんが、少量短期の案件が増えました。そんなのを在宅でやっていたら儲からないので、オンサイトでしかやりませんが。製品のUIにしてもWebサイトのコンテンツにしても、クライアント企業はある程度まとまった量で翻訳会社に委託していたと思いますが、最近ではファイルを変更するそばから次々翻訳ベンダーにハンドオフしているプロジェクトも多くなりました。翻訳メモリー100%マッチ分は作業対象外なので、下手すると1ファイル当たりの作業対象ワード数が1桁ということもあります。機械翻訳を使うプロジェクトだと、MTの出力は大して使えないくせに単価を割り引いてくるし。数万ワード単位のまとまった量の翻訳案件は今でもあるので、在宅では主にそちらをしていますが、いつまでフリーでやっていけるのだろう。10年後も今と同じように仕事ができていたら、結構幸せなのではないのかなと思います。翻訳者の疑問そのうち何か書こうと思っているうちに、1年以上放置していました。思うことはあるのですが、大体は過去に書いたことなんですよね。最近も、ある案件のフィードバックに書かれていた推奨訳が「柔軟性を提供します」式の逐語訳でした。こちらはあれこれ考えてそれらしい日本語にしたのに......1年前も同じことを書いていますね。それだけならともかく、「原文に忠実に訳せ」というご指導があったのでびっくりしました。いう訳し方をする人がいるのは知っていますが、そう訳せと明言されたのは初めてです。英語と日本語はまったく違う言語なのに、単語単位で置き換えたところで「忠実に」訳せるわけがありませんよね。日本語には定冠詞も不定冠詞も前置詞も関係代名詞もないし、日本語の助詞は英語にはありません。言っていることがナンセンスすぎるので抗議したら、翻訳会社の人は理解してくれたようですが、どうもそういうレビュアーは一人だけではないらしいのでこの先も不安です。最近では、私のところにくる翻訳の仕事のかなりの部分が、ソースクライアント→MLV→日本国内の翻訳会社→私という流れになっています。間にMLVが入っても入らなくても、直接の取引先である翻訳会社との仕事のやり方はほとんど変わらないのですが、時々MLVからのフィードバックというのを見せられて、これに合わせてくださいと言われて困ってしまうことがあります。フィードバックに書かれている推奨訳が変な訳だったりするからです。どのように変かというと、これまでにここに書いたような感じのものです。MLVのレビュアーといっても、特別なスキルがあるとは限りません。日本オフィスのシニアトランスレーターといった肩書きの人ならば、それなりにスキルが高く、レビューにも責任を持てるでしょう。最近では、外部の翻訳者にレビューを委託していることもあるようです。私もそのような仕事を頼まれたことがあるから。日本語へのローカライズ案件であっても、そのMLVの日本オフィスを通さず、MLVの海外オフィスから日本国内の翻訳会社に翻訳作業を委託することも最近は多いようです。MLVとしては、完全に丸投げというわけにもいかないので、レビュアーを探してきてサンプルチェックをさせるわけですね。限られた時間でのサンプルチェックで、本当に品質を保証できるのでしょうか?レビュアーに与えられる時間はせいぜい2〜3時間なので、背景情報などを知る余裕はありません。それでドキュメントの一部だけを読んで、訳が正しいかどうかを判断できるのでしょうか。こちらがあれこれ考えて決めた訳が、「原文にcanがあるのに訳は『できる』になっていない」だの「afterの訳が『〜の後』でない」だのといった理由でエラー扱いされているとがっくりします。推奨訳が明らかな誤訳だったこともあります。二次ベンダーとしては、一次ベンダーであるMLVが「お客様」なので、「お客様の好み」に合わせるのは当然だし、一度指摘されたエラーを繰り返してペナルティをくらったら大変です。二次ベンダーをやっているような翻訳会社は、フィードバックの内容が多少変でもそのまま受け入れるのでしょう。いつも疑問に思っていた、変な訳が流行する理由は、この辺にあるのかもしれません。私自身は、理不尽なエラー判定を黙って受け入れるわけにはいかないので、反論の機会があればきっちり反論します。間に入る翻訳会社には手間をとらせて申し訳ないと思いますが。マーケティンググループの***氏が登壇。いう文章がありました(お名前を晒すのが目的ではないので「***」で置き換えました)。***氏となっています。***氏となってしまって、どこが区切りなのかよくわからないことになってしまいます。こんなこと、IT翻訳に関係ないだろうと言われるかもしれませんが、ソフトウェアの事例紹介のドキュメントに人名と会社名や組織名が並べて書かれていることはよくあります。会社名や人名は原文ままで良いことがほとんどですが、組織名や役職名はそうもいかないので、そのままカタカナ表記することになります。私が仕事で受け取る「スタイルガイド」って、ほとんどはマニュアルのことしか想定していないので、こういうときに困るんですよね。プレジデント」になっているのであればそれに合わせるという考え方もありますが、元々日本語にない表記を取り入れるのは、個人的には反対です。00:00MSスタイルのカタカナ複合語表記と分かち書きTweet広告を非表示にするもっと読むコメントを書く2013-03-25やっぱりカタカナ複合語の区切りはいらないと思う翻訳者の疑問オンサイトの仕事をしていると、小さめの案件が次々にやってきますが、相変わらず表記スタイルをはじめとする、細々とした指示に振り回されてばかりです。こんな細かいことをいったい誰が気にしているのか。「もうやめよう」と言いたい。なかでも面倒なのが、カタカナ複合語の区切りです。パネルという3通りの表記スタイルがあります。後の2つは基本的に、英語の単語の区切りに合わせてスペースまたは「・」を入れるというものですが、それだけで済まないのがIT翻訳業界です。「原文で2語がハイフンでつながれていたら日本語でも区切りは入れない」という規則に従った結果、訳文の中で「エンド・ユーザー」と「エンドユーザー」が混在していたということはよくあります。「お客様の好み」で、特定の複合語は区切りなしで表記することになっていたりします。Word形式の翻訳指示書の中やExcel形式の「フィードバック集」に書かれていたりします。それをうっかり見落とすと、クライアントのQAでエラー扱いされて翻訳会社の評価にかかわるという話もあるそうですが、このようなことに費やすエネルギーが、正直いってもったいないと思います。種類の表記方法のうち、現時点では「(3)*1何も挿入しない」表記方法を使用しないことにしました。理由は、語に区切りを入れないと、機械翻訳時に未知語を判定しづらい場合があるからです。なっていましたが、「機械翻訳時に未知語を判定しづらい場合がある」という理由にびっくりしました。この仕事を10年以上やっていますが、現場でこのようなことを聞いたことは一度もありません。私が扱うのは英語から日本語への翻訳ですので、日本語に訳したものをさらに機械翻訳にかけるということは考えにくいです。「機械翻訳時に未知語を判定しづらい」ことが本当に問題になるのであれば、日本語で文章を書く人全員がカタカナ複合語に区切りを入れなければなりません。私が書いているようなことは、スタイルガイドを決める前の議論の場でも出ていると思われますので、これ以上は書きませんが、やっぱり区切りはいらないと思いますよ。外国語のカタカナ表記である(カタカナ語として定着していない)場合だけ入れれば十分だと思います。上記のルールが書かれているドキュメント自体も「スタイルガイド」ですし。words.という規定があります。これは一体、何のためでしょうか。私自身の経験では、マイクロソフトではないクライアントからの「モバイル」案件で、これと同じような指示を受けたことがあります。表記しますが、モバイル用の場合はこのWebページは、携帯電話(スマートフォンを含む)でも表示されます。表記しろということです。なんでも、モバイルデバイスは表示領域の大きさの制限があるので、不要なスペースは入れるなということです。いつもスペースを入れているのは見やすさのためらしいのですが、モバイル向けでは見やすさはどうでもいいのでしょうか。「表示領域の大きさの制限」が問題になるのは、スマートフォン以前の携帯電話まででしょう。今時のスマートフォンでは、文字間のスペースを削除したところで表示できる情報量は大して変わらないはずです。モバイルデバイスのサイズも最近ではいろいろあり、タブレットも「モバイル」に該当するとなると、同じぐらいの画面サイズのウルトラブックがPCに分類されるのはナンセンスな感じもします。それ以前に、モバイルでの表示用の調整をテキストデータ作成の時点で人力でやるという、馬鹿馬鹿しい作業をいつまでも続けているのが不思議です。このブログも、スマートフォンからアクセスすると、PC版とは異なるレイアウトで表示されますが、別に私が特別なことをしているわけではありません。コンピューターで自動化できることはどんどん自動化するのが当然ですが、その逆を行くのはローカリゼーション業界ぐらいなものでしょう。モバイルに限らず、全角文字と半角文字の間にスペースを入れるだのという「スタイル」の指示に振り回されるのも相変わらずですし。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。