みなさんはFAQ（Frequently Asked Questions）を英語で作成する機会はありますか？
今回は私たちが普段英語でFAQを作成する際に気をつけているポイントをいくつかご紹介します。
-質問はユーザーの目線で書く
（例文）
Q: Why can't I add feeds that are in Atom format?
ポイント！
・主語を“I”にする
-回答は会社の目線または客観的な視点で書く
１つのFAQの中で両方の視点で書いてもよい
（例文）
A: We are investigating adding support for Atom feeds in a future version.
A: The advanced features of WondefulFeedApp rely upon aspects of RSS feeds that are not available in Atom feeds.
ポイント！
・主語を“We”にする
・主語を製品や機能などにし、その機能について客観的に説明する
-できるだけ質問形式で書く
ただし、質問形式だと不自然な場合や質問が長く続く場合などは、読みやすさを考え、以下のようにシンプルに現象を書いてもよい
（例文）
Q: My MagicAudioPlayer won't turn on.
-ユーザーの立場で考える
ユーザーが今何を経験しているのか、何を知っているのかなどを考える
会社の内部で使用されている専門用語より、ユーザーが知っていたり、使いそうな用語を使用する
SDNAネイティブチェック担当者はいつも言っています。
Try to put yourself in the user's shoes.（ユーザーの立場で考えること）
FAQに限らず、ユーザーの立場に立ったローカライゼーションを私たちはこれからも心掛けていきます。
アプリや製品によって英語文言の最後にピリオドを付けているものと付けていないものがあり、一体どちらが正しいのか迷ったことはありませんか？
私たちが英語化する時は、OS の句点ルールに合わせているという前提で、基本的に英語のもととなる日本語文言の句点の有無に合わせてピリオドの有無を決めています。また、日本語文言が文であるのに対し、英語文言が名詞など文でなくなった場合は、日本語文言に句点が付いていても英語文言にピリオドを付けない場合もあります。
通常英語では、基本的に主語と動詞を持つ完全な文（complete sentence）の最後に必ずピリオドや疑問符、感嘆符などの“terminal punctuation”を付けますが、UI 文言の場合は正解があるわけではなく、スタイルの問題とされています。Microsoft スタイルガイドの“Punctuation”の項目でも、“This section focuses mainly on punctuation issues that are matter of style and not a matter of right or wrong”という前置きがあります。
各 OS はピリオドのスタイルについてどのようなルールを定めているでしょうか？
Android を開発する Google の Style ページではピリオドについて、ラベル（ボタンなどのテキスト）や短文にピリオドは付けない、ダイアログの本文や二つ以上の文を続けて書く場合はピリオドを付けると書かれています。
Apple Style Guide では、完全な文（complete sentence）にはピリオドを付けるが、“sentence fragment”（完全な文ではないフレーズ）にはピリオドを付けないと書かれています。
Microsoft スタイルガイドはピリオドについて、下記のように書いています。
・ピリオドの後は 1 スペースのみ空ける。（SDNA 注：タイプライターの時代、ピリオドの後にダブルスペースを入れるルールが定着していたので、わざわざ書いているのかもしれません。）
・コロンの後の箇条書きリストでは、下記の例のようにそれぞれの項目が前置きとつながって一つの文になっている場合や少なくとも一つの項目が完全な文の場合にピリオドを付ける。項目すべてが 3 ワード以下の短いセンテンスの場合は、ピリオドを付けない。
例：
I like to:
- Play my guitar.
- Drive my MINI Cooper.
- Hang out with my family.
Microsoft スタイルガイドでは、上記以外にもピリオドのフォントスタイルなどにも言及しています。
このようにそれぞれのスタイルガイドがありますが、ピリオドに関しても最も重要なのは、製品内で一貫したスタイルを使用することです。
日本語ではお得な、またはある物の値段がそれほど高くないといった意味で「リーズナブル」が使用されているのをよく耳にします。しかし“reasonable“には「分別がある」または「合理的な」という意味があり、必ずしも値段に関係があるとは限りません。“I think it’s reasonable to leave a 12-year-old girl home alone for an hour.“などと言うこともあります。
＜例文＞
The maximum file size setting for a video must be a reasonable value (128 or less).
ビデオの最大ファイルサイズ設定は、妥当な値 (128 以下) にする必要があります。
では値段が「手ごろな」と言いたい場合は何を使えば良いでしょうか？
こういう場合は“affordable“がより適切です。
＜例文＞
SDNA's affordable ABC app is now available to buy.
SDNAのお求めやすいABCアプリが購入可能です。
“affordable“は購入可能な物の値段に対して使用されます。
そして、“reasonable“、“affordable“のどちらともその価格が妥当であろうという印象を与えますが、“reasonable“は価格との関連性はよりあいまいです。したがって、もし“reasonable“を使用するのであれば、“reasonably priced“のように使用すると意味が明確になり良いでしょう。
他に「あまり高価でない」という意味の単語にはたとえば以下があります。
- cost-effective
- low-cost
- economical
しかし！
ある物を「低価格」と言う場合は慎重にならなければいけません。消費者はバーゲンに惹きつけられる一方で、安い物は価値も低い物と同一視する場合もあります。価格について言及する際は表現を慎重に選んだ方がよいかもしれません。こういった場合はニュアンスが重要です。
単語の本来の意味をよく理解し、分別を持って英語を使いこなしていきたいものですね。
今回は「その他」の英訳について、二つの事例を挙げてお話しします。
事例１：
アプリの設定画面で項目が多い場合、設定項目をグループに分けて表示することがあります。
（Microsoft Office の「オプション」画面も設定項目をグループに分けていますね。）
私たちが英語化を担当したアプリの中には、グループにまとめづらい項目を集めて「その他」というグループ名を付けているものがありました。
事例２：
いくつかの選択肢の中から一つを選択する設定で、該当する項目がない場合に選択する「その他」がありました。
この二つの事例で使用される「その他」は英語で何になると思いますか？
SDNA ネイティブチェック担当者は、両方とも“Other”がよいと言っています。
特に事例１は「その他色々」の意味で複数の“Others”がよいのではないかと想像しましたが、以下のような理由で単数がよいそうです：
In this case, the singularity is idiomatic. I would guess the reason is that it’s a shortening of “Other settings.”
“Other settings” の短縮だから単数の”Other“がよいのですね。
このような事例にあたると、「理由は明確ではないけど、自然だから」という感覚を持つネイティブにチェックしてもらう大切さを実感します。
日本語もそうですが、英語でも、この名詞にはこの動詞をよく組み合わせるということがあります。
例えば英語では、「風邪をひく」は“catch a cold“とよく言いますね。
こうした語と語の慣用的な結びつきをコロケーションと言います。
同様に、“connection”には以下のように“establish”を組み合わせると良いです。
（例文）
Connection established.
接続が完了しました。
日本語を直訳して、
Connection completed.
としても問題ありませんが、この場合“connection”には“establish”を合わせるとより適切です。
ただし、“establish”は何とでも組み合わせられるわけではありません。
“Installation established.”や“Download established.”とは言いません。
ある検索サイトでは、"Connection established."が約419,000件のヒット数であるのに対し、"Connection completed."は約20,600 件となり、"Connection established."の方が使用頻度が高いことがわかります。
使用頻度の高いコロケーションを知っておき、しっくりくる表現を使いこなしていきたいですね。
ある日本語の英訳が分からず調べた時、予想していた英語とまったく違うことがありますが、印刷方向の「縦」「横」の英訳もその一つでした。
「縦方向」は“Portrait”で、「横方向」は“Landscape”です。
「肖像画」と「景観」・・・感覚的に理解できるし、素敵な表現ですよね。
（ちなみに「印刷方向」は英語で、“Orientation”と言います。）
このような決まった訳語がある言葉はネイティブに教えてもらうのが確実ですが、それ以外に私たちが参考として使っている方法をご紹介します。
・Microsoft ランゲージ ポータルで検索する
Microsoft 製品で使用されている文言を検索することができる Web ページです。
日→英、英→日両方の方向に検索可能なので、予測した英語の使われ方などの参考にしています。（日英以外の言語も検索可能です。）
Microsoft ランゲージ ポータル
・英語版の Windows や Microsoft Office を使う
Windows のコントロール パネルで表示言語を英語に設定すると、Windows や Microsoft Office、その他 OS の言語設定に合わせて表示言語を変更しているアプリの UI（ユーザーインターフェイス）文言も英語で表示されます。
ローカライズ対象分野によっては、そのまま使用できる用語や表現があまりない場合もありますが、コンピューターや業務用アプリの関連用語や表現の勉強にもなります。
私たちがローカライズを担当している製品は、英語化として米語版のみ作成し、米国以外の国や地域にも配布する場合が多いですが、米語版（アメリカ英語）と英語版（ブリティッシュ英語）を分けて作成する場合もあります。
今回は、米語と英語の違いについて、Android OS (Jelly Bean や Lollipop を参照) の対応例をご紹介します。
| 例 |
米語 |
英語 |
| スペル |
dialing |
dialling |
| スペル |
behavior |
behaviour |
| コンマの有無 |
At most 1 process |
At most, 1 process |
| シリアル・コンマ） |
Read and write your SMS, email, and other messages. |
Read and write your SMS, email and other messages. |
| 単語 |
Airplane mode |
Aeroplane mode |
| 単語 |
Cell standby |
Mobile standby |
| “that“の有無 |
Observe text you type |
Observe text that you type |
時制 |
The engine you chose can't run. |
The engine you have chosen can't run. |
ハイフンの有無 |
Dial pad touch tones |
Dial-pad touch tones |
ハイフンの有無 |
This will disable all third party applications you have installed. |
This will disable all third-party applications that you have installed. |
上記以外にも米語と英語ではスペルや単語、言い回し、用法など様々な違いがあり、まずはどこまで厳密に対応するか方針を決める必要があります。
UI（ユーザーインターフェイス）文言で「選択する」という言葉はよく出てくると思いますが、英語化する時に“select”と“choose”どちらを使用するか迷ったことはありませんか？
Microsoft スタイルガイドの“choose”の項目には以下のような記述があります：
“Use
choose when the user must make a decision, as opposed to selecting (not
picking) an item from list to carry out a decision already made.”
すでに決めたことを実行するためにリストから項目を選ぶような場合に“select”が使われていますが、“choose”はユーザーが決定する時に使うと書かれています。
SDNA ネイティブチェック担当者にも UI 文言としての“select”と“choose”の使い分けについて聞いたところ、以下のような回答でした：
“I think I would use ”select“ any time we mean for the user to actually do something in the interface, and use ”choose“ when we mean just making a choice.”
「ユーザーが実際にインターフェイスで何かする時は“select”を使用し、単に選択する時は“choose”を使用すると思う。」と言っており、Microsoft スタイルガイドと同様の回答でした。
また SDNA ネイティブチェック担当者は使い分けの例として、以下のような文を挙げてくれました：
“To complete installation, you must choose your country/region. Select your country/region from the list, and click OK.”
「しばらくしてからもう一度お試しください。」
アプリケーションなどでユーザーがある操作を行おうとしたものの、何らかの理由でその操作ができなかった場合などに表示される文言です。通常はこの文言の前に「～できません。」や「～中です。」など、その操作ができなかったことやその理由などが記載されています。
このときの「しばらくしてから」ですが、いったいどれ位の時間になるのかみなさんは考えたことはありますか？
アプリケーションやその機能などにより、同じ「しばらく」でも英語ではその時間によって以下のように使い分けることも可能です。
・数分またはそれ以上の場合
Try again later.
・1分以内などすぐの場合
Try again in a moment.
どの程度待つのか、可能であればユーザーに前もってより具体的にお知らせするなど、ユーザーの視点に立ち、文言で工夫できることがあります。
「ファイル出力に失敗しました。」という日本語に対し、次の英語のうちどちらを使用しますか？
Failed to output file.
Unable to output file.
日本語を直訳すると“Failed to～“になりますが、私たちは通常“Unable to～”（～できない）を使用しています。
マイクロソフトのUXガイドに、エラーメッセージを作成する上で気をつけることとして次のような記載があります。
・以下の言葉を使用しない。
・“Error,“ “failure“ （代わりに“problem“を使用する）
・“Failed to“（代わりに“unable to“を使用する）
・“Illegal,“ “invalid,“ “bad“（代わりに“incorrect“を使用する）
・“Abort,“ “kill,“ “terminate“（代わりに“stop“を使用する）
・“Catastrophic（壊滅的な）,“ “fatal（致命的な）“（代わりに“serious“を使用する）
ユーザーに責任を押し付けたり、ユーザーに非があるような言い回しを避ける。「あなた」という表現は使わないようにする。一般的には能動態が好まれるが、ユーザーを主語にすることでエラーの責任がユーザーにあるかのように感じさせてしまう可能性がある場合は受動態を使用する。
OSの用語・スタイルなどに合わせ、また仕様やクライアントがユーザーに伝えたいことなどを確認しつつ、ネイティブチェッカーとも相談しながら、ユーザーがその製品を利用しやすい文言になるよう心がけています。
日々 UI（ユーザーインターフェイス）文言を英語化していると、過去に英語化済みの他のアプリの文言が意外に流用できない（新しい文言が多い）ことに驚きますが、それでもよく使うパターンはあります。
今回は英語の UI 文言でよく使われるパターン例をご紹介します。
・Cannot （動詞）～ because ・・・.
和訳：・・・のため、～できません。
例文：Cannot save the created video because it is larger than 4 GB.
（和訳：作成されたビデオが 4GB を超えているため、保存できません。）
英語は結論から先に言うので、結論と理由の順番が日本語と逆になります。
・Are you sure you want to （動詞）～?
和訳：～してもよろしいですか？
例文：Are you sure you want to delete this file?
（和訳：このファイルを削除してもよろしいですか？）
ユーザーの選択に対する確認メッセージです。
下記のように元の日本語が長い場合は、英語も二文に分け、｢よろしいですか?｣を“Do you want to continue?”と英訳しています。
例文：（フォルダー名）とこのフォルダーに含まれるすべてのファイルをごみ箱へ移動します。よろしいですか?）
英訳：（フォルダー名）and all files inside it will be sent to the Recycle Bin. Do you want to continue?”
・Click （ボタン名など） to （動詞）～.
和訳：（ボタン名など）をクリックすると～します。
例文：Click Start to begin creating the movie.
（和訳：[作成開始] をクリックするとムービーの作成が始まります。）
“Click”を“Select”や“Tap”と入れ替えて使用することもできます。
ちなみに日本語文言ではボタン名などのUI コントロールを引用する時に通常カッコを付けますが、英語では通常、UI 文言そのままのキャピタライズで入れてカッコを付けません。
・To （動詞）～, ・・・.
和文：～するには、・・・してください。
例文：To authenticate, this computer must be connected to the Internet.
（和訳：認証を行うにはこのコンピューターがネットワークに接続されている必要があります。）
・Refer to （名詞）～ for （名詞）・・・.
・・・については～をご参照ください。
例文：Refer to the help for details about the disc types you can create.
（作成できるディスクの種類など詳細はヘルプをご覧下さい。）
これらのパターンは、一つのアプリの中で何度も出てくることも珍しくないほど汎用性が高いので、覚えておくと便利かもしれません。
アプリケーションのメニュー名などによく使用されている「オプション」を英語化する際、私たちは通常”Options”と複数形にしています。ネイティブによると、たとえ選択肢が１つであってもカテゴリーとしての「オプション」を指す場合は"Options"が良いとのことです。通常全てのオプションが集まっている場所を指すからです。
一方、ある特定のオプションのみを指す場合は”xx option”と単数形にします。
同じように「設定」もカテゴリーの場合は、通常”Settings”と複数形にしています。
英語にする際に仕様をよく理解した上で単数形にするか複数形にするか確認することもローカライゼーションでは大切です。
UI（ユーザーインターフェース）文言では「機能」という言葉がよく出てきますが、英語では“feature”と“function”のどちらを使用すれば良いか迷ったことはありませんか？
私たちが扱うUI文言のほとんどのケースでは"feature"と"function"はほぼ同じ意味で、両方とも製品がユーザーに提供する機能を示します。しかし私たちは通常"feature"を使用しています。その理由は以下のようにちょっとしたニュアンスの違いがあるからです。
"feature"：マーケティング用語。非常に肯定的な言葉で、製品をより良くし、ユーザーにとってより役立つものというニュアンスがある。製品の一般的な特徴ではなく、ユーザーにその製品を選んでもらえるような最も良い特徴を意味する。
"function"：技術用語。ユーザーの感情に訴えかけるものではない。非常に中立で味気なく、製品の操作を示す専門用語的な響きがある。"function"という言葉にワクワクする人はいない。
改めて辞書を引いてみると、"function"は機能、作用、働き、効用といった意味合いが強いのに対し、"feature"は特徴、特性、特長といった意味合いが強いことがわかります。
ちょっとした言葉のニュアンスの違いで製品やブランドなどに対する印象が変わったりします。違いを理解した上で適切に使用していきたいですね。
日本語では、中黒（・）を“and”の意味で使用し（例：テレビ・ビデオ）、スラッシュ（/）を“or”の意味で使用することが多いですが（例：オン/オフ）、英語でスラッシュは“and”と“or“両方の意味で使用されます。
例えば Android OS 文言には“make/receive Internet calls”（日本語：インターネット通話の発着信）がありますが、このスラッシュは“or“を意味します。
また、Windows にプリインストールされている「メモ帳」のメニュー項目に“Time/Date”（日本語：日付と時刻）がありますが、この場合は“and”の意味でスラッシュが使用されています。
Microsoft のスタイルガイドラインには、”Slash mark” という項目で以下のような記述があり、“either/or”や“he/she”など選択肢を示すスラッシュを入れた構文を使用してはいけないとあります。
ローカライズ担当者やノンネイティブにとって、スラッシュが選択肢であることを示しているのか、二つの語が類義語であることを意味するのか、二つの語がひとまとまりで意味を成すのか分かりづらいとも言っています。
Microsoft のスタイルガイドラインより：
“Do not use constructions that contain a slash mark to indicate a choice, such as either/or and he/she. However, and/or is all right to use if you have no other choice. Localizers and non-native English speakers may not know whether the slash mark indicates a choice, indicates that the two words are synonyms or indicates that two words are part of a single construction, such as client/server.”
このように記号は国によって解釈が違う場合があるので、翻訳する時は気を付ける必要があります。
○×△（まる ばつ さんかく）記号は日本では評価や製品のサポート情報など、いろいろな用途で使用されているのを目にします。一般的に○は良い、×はダメ、△はその中間といった意味で使用されていることが多いですが、海外ではそれぞれの記号が国や地域によって意味が異なる、わからない、場合によっては反対の意味になることがあります。
あるゲーム機ではアジア仕向けと欧米仕向けで〇（決定）ボタンと×（キャンセル）ボタンは逆の機能になっていたりします。
アメリカ人のSDNA ネイティブチェック担当者はこれらの記号について以下のように述べています。
〇（circle）:「オフ」を意味する。電気機器では電源スイッチに「オン」の位置を示す縦棒（アルファベットのIのような）と「オフ」の位置を示す○がよく使用されている。○は一般的に“empty”、または否定的な状況を示すことが多い。
×（ex）: “X“は“do not“や“prohibited“（禁止された）など、強い否定の意味になる。ソフトウェアインターフェースのコントロールキーでは“close“や“cancel“を意味する。“incorrect“の意味もある。ちなみに発音については、「クロス」と発音するネイティブもいるがこれは正しくない。“＋“のようにクロスしている要素が縦横2つの場合が「クロス」であり、“X“の発音はアルファベットの“X“と同じで「エックス」が正しい。
△:特に意味はない。
それでは○や×は英語ではどのように表記すればよいでしょうか？それぞれ以下のように使用すると良いそうです。
○→√チェックマーク（色をつけるとしたら緑）
×→X（色をつけるとしたら赤）
△→文脈によってニュアンスを英語（単語や文章）にする。
ただ、可能であれば、○や×に関しても文脈によって適切な単語や文章にするのがもっとも確実かもしれません。
私たちはUI（ユーザーインターフェース）文言のローカライズだけでなく、ドキュメントの英訳も行っていますが、その中で○×△があった場合は意図を確認し、適宜記号にしたり文章にしたりしています。
書き手が意図していることをよく理解して翻訳することが大切ですが、記号についても忘れてはなりません。
10 月 9 日に 2014 年度第 3 回 JTF 翻訳セミナーを受講してきました。
「JTF」とは、
「日本翻訳連盟」のことで、弊社も毎年参加している
翻訳祭も JTF が主催しています。
JTF 翻訳セミナーは、翻訳者、翻訳会社、翻訳発注者、翻訳品質管理担当者などを対象に、年に何度か東京と大阪で開催されるセミナーで、テーマは実務翻訳のコツ、翻訳品質管理の手法、翻訳業界の動向や今後についてなどです。
10 月 9 日のセミナーは、日英翻訳者の遠田和子氏が「SVを鍛えて翻訳の「殻を破る」英文ライティング術」というテーマで、技術英訳について講演されました。
非常に明快な内容で、ネイティブの発想に近い英文を作成するために、すぐに取り入れられそうな手法がいくつか紹介されていたので共有致します。
・目指す英語は“Plain English”（=明解な英語）
そのためには、以下を意識する。
・短い文にする
（推奨：20 ワード以下、日本語の長い１文は、複数の文に分けて英訳する戦略を立てよう！）
・能動態を使う
上記の他に“Plain English”の基準は「平易な単語を使用する」がありますが、ビジネス英語は専門用語もあるので、今回のセミナーでこの基準は取り上げない、とのことでした。
・主語と述語を文頭に置き、近くにする
・書いた英文の最初の 6 ワードに線を引いてみよう！メインアイデアが入っているか？
日本語の語順を変えて問題ない。
例：
日本語：XX 新聞の世論調査によると、安倍内閣の支持率は 54% です。
英訳例：Abe's cabinet gets a 54% approval rating in a poll by XX Shimbun.
英訳例の解説：
・「XX 新聞の世論調査によると」はメインアイデアではないので後にする
・主語は「支持率」ではない
・強い動詞を使用する
・「強い動詞」とは、1 単語でより多くの意味を持つ単語。
上記の英訳例の“get”を”retain“に変更すると、前と支持率が変わらないことが分かる。また、” enjoy“に変更すると、支持率が高いことが分かる。
・日本語は「～を行う」というような表現がよく使われるが、英語は「～」を動詞にする
例：「コスト削減を行う」
×make cost reductions
○reduce cost
皆さま、遠田氏が教えてくださった上記の手法、いかがでしょうか？
これらの手法を実践したら、英語ネイティブの書く英語に近づけそうな気がしませんか？
ご参考に遠田氏の Facebook ページをご紹介します。
WordSmyth英語ラボ
今では世界中でやり取りされている「メール」ですが、「メール」を英語にする際は“mail”でしょうか？
“e-mail”でしょうか？“mail”は元々手紙や小包などの「郵便物」を意味しますので、動詞または名詞として
“e-mail”の代わりに使うのは曖昧さを生むため注意が必要です。ただし、メールソフトの中の“mail box”など形容詞として使用することは一般的なようです。時々“Email”のように文中でも“E”が大文字になっているのを目にすることがありますが、固有名詞ではないので“Email”とする理由は特にありません。
“e-mail”と“email”でどちらを使用するかについては全く個人や会社の好みによりますし、“e”と“mail”の間のハイフンは伝統的に使用されていましたが、最近はハイフンを入れない傾向が強く、ハイテク分野の最も一般的なスタイルガイドである『AP Stylebook』も２年前にハイフンを入れるのをやめたそうです。
というわけで、私たちは“email”の使用をおすすめします。
みなさんは英語を書く際、理由を表す場合に“because”と“since”ではどちらを使いますか？これらは正式には意味が異なりますが、日常会話ではどちらも理由を表す語としてよく使用されています。
しかし、“since” には「～以来ずっと」の意味もあるため、テクニカルライティングではあいまいさを避けるため、またノンネイティブに配慮し、通常 “because” を使用します。
<例文>
Cannot play because the file is in use.
ファイルが使用中のため、再生できませんでした。
具体的にbecauseとsinceの違いを見てみましょう。
Because you moved away, I never go to the movies.
※あなたが離れてしまったので映画に行っていないと明確に理由を述べています。
Since you moved away, I never go to the movies.
※最初の節は主節が起こっている期間を明確にしているだけで、「なぜ」映画に行かないかについては言っていません。しかしながら、日常的な用法では映画に行かなくなったのはあなたが離れたことが理由という意味に解釈されます。
Microsoftのスタイルガイドラインでは、以下のようにテクニカルライティングにおいて“because”と“since”を区別すること（“because” は理由について使用し、”since“は時間の経過について使用する）は翻訳時やノンネイティブに対してあいまいさを減らすため重要であると強調しています。
“Do not use since to mean because. The use of since to mean because can be confusing to the worldwide audience, and the possible ambiguity may lead to mistranslation in machine-translated content. In general, use because to refer to a reason and since to refer to a passage of time.”
また“as”についても、理由を表す場合や「～の間に」といった時間を表す場合は、ノンネイティブが読むことも考慮し使用を避けるべきとの記載があります。
“Do not use as a synonym for because or while in subordinate clauses. Both uses are grammatically correct, but they make reading more difficult for the worldwide audience. ”
読み手の立場に立って誤解なく正しく伝わるよう、適切な単語の選択が大切です。
ポータブル音楽プレイヤーなどの、スクリーンセーバーを表示するまでの時間を設定する画面に「待ち時間」とあった場合、私たちは通常“delay”を使用しています。“delay”と聞くと、「遅延」などネガティブな印象を受け、“waiting time”などとしたほうがよいのではないかと、日本人の感覚では思ってしまいますが、こういったケースでは、英語ではよく“delay”が使用されるそうです。もっとも、元の英語が比較的そのまま使用されることが多いコンピューター用語に詳しい方にとっては、“delay”の使用は珍しいことではないかもしれません。
<日本語>
待ち時間
15秒
30秒
60秒
<英語>
Delay
15 Sec
30 Sec
60 Sec
英語辞書の Longmanで調べると、以下の記載のように、単に「待ち時間」の長さも意味することがわかります。
delay: when someone or something has to wait, or the length of the waiting time
ただし、多言語に翻訳する際は、翻訳者によく仕様を伝えたうえで、その国や地域に合った訳語にしてもらうよう注意が必要です。日本語でもこの場合「遅延」は適切ではないですね。
アプリケーションのユーザーインターフェイスにおいて使われる英語のメッセージ、“Invalid date”の日本語訳例は「無効な日付です」となります。 では“Invalid claim”の訳はといえば、「無効なクレームです」ではなく、「無効な要求です」となります。
“claim”をカタカナ表記にして「クレーム」と訳すと、「苦情」や「不満」といった意味にとられ、誤解を招く可能性があります。 「クレーム」は和製英語で、英語における本来の意味との違いに気を付けなければならない単語の一つです。
“file a tax refund claim”は「税金還付の請求（要求）をする」という意味です。 このように“claim”には「（当然の権利としての）要求」や「（事実としての）主張」といった意味はありますが、「不満による苦情」や「文句」のような意味はありません。
一方、「不満による苦情」といった意で使う「クレーム」の英訳には“complaint”があります。 ユーザー同士が交流できるオンラインゲームにおいて、不適切なメッセージや画像を掲載しているプレーヤーに関して通報する機能がついているものがありますが、その機能名や説明において“file a complaint”（苦情を訴える）という表現が使われることがあります。
たとえば、海外旅行先で買い物をし、英語で還付請求をしたり（file a tax refund claim）、買い物をしたお店での対応に苦情を訴えたり（file a complaint）することもあるかもしれません。 そんなときは、和製英語の誤用に気を付けて、正しく意図を伝えたいものですね。
「動画コンテンツ」や「デジタルコンテンツ」など、マルチメディア環境で提供される情報やデータは日本語で「コンテンツ」と呼ばれていますね。
では、「コンテンツ」を英語にすると何になるでしょうか？
答えは“content”です。
“content
s”ではないの？と思った方がいらっしゃるかもしれませんが、「コンテンツ」が一つでも複数あっても、英語では常に“content”になります。（不可算名詞ということですね。）
以下にいくつか例文をご紹介します。
＜日本語＞
USBマウント中はコンテンツにアクセスできません。
＜英語＞
Cannot access content while the device is mounted over USB.
＜日本語＞
リカバリ後に登録したコンテンツが参照できなくなります。
＜英語＞
Content registered after the system was recovered will not be available for use.
ちなみに”content“にはいくつかの意味があり、「箱の中身」や「本の内容」のような意味の場合は、可算名詞になります。
例えば、本の「目次」は、英語では“table of contents”です。
“content”と“contents”、一文字の違いですが、「コンテンツ」の意味で“contents”を使用すると、意味が通じなくなるので要注意です。
日本では夜中の12時のことを「午前0時」や「24時」などと言ったりし、「0:00 AM」や「午前0:00」と表記したりします。海外ではどのように表記するのでしょうか。
国によって異なりますが、たとえばアメリカは12時間表示なので、夜中の12時は“12:00 AM”と一般的に表記されます。ヨーロッパは24時間表示なので、イギリスでは夜中の12時は“00:00”といったように、AMやPMを用いないで表記するのが一般的です。
実際にプルダウンリスト等で夜中の12時から表示する場合は、アメリカ方式では以下のような順番になります。
12:00 AM
1:00 AM
2:00 AM
：
日本では時刻表記について製品ごとなどで表現が統一されていることが多いですが、普段使用する際には特に統一されていないため、正午は午前12:00であったり、午後0:00だったりします。アメリカ方式では正午は12:00 PMとなり、少し混乱しますね。
ただ単純に翻訳すればよいというわけではなく、その国に合った表記にすることが必要なローカライゼーションの一例です。
ご参考までに Windows の時刻表記確認方法をお伝えします。Windows 7では、「コントロールパネル」の「地域と言語」で言語を選択すると、以下のようにその言語（国と地域）のフォーマットで時刻が表示されます。みなさんもよかったら試してみてください。各言語（国と地域）のフォーマットを確認することができます。
<英語（米国）>
時刻（短い形式）：12:00 AM
時刻（長い形式）：12:00:53 AM
<英語（英国）>
時刻（短い形式）：00:00
時刻（長い形式）：00:00:53
<日本語（日本）>
時刻（短い形式）：00:00
時刻（長い形式）：00:00:53
アプリケーション使用中に、ユーザーが操作を続行するかどうかを確認するメッセージが表示されますが、英語ではたとえば“Are you sure you want to ～ ?”や“Do you really want to ～ ?”を使った表現を用います。
「このアルバムを削除しますか？」という確認メッセージを“Delete this album?”と英訳しても意味は伝わりますが、ユーザーの意図を確認するという目的を明確に伝えるために“Are you sure you want to delete this album?”とします。
以下の例文は、実行中の取り込み処理を中止する操作をユーザーが行った際の確認メッセージです。
＜日本語＞
取り込みを中止します。よろしいですか？
＜英語＞
Are you sure you want to stop the import?
このメッセージが念のための確認であることは、日本語の「よろしいですか？」からも読み取れますが、英訳する際は、意味を伝えるということだけでなく、ユーザーの意図を確認するといった、その文言が持つ役割についても考慮して翻訳しています。
撮影した動画や写真を使って自動的にショートムービーを作成するアプリの英語ローカライズを、以前に担当しました。
ユーザーは使用する動画や写真に合ったテンプレートを選択しますが、「ウェディング」というカテゴリーの中にブーケの演出でかわいくまとめた「キュート」という名前のテンプレートがありました。
ネイティブチェック担当者にこのテンプレートは英語版で“Cute”にしてよいか聞いたところ、｢”cute”は、否定的な意味で使用される場合もあるので、やめた方がよい。｣と言われ、英語版では“Lovely”を使用
することになりました。
英語での“cute”の意味が気になったので、別の英語ネイティブにもう少し詳しく聞いたところ、日本語と同じく「（例えば赤ちゃんや子犬が）かわいい」という意味がある以外に、性的魅力がある男性に対して使われる場合もあるそうです。
英語辞書の Longmanで調べたところ、下記の 3 番のように「抜け目のない」というような意味もあることが分かりました。
Longman の“cute”検索結果：
1. very pretty or attractive
2.
especially American English sexually attractive
3.
especially American English clever in a way that can seem rude
多くの英単語が日本語にカタカナで取り入れられていますが、英訳する場合は両言語で同じ意味なのか、確認することの重要性を改めて感じた一件でした。
次の例文に含まれる、「24 ビット」や「16 ビット」の英訳に注目してください。
＜日本語＞
現在編集を行っているプロジェクトのサンプリングビット数は 24 ビットに設定されているため、16 ビット録音のみが行えるマイク端子、ライン入力端子を使用しての録音は行えません。
＜英語＞
Cannot start recording because the bit depth of the current project is set to 24 bits, but the MIC and LINE IN inputs support only 16-bit recording.
「24 ビット」「16 ビット」ともに 2 以上の数に言及していますが、表記はそれぞれ“24 bits”と“16-bit”と異なっています。
“24 bits”の“bits”は“bit”の複数形であり、“16-bit”の“bit”は数と単位をハイフンでつないだ複合形容詞の一部です。複合形容詞の一部として使われている単位“bit”は複数形にはなりません。
複合形容詞といえば、“He has a sixty-year-old mother.”のような例文で習った方も多いのではないかと思います。“She is sixty years old.”という文の“years”が名詞の複数形であるのに対し、“sixty-year-old”の“year”は複合形容詞の一部なので“years”と複数形にはなりません。
複合形容詞として“sixty-year-old”と“16-bit”はそれぞれ後に続く“mother”、“recording”を修飾しています。
ちなみに「ビット」を形容詞的に使った表現として、“a 64 bit machine”というようにハイフンを用いない文言も見かけます。広く一般的に使われる複合語の中には、ハイフンでつながなくても意味的に誤解を生じないとみなされるものがあり、“bit”に関してもハイフンでつながずに形容詞として使うことが許容されているようです。
この例からもわかるように、ハイフンに関する絶対的な不変のルールがあるわけではありません。英訳時には、参照すべきスタイルガイドなどにハイフンについての規定があれば、それに合わせ、特に規定がない場合には、少なくとも文書内での表記方法を統一することが大切となります。
英訳をしていて困ることの一つは、原文の日本語にぴったり合う英語表現がない場合です。
その一例として、日本語の「～以上」「～以下」があります。
日本語で「５以上」というと、「５かそれより大きい」という意味で「５」が含まれますが、英語では「以上」にあたる単語はなく、近い表現の“more than ～”は「～より大きい」という意味なので、“more than 5”は「６以上」という意味になります。
「以下」も同じく、「５以下」に「５」は含まれますが、“less than ５”に「５」は含まれません。
（英語の“less than”は、日本語の「未満」にあたりますね。）
ユーザーインターフェイス（UI）文言で「以上」や「以下」はよく使われますし、ローカライズ時に気をつけて翻訳をしないと、誤った情報を伝えユーザーの混乱を招きかねません。
下記は私たちの「以上」、「以下」の英訳例です。
＜英訳例＞
日本語：一つ以上のフォルダを選択してください。
英語：Select at least one folder.
日本語：二つ以上のビデオを選択してください。
英語：Select two or more videos.
日本語：2 MB 以下の動画ファイルは DVD-VR に出力することができません。
英語：Cannot output a video file whose file size is 2 MB or smaller to DVD-VR.
「以上」と“more than”の違いを知った時、「ただの友達以上」と“more than just friends”も意味が違うのだろうか？と思いました。
いやいや、「あなたはただの友達以上」と言われたら、喜んでいいのですよね？
[設定]といったように、ユーザーインターフェイス（UI）文言の日本語のメニュー名などで、よく[]が使用されているのを目にします。英語ではそういったメニュー名などでは[]は使用せず、単語の先頭の文字を大文字にしてそのまま記載することが多いです。
＜例文＞
日本語：設定画面は [設定] をクリックすると表示することができます。
英語：Click Settings to display the settings window.
日本語：設定は [ツール] - [設定] の [高度な設定] の項目で確認することができます。
英語：The settings can be confirmed by selecting Settings from the Tools menu and clicking the Advanced Settings panel.
SDNAネイティブチェック担当者によると、英語ではメニュー名などを[]で囲むことはせず（少し不格好とのこと）、強調したい場合はボールド（太字）にした方が良いそうです。
UI文言以外でも、日本ではたとえばメールの件名でもよく[]を使用しますが、英語では[IMPT]（重要）、[URGENT]（至急）などは強調するために使用することはあるが、通常はあまり使用しないとのことです。
このようにカッコの表記にしても、日本では一般的でも海外ではそうではないということがありますね。
アプリケーションの日本語版ユーザーインターフェイス（UI）文言では、キーボード上の方向キーの表記として矢印記号を使っています。
たとえば「Ctrl+↑」という文言は、キーボードの“Ctrl キー”と“↑キー”（上方向キー）を一緒に使用することを意味しています。
“上方向”ではなく矢印記号“↑”を使うこの表記は、Microsoft のサイトやスタイルガイドに、方向キーに言及するときの留意点として「← キー」「→ キー」「↑ キー」「↓ キー」を使用するとあることからも、広く認知された方法と言えます。
一方、英語表記では“Ctrl+Up Arrow”や“Ctrl+Up”というように、矢印記号ではなく、語句を用いています。
多くのキーボードにおいて、方向キーのラベルには、語句ではなく“↑”や“▲”といった記号が使われるのが一般的なので、当然のように「Ctrl+↑」といった UI 文言は世界共通で使える表記だと思ってしまいそうですが、むしろ多くの言語において、英語のように語句を使って表記するケースが多いようです。
（「Ctrl+↑」のフランス語例：Ctrl+Flèche haut）
ちなみに“Ctrl”についても、ローカライズをする際には気を付けたいポイントです。 というのも、たとえばドイツ語向けのキーボードでは“Ctrl”は、“STRG”や“Strg”といったラベルになっているものもあるため、「Ctrl+→」をドイツ語で表記する場合は“Strg+Rechts”というようにローカライズする場合もあるからです。
以下、キーボードに言及している日英の UI 文言例を、参考までにいくつかご紹介します。
| 日本語 |
英語 |
| Ctrl+← |
Ctrl+Left |
| Ctrl+→ |
Ctrl+Right |
| Ctrl+↑ |
Ctrl+Up |
| Ctrl+↓ |
Ctrl+Down |
| 前の画像 (←) |
Previous (Left Arrow) |
| 次の画像 (→) |
Next (Right Arrow) |
日本語で「音楽 CD ケースの中に入っている絵や写真がついた紙」と言えば、「ジャケット」ですよね？
ジャケットが気に入って購入する「ジャケ買い」なんて言葉もあります。
以前にメディアプレーヤーアプリの英語化を担当していた時、ジャケット写真の英訳は“album artwork“、“cover art“、“album art“、“cover”など一つでないことが分かりました。
また、英語の”jacket”は、日本語の「ジャケット」より狭義のようで、レコードを入れる厚紙ケースを指すようです。
英語辞書の Longman では、”jacket”は以下のように定義されています。：
American English a stiff paper cover that protects a record [= sleeve
British English]
ブリティッシュ英語では、”sleeve”と言うのですね・・・。
今回この記事を書くにあたって改めていくつかのメディアプレーヤーアプリを確認したところ、Android Walkman は日本語版でジャケットの写真を「カバーアート」と呼び、iTunes は「アルバムアートワーク」と呼んでいました。
日本語の「ジャケット」の意味も少し変わってきているのでしょうか？
日本語で注釈を表す「※」（米印）は英語では何を使用すればよいでしょうか？
“*”（アスタリスク）が使用されているのを見かけることがよくありますが、私たちが「※」または「ご注意」を英語化する際は、基本的に“*”ではなく、“Note:” としています。
アスタリスクは見た目は似ていますが、脚注として使用されるので米印の代わりにはならないそうです。
＜参考文例＞
日本語：
※ 写真のスライドショーには適用されません。
英語：
Note: This setting does not apply to slide shows.
日本語：
ご注意：削除する曲数が多い場合は、時間がかかる可能性があります。
英語：
Note: This process may take a long time if a large number of songs were selected.
国や地域によってその記号が何を表すか異なる場合がありますので、それぞれの国や地域に適した表記にすることが大切です。
前回は色々な言語で「０」は単数扱いか、複数扱いかというお話でしたが、今回は少しマニアックな 1 未満の正数の扱いのお話です。
例えば 0.1 は英語で単数として扱われるか、複数として扱われるか、どちらだと思いますか？
正解は・・・それぞれ正しいという見解があるようです。
「正確なルールはなく、単数扱い、複数扱い両方されている」
「1 以外の数字は複数扱いにするのが無難」
という見解がある一方、Microsoft のスタイルガイドラインには、
「単位が省略形でない場合、１またはそれ未満の数量には単数を使用する。例外として 0 は複数形。」
とあります。
Android の“Writing Style”には、1 未満の数量の扱いに関する記述はありませんが、文言の中に“0.5 seconds”や“0.5 hours”がありました。
Apple スタイルガイドにも 1 未満の数量の扱いに関する記述を見つけることができませんでしたが、スタイルガイドの中に“decibel (0.10 bels)”という記述を見つけました。
最後にアメリカ人テクニカルライターのコメントを紹介します。
「多くのスタイルガイドが何と決めようと、ネイティブスピーカーの一般的な用法では -1 から 1 の間の値の後に複数形の単位を使います。しかし、なぜだか分かりませんが単数扱いと定義しているスタイルガイドラインもあります。」
ちなみにこのトピックについて“This is always sticky (やっかいな) question.”と言っていました。
“BGM”は何の略語でしょうか？
ご存知の方も多いと思いますが、日本では“background music”の意味でよく使用されていますね。
ユーザーインターフェイス（UI）文言の日本語に“BGM”が含まれていた場合は英語では“background music”を使用しています。一般的に“BGM”は英語では使用されず、ネイティブにとっては何のことを言っているか分からないそうです。
＜参考文例＞
日本語：
メニュー画面の BGM を設定します。
英語：
Select Background Music for the disc menu.
ただ、文言が表示される領域の制限や自然な表現のため、文言によって英語では以下のように単に“music”とする場合もあります。
＜参考文例＞
日本語：
スライドショーBGM
英語：
Slideshow Music
これですと文字幅も気にならず、“background”が含まれていなくても十分意味が通じますね。
Windows OS では「内部スピーカー」を“internal speaker”と呼んでいますが、私たちが担当したポータブルオーディオプレーヤーの「内蔵スピーカー」は“built-in speaker”と表現しました。
仕様としてはプレーヤーの背面にあるスピーカーから音が出ますが、内蔵された本体から直接音がでる場合に“internal”を使用するのは違和感があるという意見が、アメリカのマーケティング担当者から出たためです。代案として“built-in speaker”を提案したところ、その方がしっくりくるとのことでした。
念のため他の英語ネイティブに確認したところ、
「内蔵された機器から音が出るスピーカーに“internal speaker”を使用することができないとは思わないが、“built-in speaker”の方が良い選択だと思う。コンピューターに内蔵され、本体外に音が出るスピーカーは長年“internal speaker”と呼ばれてきたが、“built-in speaker”の方が多分、より明確で誤解が少ないと思う。」
とのことで、やはり“built-in speaker”の方がふさわしいことが分かりました。
すでに一般的と思われる用語も、その文言が使用される場所（ユーザーインターフェイス）や仕様をネイティブに伝えることにより、よりふさわしい表現を引き出すことができると日々の業務で実感しています。
ちなみに、スピーカーがモノラルの場合は“speaker”と単数形を使用し、ステレオの場合は“speakers”と複数形を使用します。
日本語では「～など」のように、「その他」を意味して「など」が使用されているのを多く目にします。
UI などテクニカルライティングでは、日本語もあいまいさを避けることがルールとなっていますが、英語化を行う際は日本語に「など」が含まれている場合は、その「など」が具体的に何を指すのか文言作成者に確認します。「など」が指すものを具体的に挙げることができ、かつスペースが十分にある場合は英語ではなるべく具体的に表記するようにしています。
＜参考文例＞
日本語：プロジェクトや録音した曲のファイルなどを保存するフォルダを指定します。
英語：Specify the folder that stores project files, and recorded and imported sound files.
※ここでは「など」は“imported (sound files)” と具体的に表記しています。
ただ、そもそも「など」としているのはいろいろなケースを想定しており、その全てを記載しきれないという事情があるため、その結果英語では以下のように「など」以前で言い切る形にすることが多いです。
＜参考文例＞
日本語：取り込んだ映像や一時ファイルなどもここに保存されます。
英語：Video, Pictures and temporary files are stored here.
※ここでは「など」は特に表記していません。
もし日本語文言の構成に合わせて「など」を入れなければならない場合は、「テクニカルライティングでは“etc.”の使用は避けたほうが良く、“and so on”を使用するべき。」と SDNA ネイティブチェック担当者は言っています。Microsoftガイドラインでは 「ボタンのラベルのようにスペースがあまりにも限られているような場合以外は“etc.”は使用しないこと。」“and so on”については、「画面スペースが限られている場合や、“...a, b, c, and so on.”のように、少なくとも2つの項目の論理的進行を示すような場合以外は使用しないこと。“and so on”によって具体的な情報を与えるわけではないためあいまいさを生んでしまう。」といった記述があります。
UI文言ではあいまいさをなるべく避けた簡潔な表現になるよう、また、単純な翻訳ではない、違和感のない文言になるようローカライズを行っています。
あるアプリケーション用にお客様対応窓口を表す英語を用意するために調べてみたところ、これまで日常生活の中では意識せずに見聞きしていた「カスタマーサービス」や「サービスセンター」に、以下のような使い分けがあることがわかりました。
「カスタマーサービス」（customer service）が、ユーザーからの操作方法等についての問い合わせに対応するための部門や、対応そのものを指すことが多いのに対し、「サービスセンター」（service center）は、不具合のある電気製品などが持ち込まれたり、送られたりする場所や、修理される施設を指すことが多いのだそうです。
よって、上記二つの文言のうち、アプリケーションに関する問い合わせ先を表す英語としては“customer service”を使うことにしました。
日本語から英語、そしてさらに、英語から他言語へとローカライズを進める場合、英訳時に気になって調べたことは、他言語翻訳者へも伝達し、翻訳時の参考としてもらっています。 今回のケースで言えば、“customer service”が「アプリケーションに関するユーザーからの問い合わせ先」を表すということを補足情報として他言語翻訳者に伝えることで、誤解のない翻訳結果を得られるようにしました。 このように英訳の品質を高めるために行ったことを、他言語翻訳の品質保持にも役立てながら、複数言語へのローカライズ業務を進めています。
以前に英語ローカライズを担当したアプリの中で、何枚か並んでいる写真を一枚表示させ、次の写真、前の写真とボタンを選択して移動するユーザーインターフェイスがありました。
この場合、前の写真へ戻るボタンは、“previous”と“back”のどちらがふさわしいか疑問に思い、ネイティブに質問しました。
ネイティブの回答は、
「“previous”は『順番に並んでいるものの一つ前』、“back”は『(基本的に）直前に見たもの』に戻る場合に使用されるので、今回は“previous”がふさわしい。
例えば、写真 A, B, C が順番に並んでいて、ユーザーが写真 A を見て次に C を見た場合、“previous”ボタンを選択したら写真 B が表示されます。
“back”ボタンを選択したら、写真 A が表示されます。」でした。
上記の説明を図にすると、下記のようになります。
ウェブブラウザーの「戻る」ボタンが英語版で"Back"になっているのは、「直前に見た画面に戻る」という意味だからですね。
disc
オーディオ CD、CD-ROM、DVD-ROM、DVD-RAM、DVD-Video ディスクなどの光記録メディアを指します。
disk
フロッピーディスク、コンピューターのハードディスクドライブ(HDD)内のディスク、外付けHDDなどの磁気記録メディアを指します。
日本語ではどちらも「ディスク」と表記されますが、英語では上記のように ”disc” と ”disk” を区別して表記します。
たとえば、「ディスク空き容量」という日本語に対し、英語ではDVDなどのディスクの場合は ”Free disc space” となり、 HDDなどのディスクの場合は ”Free disk space” となります。
上記の使い分けには諸説あるようですが、マイクロソフトのスタイルガイドラインでも定義されており、IT商品における一般的なルールになります。
アプリケーションなどのユーザーインターフェイス（UI）上で使用される日本語文言には「～してください」といった丁寧な表現がよく見られますが、英語に翻訳する際、”please” を使うことはほとんどありません。
＜参考文例＞
日本語：
タグ名を入力してください。
英語：
Enter a tag name.
UI 上の英語文言は冗長さを排した直接的な指示文とすることが通例となっており、”Please enter a tag name.” とはしていません。 Android の Writing Style でも ”please” の使用を避けることについて触れられています。
近年、タブレットや携帯電話など多様な機器で使われるアプリケーションが増える中、小型端末上での UI 文言の表示スペースが小さい場合も多く、より簡潔な表現が求められていると感じます。
ただ UI 上の英語文言であっても、アプリケーションでの問題発生時などに、ユーザーをわずらわせるような作業をお願いする文言では、表現を和らげるために ”please” を使うこともあります。
＜参考文例＞
日本語：
サーバーとの通信に失敗しました。 ネットワークの接続をご確認いただき、もう一度やり直してください。
英語：
Communication with the server failed. Please check your connection and try again.
私たちが日本語 UI 文言の英訳をするとき、その文言の用途や、その文言にまつわる文化などを考慮した翻訳を心がけています。 さらに、私たちが翻訳した英語をネイティブスピーカーにチェックしてもらうことで、より自然で、適切な英語となるようにしています。
Web 上のサービスへ「ログインする」という日本語を "log in" と英訳したところ、ネイティブチェック担当者が次のような理由で "sign in" へ変更しました。
「（インターネットアカウントへは）"log in" より "sign in" の方が一般的と言ってよいと思う。
"log in" は、やや昔風のコンピューター用語のように聞こえる。
一方 "sign in" は日常的に使用されており、例えば立ち入り制限区域で物理的にリストにサイン（sign）して立ち入り許可をもらうなど、技術系ではない、より幅広い人々も意味がすぐ理解しやすい。」
Microsoft のスタイルガイドラインには、インターネットアカウントのユーザーセッションを開始、終了する時に "sign in" "sign out" を使用し、コンピューターやイントラネットユーザーアカウントのユーザーセッションを開始、終了する時に "log on" "log off" を使用すると書かれています。（ちなみに "log in" と "log out" は、ユーザーインターフェイスで使用されていない限り使用しない、とも書かれています。）
形容詞的に使用する場合は、"The sign-in account has been changed." のようにハイフンを入れます。
オリンピックで「204の国と地域から参加」というようなフレーズを聞きますが、なぜ「国と地域」と表現するかご存知ですか？
下記のような国名を選択する画面でも、選択肢のタイトルは｢国と地域｣としています。
（英訳すると「地域」は "area" または "region" です。）
これは様々な理由により国家と承認されていない国があり、その国々を「地域」と表現しているためです。
承認についてはそれぞれの立場があり、デリケートな事柄で思わぬ問題を起こす可能性もあるため、私達は必ず対応しています。
私たちのネイティブチェック担当者に "area" と "region" の違いを聞いたところ、「この場合、どちらを使用しても問題ないが、"area"が大まかで抽象的であるのに対して、"region”は地理的なニュアンスを持ち分かりやすいと思うので、"country/region"の方がよい。」 とのことでした。