ソフトウェアのインターナショナリゼーション（I18N）では「ソースコードと表示テキストの分離」という作業をします。分離して別ファイルにしておくことで、外部の翻訳業者にテキストを送って翻訳してもらえたり、翻訳者が誤ってソースコードを編集してしまうことを回避したりと、ローカリゼーション（L10N）がやりやすくなるわけです。開発と翻訳の分業です。
【よくある形式の翻訳ファイル】
SNS機能が付いた本棚登録アプリみたいなものがあったとして、例えば以下のようなメッセージが表示されるとします：
SNS上で友達である「タロウ」さんは、読んだ本を5冊登録しているという単純なメッセージです。開発時には「名前」と「冊数」の部分を変数にしておき、実行時に具体的なテキストを代入すれば良さそうです。例えば前者の変数を仮に{0}、後者を{1}とすると…
と書けます。
こういったメッセージをまとめて外部ファイルにしておくまでが開発者が担当するI18Nで、その後に翻訳会社に送ってL10N（英訳など）してもらいます。そういったファイルは「キー」と「値」という形式で書かれることが多いと思います。例えばJavaのpropertiesファイルであれば以下の形式です。
イコール記号の右側にある「値」部分を翻訳するわけです。L10N分野の翻訳会社や翻訳者であれば、こういった形のファイルを見たこともあるでしょう。
【翻訳側での限界】
上記のメッセージを英訳する場合、例えば以下のように訳せそうです。
英語では名詞に単数と複数があるため冊数に応じて「1 book」、「2 books」などとするはずですが、1メッセージにまとめなければならないため、「book(s)」というあまり理想的ではない書き方を選択せざるを得ません。また、ユーザーの性別に応じて代名詞を「his」または「her」としますが、同様に1メッセージにまとめなければならないため、「his/her」という書き方になります。
どうにかこうにか英語にはできそうですが、必ずしも望ましい言語表現ではなさそうです（そもそも「0冊の本があります」ではなく「本がありません」といった表現の方が良いかもしれない）。
特に変数が組み込まれたソフトウェアUIのメッセージを、文法などが異なる言語に翻訳するのは苦労が多いわけです。
【最近増えつつあるやり方】
メッセージを1対1で対応させて翻訳すると前述のような無理が発生するため、最近では場合分けで翻訳できる仕組みが広がりつつあるようです。とりわけ名詞の「複数形」が場合分けの基準になることが多くなっています。比較的多くのソフトウェア企業で用いられている（らしい）ICUのメッセージ・フォーマットに関するページには以下のような例が掲載されています。
（http://userguide.icu-project.org/formatparse/messages より引用）
一見すると複雑ですが、「パーティーにホストが何人招待したか」を表すメッセージです。
まずホストが女性の場合、「female」と書かれたブロックが選択されます。さらに、
・ゲストが0人の場合： 最上段の「{host} does not give a party.」
・1人の場合： 2段目の「{host} invites {guest} to her party.」
・2人の場合： 「{host} invites {guest} and one other person to her party.」
・それ以外の人数の場合： 「{host} invites {guest} and # other people to her party.」
が選択されます。
ホストが女性であるため「her party」となっています。同様にホストが男性の場合、2つめの「male」というブロックから人数に応じてメッセージが表示されます。L10Nの際は、このように場合分けされたメッセージのそれぞれを訳すことになります。
最近このような方法が増えている背景には、さまざまな複数形（plural）を持つ言語に対応しようという機運が高まっている点があるのではないかと思います。各言語の複数形をまとめたUnicodeのサイト（CLDR）を見ると、日本語や中国語では名詞の単数と複数は特に区別しません（otherのみ）。英語やフランス語では単数形と複数形の2種類（oneとother）があります。さらにロシア語では4種類（one、few、many、other）、アラビア語では6種類（zero、one、two、few、many、other）に分けられています。
さまざまな現地語に翻訳するのがL10Nであり、それを可能にする仕組みをソフトウェア側で用意するのがI18Nであることがよく分かります。
先ほど示した画像を見ると、場合分けのテキストはなかなか複雑です。翻訳者がこれを翻訳するにはある程度プログラミングに関する知識が必要になるでしょう。一方、多言語化されるソフトウェアの開発者も、さまざまな言語に関する理解が求められそうです。
以上です。
【よくある形式の翻訳ファイル】
SNS機能が付いた本棚登録アプリみたいなものがあったとして、例えば以下のようなメッセージが表示されるとします：
タロウさんの本棚には5冊の本があります。
SNS上で友達である「タロウ」さんは、読んだ本を5冊登録しているという単純なメッセージです。開発時には「名前」と「冊数」の部分を変数にしておき、実行時に具体的なテキストを代入すれば良さそうです。例えば前者の変数を仮に{0}、後者を{1}とすると…
{0}さんの本棚には{1}冊の本があります。
と書けます。
こういったメッセージをまとめて外部ファイルにしておくまでが開発者が担当するI18Nで、その後に翻訳会社に送ってL10N（英訳など）してもらいます。そういったファイルは「キー」と「値」という形式で書かれることが多いと思います。例えばJavaのpropertiesファイルであれば以下の形式です。
…
buttonLogIn = ログイン
buttonLogOut = ログアウト
messsageNumOfFriendsBooks = {0}さんの本棚には{1}冊の本があります。
…
イコール記号の右側にある「値」部分を翻訳するわけです。L10N分野の翻訳会社や翻訳者であれば、こういった形のファイルを見たこともあるでしょう。
【翻訳側での限界】
上記のメッセージを英訳する場合、例えば以下のように訳せそうです。
{0} has {1} book(s) in his/her bookshelf.
英語では名詞に単数と複数があるため冊数に応じて「1 book」、「2 books」などとするはずですが、1メッセージにまとめなければならないため、「book(s)」というあまり理想的ではない書き方を選択せざるを得ません。また、ユーザーの性別に応じて代名詞を「his」または「her」としますが、同様に1メッセージにまとめなければならないため、「his/her」という書き方になります。
どうにかこうにか英語にはできそうですが、必ずしも望ましい言語表現ではなさそうです（そもそも「0冊の本があります」ではなく「本がありません」といった表現の方が良いかもしれない）。
特に変数が組み込まれたソフトウェアUIのメッセージを、文法などが異なる言語に翻訳するのは苦労が多いわけです。
【最近増えつつあるやり方】
メッセージを1対1で対応させて翻訳すると前述のような無理が発生するため、最近では場合分けで翻訳できる仕組みが広がりつつあるようです。とりわけ名詞の「複数形」が場合分けの基準になることが多くなっています。比較的多くのソフトウェア企業で用いられている（らしい）ICUのメッセージ・フォーマットに関するページには以下のような例が掲載されています。
（http://userguide.icu-project.org/formatparse/messages より引用）
一見すると複雑ですが、「パーティーにホストが何人招待したか」を表すメッセージです。
まずホストが女性の場合、「female」と書かれたブロックが選択されます。さらに、
・ゲストが0人の場合： 最上段の「{host} does not give a party.」
・1人の場合： 2段目の「{host} invites {guest} to her party.」
・2人の場合： 「{host} invites {guest} and one other person to her party.」
・それ以外の人数の場合： 「{host} invites {guest} and # other people to her party.」
が選択されます。
ホストが女性であるため「her party」となっています。同様にホストが男性の場合、2つめの「male」というブロックから人数に応じてメッセージが表示されます。L10Nの際は、このように場合分けされたメッセージのそれぞれを訳すことになります。
最近このような方法が増えている背景には、さまざまな複数形（plural）を持つ言語に対応しようという機運が高まっている点があるのではないかと思います。各言語の複数形をまとめたUnicodeのサイト（CLDR）を見ると、日本語や中国語では名詞の単数と複数は特に区別しません（otherのみ）。英語やフランス語では単数形と複数形の2種類（oneとother）があります。さらにロシア語では4種類（one、few、many、other）、アラビア語では6種類（zero、one、two、few、many、other）に分けられています。
さまざまな現地語に翻訳するのがL10Nであり、それを可能にする仕組みをソフトウェア側で用意するのがI18Nであることがよく分かります。
先ほど示した画像を見ると、場合分けのテキストはなかなか複雑です。翻訳者がこれを翻訳するにはある程度プログラミングに関する知識が必要になるでしょう。一方、多言語化されるソフトウェアの開発者も、さまざまな言語に関する理解が求められそうです。
以上です。
