自分が作成した英文に対してネイティブスピーカのチェックを受けられるサービスを比較、第2回です。
この記事では、実際に利用した2つのサービスについて、依頼の流れと結果について紹介します。なお、依頼したのは、以下の2社です。よく似た名前なので、以降A,Bと呼びます。
- A: Proofreading Services .COM
http://www.proofreadingservices.com/pages/website-proofreading - B: PROOF READING .com
http://www.proof-reading.com/website-content-editing.html
チェックの対象について
チェックの対象にしたのは、OnTargetメールテスターの説明ページ英語版です(公開しているページは、すでにチェックを受けた後の内容です)。全部で445語でした。
http://mailtester.ontarget.cc/en/features.html
元の文章は、公開中の日本語版説明ページを、自分で翻訳したものです。
依頼の流れについて
A: Proofreading Services .COM
ユーザ登録不要で使えます。フォームに必要事項を入力して、チェック対象のファイルを送信すると、決済用にshopifyのサイトに飛ばされます。ここでサービスサイトの至るところに書かれている5%割引コードを入力すると、金額が更新されます。
価格は、250語を1ページとして、切り上げで2ページと計算されました。5%割引コードを使って最終的に、です。
72時間以内のコースで依頼しましたが、チェック結果は66時間7分後に、メールにWordファイルを添付する形で届きました。
B: PROOF READING .com
チェック対象文書は、ログイン後の画面で送信するようになっており、ユーザ登録必須です。ユーザ登録時にクレジットカード番号が必要ですが、登録費用は特にかからないとのことです(サイトに書いてある)。
アメリカ以外のクレジットカードを使っていると、初回のチェック依頼時(登録時ではなく)に、住所確認のためコールセンターに電話するようにというメッセージが表示されます(海外のクレジットカードは不正が多いのでこういう対応になっていると思われる)。
自分の場合「国際電話で、アメリカのフリーダイヤルに電話できるのかな…」などと考えているうちに、向こうから電話がかかってきました(発信者番号は日本の携帯電話番号)。電話は英語で、こちらの名前と住所を確認した後、電話は初回だけであること、文章チェックが完了次第メールが届くことなどの説明を受けました。
余談ですが、ユーザ登録の電話番号欄に、プラス記号が入力できなかったので、自分の携帯電話番号を国番号から始めてハイフンもなしで入力していたにも関わらず(こんな感じ→ 818012345678)、ちゃんと電話がかかってきたので、日本の電話番号システムをちゃんと理解している担当者が電話連絡している模様です(海外ユーザの確認を請け負っている専門業者があるのかもしれない)。
価格は、300語を1ページとして厳密に単語単位で計算されます。最終的にでした。
72時間以内のコースで依頼しましたが、電話での身元確認後、1時間12分で完了した旨のメールが届き、サイトにログインしてWordファイルがダウンロードできました。
なお、編集されたファイルを受け取ってから48時間以内に再度同じ文書(変更された語数が20%以内であること)チェック依頼する場合は、24時間以内コースが割引レートで利用できるようです。
http://www.proof-reading.com/edit_confirm_service.asp
(2014/6/19追記)
その後、再び利用する機会があったのですが、今回は24時間コースで申し込んで、完了まで21時間22分でした。
編集結果について
編集結果の総括です。
- A,B共に、頼んだ甲斐がある全体的に自然な文章になった。
- Aは意味が曖昧な部分などにコメントが多い。Bはコメントがほとんどなく、ただ修正して来るという印象。コメントで、自分の元の文章自体の曖昧さに気付き、改善につながる点もいくつかあった。
- チェック後の文章をよく読むと、Bの方が正しく理解してくれている印象。
- 冠詞の間違いはいくつも指摘された。ただし、A,Bの修正内容が違うケースもあり、「絶対的な間違い」(自分が書いたもの)があっても、「絶対の正解」はないのだということが分かる。
- 2社の解釈がまったく異なることで、原文のあいまいさに気付いた部分があった。
それぞれの具体的な例は、長くなったので末尾にまとめておきます。
まとめ
自分が次回依頼するとしたら
B社に「文意が曖昧な点などあったら、再依頼を検討するので、積極的にコメントを入れて欲しい」と補足指示をつけて依頼すると思います。
B社は、文意の曖昧さなど気になる点があっても、校閲者なりの解釈をして、きちんと完成品の文書として出てくるのが便利です。
これにさらにコメントが入ってくれば、再編集サービスと合わせて、さらに文章を改善することができます。
また、1語単位の請求でムダがないこと、とても早く結果が返ってきたこと、などもポイントです。
(2014/7/22追記)
その後、英文レジメ(職務経歴書)をA,B両社に依頼する機会があったのですが、逆に、次からはAを使いたいと思う編集結果でした。Aの方が、レジメらしい冠詞の少ない表現になっていたためです(Bの編集結果は完全に捨てました)。なお、英文レジメについては、もっと高級な電話面接つきの専門サービスを使う方が一般的なようです。
A社の便利な点
A社にもメリットはあって、登録不要で、編集結果をメールで受け取れるのは一時利用には便利です。また、PayPalが使えること、英語で身元確認電話をしなくて済むことは、人によっては大きなメリットかもしれません。
コメントが豊富なことも、何往復かやり取りすることが前提なら魅力的だと思います。
2社同時利用をやるかどうか
今回は初回だったこと、想定予算5,000円に対して非常に安かったことから、2社に依頼してみましたが、原文と2つの編集案の3つを比較しながら、最終的に統合していくのは非常に面倒だったので(例示した以外の箇所もいちいち悩みながら統合しました)、もうやらないと思います。
開発者向けには「コンフリクトの非常に多いブランチをマージする破目になった」と言えば、共感してもらえるでしょうか…。
付録: 編集結果の具体例
1.特に自然さを感じた箇所の例
(自分の原文)
Limit of total storage is not currently enforced, but old email might be deleted based on whole service usage.
(Aの編集結果)
The limit of total storage is not currently enforced, but old e-mail might be deleted based on the usage of the entire service.
「サービス全体」という表現が、自分の"whole service usage"から、"usage of the entire service"となって、明瞭になっています。
(自分の原文)
When you plan to expand your Web application to world wide, do not forget localizing email at the same time. Email is still very important to contact to your users.
(Bの編集結果)
When expanding your Web application worldwide, don't forget about localizing your email at the same time. Email is still a very important point of contact with your users.
書き出しが主語・述語をもつ複文から、分詞を使った表現に修正されて、軽くなっています。また、末尾の"important point of contact"という表現も、この部分にぴったりだなと思いました。
2.コメントの例
Aは原文の意味が分かりにくい箇所を中心に、色々なコメントを残してくれています。全部で7箇所入っていましたが、そのうちの1つを紹介します。
(自分の原文)
However, e-mail clients vary much more than browsers and treat multibyte characters differently .
(Aのコメント)
This is somewhat confusing. Do you mean e-mailing clients varies much more than [insert appropriate verb here] browsers and treats multibyte characters differently?
In any case, please make the appropriate changes so that your thought is carefully discussed.
指摘の通り、曖昧だと思ったので、最終的に公開しているものは曖昧さを減らすように修正しました。
一方で、Bのコメントは、全体の見出しに対する1つのみでした。
(Bのコメント)
Perhaps something like 'Is email localization giving you a headache?' would work better here.
結局、このコメントで提案された見出しはいいな、と思いそのまま採用しました。
3.Bの方が内容を理解していると感じた箇所
サイトの内容がもともと開発者向けですし、Aも「誤解している」というわけではありません。全体的な印象のため、特定箇所を選ぶのに困ったのですが、一番違和感を感じたところを挙げます。
(自分の原文)
You can check actual view of your email with various email clients instantly.
(Aの編集結果)
You can check the actual view of your e-mail to various e-mail clients instantly.
(Bの編集結果)
You can check the actual appearance of your email in various email clients instantly.
そもそも、自分が"view"という単語を使っているのが分かりにくい原因かもしれないと反省しつつ、この部分はBの編集結果を完全採用しました。
4.冠詞についての指摘例
冠詞は何年勉強してもミスがなくならないところで、今回もだいぶ指摘されました。ただ、興味深かったのは修正案が異なる場合があったことです。一例を挙げます。
(自分の原文)
Limit of total storage is not currently enforced, but old email might be deleted based on whole service usage.
(Aの編集結果)
The limit of total storage is not currently enforced, but old e-mail might be deleted based on the usage of the entire service.
(Bの編集結果)
Total storage limits are not currently enforced, but old emails may be deleted based on whole-service usage.
書き出しが、"The limit of total storage"と定冠詞をつけるか、"Total storage limits"と無冠詞複数形にするかで、編集結果が分かれています。
5.2社の解釈がまったく違った例
2社から来た編集内容が大きく食い違うことで、原文の曖昧さに気付いて改善したところがあります。
(原文)
Due to long history of internationalizing email, which could originally convey ASCII characters only, character encoding in email is very complicated.
(Aの修正案)
Even with the long history of internationalizing e-mail, which could originally convey ASCII characters only, character encoding in e-mail is still very complicated.
(Bの修正案)
Due to the long history of internationalizing email, which could originally convey ASCII characters only, character encoding in email is very complicated.
Aは「歴史が長ければ、仕様は安定するのが常識」と考えていて、Bは自分と同様に「歴史の長さゆえにややこしくなっている」と解釈しています。
「たしかにどちらの解釈もありえるな」と思ってよく考えてみると、「歴史が長いこと」自体が仕様のややこしさの原因なのではなく、「パッチワーク的積み重ね」が問題であることに気付きました。そこで、最終的には"incrementally"という単語を入れて以下のようにしました。
(サイトに載せている文章)
Due to the long history of internationalizing email, which could originally convey ASCII characters only and progressed incrementally to allow more characters, handling multibyte characters in email is very complicated.
