Com2 Blog

翻訳とWeb制作を基礎から分かりやすく学ぶ

ソースクライアント様へ UI文字列翻訳を最適に行うために

dear-client

ソフトウェアやアプリケーションを開発するとき、翻訳会社への打診はいつごろしていますか。原文の英語はご自分で訳していませんか。

まずはよくある現実のはなし

MLVにいる私がお話しを頂くタイミング

翻訳開始の1か月ほど前にお話しを頂くことが多いと思います。開発当初からからむものは別として、翻訳だけの案件の場合はこんなものでしょうか。

では、1か月前に頂く情報はどのようなものがあるでしょうか。

  • 案件名(未定の場合もあり)
  • 内容(どのようなソフトウェアやアプリケーションか)
  • 言語(未定の場合もあり)
  • ボリューム(だいたいのワード数や文字列数、未定の場合もあり)
  • スケジュール(変更の可能性あり)

言語とだいたいのボリュームが分かり、受注の可能性が高い場合は、この段階で翻訳者の予約をします。しかし、言語が未定であれば当然予約はできません。ボリュームが分からない場合は、情報は出せますが、翻訳者の予約は不確かなものとなります。翻訳者だってあいまいな情報で日程を空けておくよりは、他の確実な仕事を取るでしょう。

データを頂くタイミング

データを頂く日が作業開始日であることは多いです。また、そのデータはExcelファイル一つであることも多いです。

データを頂いてから、原文に分かりにくいものはないか目を通します。とくに文字列が短い場合は誤訳の危険性が高くなります。また、文字列についての情報が記載されているかも確認します。メニュー、ボタン、項目名、メッセージなどの使用用途や、文字列に対する説明の有無などです。分かりにくいものや情報が不足している場合はクライアント様に確認します。

ここでお気づきかもしれません。そう、作業開始日に、頂いたデータを確認していることです。作業期間はその分削られます。またクライアント様に確認する場合、回答を頂けるまでの時間も容赦なく過ぎてゆきます。

原文に問題はないか?

日英翻訳をクライアント様がされて、その英語が原文だったとします。分かりにくい、英語として間違っている、また理解できないレベルということもたびたびあります。

翻訳作業期間であって、原文の見直しを業務として受けているわけではなくとも、翻訳に支障がある以上は、質問をしたり、翻訳会社で英語の代替案を提示して「このような意味でしょうか」「こんな感じで訳して問題ありませんか」などとフォローすることもあります。費用は発生しないこともありますし、作業期間も延長されないこともあります。

「英訳から任せて頂ければ」と思うものです。

納期は延期できるか?

翻訳の作業開始日、すでに納品日と、クライアント様での組み込み検査日程、製品への組み込み日程など、すべてが決まっています。開発日程に余裕があれば、多少日程の後ろ倒しも可能でしょうが、たいていゆとりなどありません。納期は変更不可であることは多いです。

作業開始日に初めてデータを目にし、不明や問題が見つかった場合、いったいどこで吸収するのでしょうか。

翻訳品質は確保できるか?

納期は延期されず、かといって翻訳量が減るわけでもない場合、そのしわ寄せはどこへ行くでしょうか。翻訳者と翻訳会社です。

翻訳者は不明点を質問し、回答を待ちます。待っている間にも時間は過ぎ去ります。納期ぎりぎりに回答があった場合、それから急いで翻訳、あるいは見直しを行います。

翻訳会社も同様です。質問をまとめ、クライアント様へ送付し、頂いた回答の内容を確認してそれを分かりやすく噛み砕いて英訳(たいていクライアント様とのやり取りは日本語のため)、それを各国語翻訳者へ送付。回答が遅れれば、申し訳なさから、その分少しでも、数時間でも納期を延ばします。翻訳者から納品された後の確認作業は、それは大変です。すでに時間がどんどん削られているためです。

このように、翻訳者と翻訳会社、いずれも作業に余裕がなく、よい品質を確保できるでしょうか。間違いのないように十分注意し、検査して納品しています。しかし、もしかしたら文字単位で見れば誤訳ではないかもしれませんが、コンテキストに合わない翻訳が仕上がるということも考えられます。

理想

次に、理想的な流れについてお話しします。

翻訳会社に打診するタイミング

早い方がよいでしょう。可能であれば開発日程を立てる段階で、翻訳会社に打診をします。

開発の計画段階では、まだ不確定要素は多いかもしれません。例えば、言語の展開はどうするか、どのくらいの文字列数になるか、など。それでも、どのようなソフトウェアやアプリケーションなのか、いつごろ日英翻訳をして、いつごろ多言語を完成しなければいけないか、まずは打診をし、相談してみることです。

一般的な内容であれば、さほど問題ないかもしれませんが、新しい概念のソフトウェアやアプリケーションの場合、翻訳者にその内容を理解してもらうためにはどのような材料が必要か、翻訳会社から助言がもらえるはずです。その材料をそろえるにはいつ何をするか、また翻訳会社に協力してもらえることはないか、など早い段階から調整し、短い翻訳期間での翻訳作業を不明や問題もなく進められるようにするのです。

日程

翻訳期間は余裕を持つべきでしょう。

開発日程を建てている間から、翻訳のための材料の十分な準備が困難であることが分かっていれば、翻訳期間は長めにとるべきです。翻訳手配の後、不明点について翻訳者から質問が上がってくることが予測されます。

もし、各種画面ショットや画面遷移図、各UI文字列についての説明など、必要な情報の準備が翻訳作業開始前にできるのであれば、翻訳期間のマージンも多少抑えることができるでしょう。

とはいえ、準備をしっかりし、十分な情報を提供したのだからと言って、短納期を設定するのはお勧めできません。情報が十分にあっても、その情報を探して、読んで、理解したうえで最適な訳語を検討するのは、文章などを翻訳するのに比べて何倍も労力が必要になるためです。

原文は誰が考えるべきか

原文はとても重要です。原文が正しくて分かりやすく、そこに必要な情報もあれば誤訳のリスクを最低限に抑えることができるでしょう。

クライアント様で日英翻訳される場合、開発と多言語展開の知識を持った会社にプルーフを手配されることをおすすめします。ただし、英訳のレベルが低かったりすると、プルーファーも無駄に悩み、効率的な作業はできず、また結果として得られる品質も十分なものではないかもしれません。

可能であれば、専門知識を有する会社に英訳から手配する方がよいでしょう。その際、仕様など十分な情報を出すことは必須です。英訳の品質が高い分だけ、以降の作業もスムーズに進められる可能性は高くなります。

まとめ

翻訳を、文字列を別の言語に置き換えるだけの単純な作業と思わないこと、これが基本です。特にUI文字列はそれぞれが短く、そこから何も読み取れないこともあります。一つの単語でも複数の意味合いを持っている場合、異なる意味で捉えられてしまう危険性があることを理解することです。

また、翻訳の品質は翻訳者の能力だけではないことも理解すべきです。(もちろん、翻訳者の能力は必要不可欠な要素ですが。)正しい原文、必要な情報、十分な時間、これがないと、いかに有能な翻訳者であっても、そのUIに適切な翻訳を提供できないことがお分かり頂ければ幸いです。


コメント

コメントを残す