ソフトウェア」タグアーカイブ

意外と知らない翻訳の注意点

意外と知らない翻訳の注意点

これまでのお取引の中で、共通している「翻訳・ローカライズ作業前のご注意点」についてまとめております。

業種問わず、共通するケースをご参考にしていただき、スムースな翻訳、ローカライズのお見積り、ご発注を実現してください。
特に翻訳お見積り時とご発注前後に見られる、意外と知られていない点をお知らせします。

翻訳は、「1 文字いくら、1 ワードいくら」の世界

翻訳、ローカライズというビジネスの基本は、「1 文字いくら、1 ワードいくら」をベースとして成り立っています。基本的にこの方法にてお見積り金額やスケジュールの算出を行っております。

そのため、ご発注後に翻訳対象原稿が変更になってしまうと文字数やワード数をカウントしなおす必要が出てきます。 これはつまり、

・翻訳見積もり金額の変更

・翻訳スケジュールの変更

に直接影響を与えることになります。

それはダイレクトに貴社へのチャージという形になりますので、このようなことを避けるためにも、翻訳対象原稿の変更はできるだけ少なく、翻訳会社への連絡前に、できれば確定させるぜひともご注意いただきたい点の 1 つとなります。

弊社としましても、このような事態は極力避けるべく、ご確認をさせて頂いておりますが、予期せぬ翻訳対象原稿の変更の連続は、コストやスケジュールだけでなく、翻訳そのものの品質にも影響を与えてしまうことがあります。

ご発注後にスムースに翻訳作業を進めるために、ぜひとも貴社にて翻訳対象原稿の再度のご確認をお願いいたします。

※紙原稿しかない、画像ファイルしかない場合にはこの限りではありません。

PDF ファイルと元データのバージョンが違う

「翻訳対象ファイルのバージョンが異なる」

このケースもよく見かけられます。PDF を先にお借りするケースで「バージョン違い」によるトラブルが起きることがあります。例えば、以下のような流れで翻訳のお見積りを作成する場合です。

  1. PDF ファイルをお借りする
  2. 概算翻訳お見積りを作成する
  3. PDF ファイルの元データ(InDesign や FrameMaker、Word 等)をお借りして再度正式なお見積りを作成する

概算お見積りと正式なお見積りとでは、多少の金額の差が出ることがあります。それは翻訳不要箇所などもハッキリするためですが、問題はそこではありません。

仮に PDF のバージョンが 1.0 だったとして、実際の翻訳対象ファイルがバージョン 1.1 となるマイナーバージョンアップの場合には、ほとんど見た目が同じで変更箇所に気がつかない場合があります。

ブローシャやカタログなどではあまり見られませんが、マニュアル翻訳の場合には、このケースに当てはまることがあります。つまり、

PDF のマニュアル = 元データ(InDesign や FrameMaker 等)のマニュアル

となっていない場合を指します。

通常、翻訳お見積り自体は上記の元データに基づき算出し、作業対象も当然ながら元データとなります。しかし以下のような場合には、何度かのデータの確認が必要になってきます。

パターン A
PDF ファイルのバージョン古い1 つ前のバージョン
元データ(FrameMaker、InDesign、Word 等)新しい最新のバージョン

パターン B
PDF ファイルのバージョン新しい最新のバージョン
元データ(FrameMaker、InDesign、Word 等)古い1 つ前のバージョン

このように、データ間でバージョンに違いがあると、ドキュメントの内容が異なるためカウントのやり直しやデータの確認などが発生し、スムースに翻訳、ローカライズを進めることが難しくなってしまいます。

これは貴社にとってもデメリットばかりになってしまいますので、くれぐれもバージョン管理、バージョンのご確認をお願いいたします。

弊社でも確認するようにしておりますが、原文のバージョン管理については判断材料が乏しいため、確実かどうかが不明な場合もございます。それらをベースに何度も見積を作ったり、またファイルを取り寄せたりすると時間もかかります。

できるだけこういった部分は省き、効率的に見積を作り、スピーディに業務を進めるようにしましょう。

まとめ

今回お知らせした 2つのケースは、非常に間違えやすいバージョンやファイル管理によって引き起こされます。FrameMaker(フレームメーカー)や InDesign(インデザイン)などの元データをご入手いただくタイミングや、マニュアルそのもののバージョンアップのタイミング、マーケットへのローンチのタイミング、開発元や本社との調整など、あらゆる要素が複雑に関わっているからこそ、ぜひともご注意いただきたい点でもあります。

マニュアル翻訳やローカライズ、カタログやブローシャ等の翻訳サービスにつきましては、お問い合わせよりお気軽にご連絡下さい。

 


UI を翻訳・ローカライズする時に注意したい 3 つのポイント

ui

UI とは何か

UI は「User Interface:ユーザーインタフェース」の略称です。具体的には、ソフトウェアなどでは頻繁に出現する画面のことを指します。(メニューやエラーメッセージなど)

ui3

この UI の翻訳やローカライズを行うにあたっては、通常のドキュメントの翻訳とは異なった注意が必要になります。今回は、その主な注意点をご紹介します。

UI 翻訳、ローカライズの準備

まず、作業にあたって準備が必要です。

  1. 翻訳対象原稿(ファイル形式)
  2. 専門用語集
  3. 表記スタイルガイド
  4. (必要であれば)スクリーンショットや実機インストール

 

それぞれについて見ていきましょう。

翻訳対象原稿について

これは読んで字のごとく、翻訳する対象のファイルのことです。しかしながら、UI の場合にはドキュメントとは異なり、様々なファイル形式があります。例えば、以下のような拡張子のファイルがあり、これらが対象となります。

  • .txt :テキスト形式のファイル
  • .resource:リソースファイル
  • .rc:リソースファイル
  • .xls/.xlsx:エクセルに抽出されたファイル

これらは、そのまま開いて作業することができないものもあるため、SDL TRADOS(トラドス) を代表とする翻訳支援ツールなどを使用して翻訳することもあります。

 

SDL TRADOS(トラドス)の解析アルゴリズム

 

またリソースファイルでは翻訳対象文章以外のプログラムコードが記述されているため、それらを誤って削除したりしないように注意する必要があります。

UI の翻訳やローカライズには、TRADOS だけでなく Passolo や Catalyst といった翻訳支援ツールを使用することで一貫性を保つことができます。なおこれらのツールは、上記のようなマニュアル等のドキュメントの翻訳でも効果を発揮します。

ローカライズとは

 

どんなファイル形式で原稿をお借りするかによって、使用ツールや納品形式も変わってしまいますので、翻訳会社への連絡時には、原稿のファイル形式を合わせて伝えた方が良いでしょう。

専門用語集について

用語集は、UI の翻訳やローカライズに関わらず大切です。弊社では、用語集をお持ちでないお客様向けに「用語集構築プラン」をご提供しています。

用語集構築・運用

 

専門性が高くなればなるほど用語集は重要になります。専門用語は、その用語が持っている意味が重要だからです。用語集がなければ、統一が難しくなってしまうシーンもあるため、できるだけ用意しましょう。

表記スタイルについて

用語集と同様に、表記スタイルも大変重要です。例えば、このような場合は何が正解なのかはお客様にしかわかりません。

表記の例ルール
ユーザ インタフェースユーザ、インタ、フェース
ユーザ インターフェースユーザ、インター、フェース
ユーザ インターフェイスユーザ、インター、フェイス
ユーザ インタフェイスユーザ、インタ、フェイス
ユーザー インタフェースユーザー、インタ、フェース
ユーザー インターフェースユーザー、インター、フェース
ユーザー インターフェイスユーザー、インター、フェイス
ユーザー インタフェイスユーザー、インタ、フェイス

どれも ” User Interface” という言葉の訳語であり、意味も変わりません。違うのは表記スタイルだけです。

これは、どれも意味は同じなのに、表記方法が異なっているというほんの一例です。UI の場合、特にこの表記方法が異なると、画面として表示させたときに、かなりバラバラな印象が強く、使いにくいソフトウェアと思われてしまうかもしれません。

スクリーンショットや実機インストール

UI はそのソフトウェアのスクリーンショットがあればより翻訳しやすくなります。これは完成形をイメージできるからです。また、場合によっては翻訳時に作業環境を構築し、実際のソフトウェアをインストール、操作しながら翻訳するケースもあります。

これらはどちらも、実際の画面に表示される状況を想像して翻訳することができるために、品質が高くなるということを意味します。

まず作業前に確認すべき点を洗い出し、準備することで実際の翻訳作業をスムースにすることができるため、より翻訳作業そのものに集中することができ、結果としてお客様が望む品質に近くなるのです。

これらを踏まえ、UI の翻訳時に、特に重要な 3 つの注意点をご説明しましょう。

注意点1:限定された文字数

ドキュメントの翻訳と異なり、UI の翻訳やローカライズではその使用される場所が画面やメニュー画面ということもあり、ダラダラと長い文章で翻訳することができません。

スクリーンショットの幅に収まるように訳文を調整しなければ、どんなに上手な翻訳でも使い物になりません。このため、翻訳後には訳文を実装し表示させ、訳文の微調整などを行わなければならないケースもあります。

例えば、英語から日本語からの翻訳の場合には、英語はシングルバイト、日本語はダブルバイトという前提を踏まえて最大の文字数をあらかじめ決めておいて翻訳する必要があります。

文字数制限のある翻訳では、創意工夫が必要になりますし、上述の用語集や表記スタイルが重要になってくるのです。

注意点2:文脈(コンテキスト)がない

通常、ドキュメントは読み物としての要素を持っているため、「話の流れ」、つまり文脈(コンテキスト)が存在しますが、UI には文脈がありません。そのため、この文章がいったいどういうシーンで使用されているのかが想像できないため、どのように訳せばいいのかがとりわけ困難になります。

文脈は非常に重要です。読み手だけでなく翻訳者にとっても、流れるような、リズムのある文章は、読み手の頭にスッと入っていきますが、逆に、読みにくい文章の場合にはそれがかなり難しくなります。

文脈(コンテキスト)がない分、周辺資料がより一層重要な位置を占めるのがご理解いただけるかと思います。

注意点3:ファイル形式

UI  ファイルには、様々なファイル形式があるのは上述のとおりですが、UI ストリングス内にある文字列では翻訳する必要のないものが多くあります。もっとも一般的なものとして、例のような記述がある場合、以下のように処理します。

example

この際、翻訳対象個所以外を誤って触ったり、変更してしまったりすることがあります。

これについてはツールを使用して回避するか、もしくはエクセル等に翻訳対象個所を抽出していただき、そのエクセルファイルを翻訳するという方法があります。これであれば、余計な文字列を気にすることなく翻訳作業に専念することができるためです。

まとめ

UI はソフトウェア内においてユーザとの接点となる大変重要なコンタクトポイントです。インターフェースとしての機能を果たすためには、適切な訳語である必要があります。

弊社のこれまでの経験でも、ドキュメントは翻訳してもソフトウェアはローカライズしなかったり、UI が英語のままの製品がありました。これは、下手な翻訳をするくらいなら英語のままのほうがユーザに親切だという判断です。UI をはじめとした翻訳・ローカライズ作業は確かにコストのかかるものですが、それは顧客満足度を引きあげるための必要な投資ですから、翻訳の品質をきちんと担保すべきではないでしょうか。

だからこそ今回お伝えした3つのポイントに注意していただき、納得のいく品質で翻訳し、ご利用いただければと思います。

翻訳・通訳・ローカライズ全般のお問い合わせ

160508-www-bnr_03


アプリをローカライズするときに気をつけたい7つのこと

topapp

今回はアプリのローカライズについてお伝えしたいと思います。

最初からローカライズを意識した日本語版を開発する

当たり前のようで意外とできていないことが多いのですが、多言語翻訳での展開を考えたときに、日本語原文に影響を受けてしまう事が少なからずあるため、事前に日本語版を作る際には、しっかりと設計する必要があるということです。

例えば、日本語を翻訳すると英語の文章が長くなる傾向にあります。理由としてはいくつかありますが、文法構造が違っていたり、書いている人が違っているなど、まったく同じ分量にはなりにくいわけです。

それにも関わらず、UI としての長さ(幅)は変わりません。つまりこのまま翻訳して英語にしてしまうと、英語が長くなってはみ出してしまうような事態になります。

アプリの内容を熟知し、使いこなしているのであれば、日本語の内容を踏まえて英語を短くしてしまったり、端折ったりということができますが、基本的に産業翻訳では「原文に忠実に」というルールが存在すること、また翻訳者が(勝手に)判断をして情報を取捨選択することはできないという側面があるため、日本語の内容を過不足なく伝えようとすると、どうしても自然と英語が長くなってしまうわけです。

日本語版の開発時に、英語やその他の言語に翻訳することを意識することは非常に重要です。

特に日本語は主語がなくても文章が成立しますが、英語などはそうはいきません。日本語を短くしても、他の言語では長くなってしまう可能性がありますので、その場合は以下のいずれかを検討する必要があります。

  • 多言語を意識して日本語の構造をハッキリさせる
  • それができない場合には、多言語が長くなっても余裕のある UI デザインを考える

ターゲット言語を決める

これは当たり前の話ですが、大変重要です。

「何語に翻訳するのか?」を検討するときには、前回ご紹介した「ダウンロード数」や「収益」を検討しなければならないからです。

モバイルアプリ開発会社 必見!アプリのダウンロード数が増えれば収益が増える?

ただ何となく中国語に翻訳しようとか、スペイン語にしておけばいいという判断では、当然ながらうまくいかないでしょう。

仮に、「スペイン語」を選ぶなら、「なぜスペイン語に翻訳するのか?」「なぜスペイン語版を作るのか?」といった裏づけが必要です。

どうしてスペイン語なのか?それは言語の特性が関係したり、その国の法律や制度なども関係するかもしれません。アプリのコンテンツによってもターゲットの言語は変わるはずです。

日本語は、基本的に日本でしか通じません。しかし英語は多くの国で読まれています。単一言語が複数の国で通用するなら、それは汎用性が高いということですので、そういった基準からターゲット言語を決めるというのもありです。

ローカライズのスケジュールを検討する

アプリをローカライズし、多言語に展開するためにはある程度の時間を要します。

例えば、日本語から英語への翻訳なら、1日に処理できる(翻訳できる)分量というのはおおよそ 3,000文字程度といわれています。それ以上のスピードアップは、品質に影響する(低下する)ため、お勧めできません。

翻訳業界と翻訳会社

このように言語ごとにスピードや処理量が違います。例えば、日本語からドイツ語に翻訳するとした場合、直接ドイツ語に翻訳できない可能性もあります。それはアプリの内容やボリュームによってリソース不足に陥る事があるためです。

その場合にはいったん英語を経由してからドイツ語に翻訳することもあります。コストはかかってしまいますが、英語→ドイツ語の方がリソースも多くキャパシティも大きいためです。

また同じヨーロッパ言語としての親和性も高いので、スピーディに展開できる事もあります。(※ドイツ語に翻訳するようなアプリは、通常は英語版があることがほとんですし、そうでない場合には英語版もリリースすべきでしょう)

無論、開発プロセスは翻訳だけではありませんが、ある程度目安を持ってスケジューリングしないと、無理な納期で翻訳することになります。当然品質は上がらず、アプリを使う現地ユーザーからも「意味が分からない」とか「文章として成立していない」といったものになってしまうことがあります。

特に多言語の場合にはその影響が全世界に広がってしまうので、慎重にローカライズを行っていかなくてはなりません。

アプリそのものの評価に直結します。

外注先を検討する

ターゲット言語とスケジュールが決まったら、今度は外注先を検討します。(社内で対応できる、という方は本エントリー自体があまり意味がありませんので、あくまで必ず外注するという前提でお読みください)

以下の図のように、外注にはいくつもの種類があります。

コスト、品質、スケジュールのバランスをしっかりと検討して発注する事をお勧めします。どの項目を重視するのか、どれが優先なのか、それを決めておかなければ期待する効果は得られません。

list

翻訳の功と罪

専門用語やスタイルガイドを準備する

これは特にアプリのローカライズに限ったことではありませんが、信頼できる参考資料のうち、もっとも重要度が高いのが専門用語です。アプリ内でしか使われていない言葉だったり、製品名のような固有名詞であれば、事前に準備して指示する必要があります。

それがなければ、翻訳者は調査できる範囲で調査して訳文を作りますが、それが果たして希望通りの訳語になっているかどうはふたを開けて見ないとわかりません。

これは単純に時間の無駄ですから、事前に準備できるものは準備しておくことで、スムースになるのは間違いありません。

用語集構築・運用

翻訳対象となるテキスト原稿を準備する

周辺資料の準備が整ったら、実際の作業対象ファイルを準備します。アプリのローカライズの場合、当然ながらソースコード内に翻訳対象テキストが記述されていますが、そのファイルをそのまま翻訳者または翻訳会社に渡しても、翻訳ができないこともあります。

余計な記述は、翻訳者にとっても混乱の元ですし、また作業中に謝ってプログラムコードを1文字消してしまった、というようなことも無いとは言えません。

そういった事故を予め防ぐために、「翻訳対象テキストだけを抽出して渡す」ことが必要になります。

例えば、エクセルにテキストを抽出します。以下はイメージです。

sample

 

このように、翻訳者にも「どこを翻訳すればいいか」を視覚的に明示してあげることで、作業スピードもあがりますし、また品質も安定します。

アプリの深い理解を促すため、翻訳者に参考となる情報を渡す

さらに翻訳の精度をあげて、アプリのローカライズを成功させるには、アプリそのものをダウンロードして触ってもらったり、事前にトレーニングや簡単なミニセミナーなどを開き、翻訳者に説明するといったことも有効です。

プロの翻訳者なら事前にアプリの動作を分かっていれば、より適切な訳語を選択する事ができます。

ひと手間かかってしまいますが、事前のレクチャーや準備こそが、アプリのローカライズプロジェクトの成功の確率を上げるのだということを理解しましょう。

まとめ

いかがでしたでしょうか。これまでにご説明した項目は、私たちが日常的にアプリのローカライズをご依頼いただく中で、最低限やっておいたほうがいいものばかりです。

アプリのローカライズの良し悪しによっては、原作(日本版)の良さやアプリの魅力が伝わらない可能性も多いにあるため、自社のアプリが現地の人々に受け入れられるかどうかを左右する重要なポイントでもあるのです。

つまり、アプリのローカライズは決して翻訳者だけの仕事ではなく、お客様、信頼できる翻訳会社、翻訳者とプロジェクトチーム全員が一丸となって取り組む仕事であるといえます。

当然その場合には、コミュニケーションやチームをまとめるマネジメント力も求められます。この総合力の違いがローカライズの品質に大きな影響を与えるといっても過言ではありません。

そして、事前にしっかりと準備をし計画を立て、投資すべき点にはしっかりと投資(お金をかける)できるアプリ開発会社のみが世界に進出するアプリのローカライズを成功させることが出来るのです。

アマネファクトリー株式会社様

ローカライズとは

翻訳・通訳・ローカライズ全般のお問い合わせ

160508-www-bnr_03