100言語を話すようにWebアプリケーションを教える方法：ローカライズ機能

オンラインサービスの重要な機能は、世界中のほとんどのユーザーが異なる言語を話すユーザーにアクセスできることです。 そのようなサービスを開発していて、さまざまな国の人々にそのサービスを使用してもらいたい場合は、翻訳および適応、つまりローカライズする必要があります。

この記事を書くというアイデアは、 MoscowJSミーティングの後に生まれました。 そこでは、Badooでのローカリゼーションプロセスがどのように進行しているかについて話しました 。 しかし、この記事では、Webアプリケーションの例でのローカリゼーションの機能、ローカリゼーションソリューションの存在、およびBadooで独自の方法が採用された理由についてもう少しお話ししたいと思います。 心配するすべての人に-猫の下で歓迎。

なぜですか？

ロシア市場のみに焦点を当てる場合、おそらくローカライズは必要ないでしょう。少なくとも、あなたの製品が国際的な視聴者にとって興味深いものになるまではローカライズは必要ありません。 その後、アプリケーションを新しい現実に非常に迅速に適応させる必要がありますが、これはそれほど単純ではありません。 したがって、あなたはすぐに決定し、質問に答える必要があります ： あなたは本当にローカライズが必要ですか？ あなたが肯定的な答えに傾いているなら、あなたのサービスはさまざまな言語機能のために準備される必要があります。 一般に、このような機能を考慮することができる手法とツールは国際化と呼ばれます。これは、追加の変更なしで、異なる言語で、異なる地域特性で動作するアプリケーションを作成するプロセスです。



次に答える質問は、なぜローカライズが重要なのですか？ そして、それは主にユーザーと顧客にとって重要です。なぜなら、それぞれがアプリケーションを快適に使用できると感じるからです。 たとえば、ある国の居住者は、英語をよく知っていても、母国語で買い物をすることを好みます。 また、ほとんどの人は母国語でサポートサービスを使用することを好みます。 約50か国のヨーロッパを取り上げると、実際にはそれぞれの国に日付、数値、通貨を表示するための独自の地域機能があります。 そして、視聴者を全世界に広げると、中国、イラン、アフガニスタン、サウジアラビアなどの国が現れ、テキストは右から左、または上から下に書かれ、数字自体はインドアラビア数字またはペルシャ数字を使って書かれています。

言語機能

ローカライズを導入する場合、 まず言語のどの機能に注意する必要がありますか？ まず、日付と時刻の表示形式に注意する必要があります。 次の表は、国ごとのいくつかの形式の依存関係を示しています。 ご覧のとおり、ほとんどの国では形式が異なります。

書式	日付の例	国
yyyy.MM.dd	09.09.22	ハンガリー
yyyy-mm-dd	2016-09-22	ポーランド、スウェーデン、リトアニア、カナダ
yyyy / mm / dd	2016/09/22	イラン、日本
dd.MM.yyyy	2016年9月22日	ロシア、スロベニア、トルコ、ウクライナ
M / d / yyyy	2016年9月22日	アメリカ

時間の記録形式も国によって異なります。 たとえば、米国、カナダ、オーストラリア、ニュージーランドでは、12時間形式（英語システム）が使用され、その他の地域では、24時間形式（フランス語システム）が使用されます。

次の機能は、数値形式と通貨表示です。 次の表からわかるように、1000桁および小数点の区切り記号は、コンマ、ピリオド、または空白文字のように見える場合があります。 また、通貨記号の位置は、言語だけでなく国によっても異なる場合があります。 たとえば、ドイツやオーストリアなどの国は同じ言語を話しますが、通貨の形式は異なります。

例	ロケール	国
123 456,79€	るーる	ロシア
€123,456.79	en-US	アメリカ
123,456,79€	デデ	ドイツ
€123,456.79	脱AT	オーストリア

特に興味深いのは、中国の伝統的な数字です。 中国語では、数字はロシア語などとは異なる方法で数字に分割されます。 私たちは、数千に応じて多数をグループに分割するのに慣れていますが、中国は数万に応じてグループに分割します。 たとえば、150.000.000という数値を1亿5000万と書き込みます。 さらに、中国人は「数値迷信」を非常に強く信じており、数秘術を真剣かつ思慮深く捉えています。 たとえば、数字4は「死ぬ」という言葉のように聞こえますが、中国人はそれを避けようとしています。 多くのホテルでは、4番の部屋、時には4階の部屋も見つかりません。 たとえば、銀行口座にも同じことが当てはまります。単純な中国人の夢は、富と繁栄の象徴である8の数字を持つことです。

また、米国、ミャンマー、リベリアで使用されている英語の対策システムが問題になる可能性があります。 重要な理由： 火星に飛んで落下した火星の人工衛星を思い出す価値があります。宇宙機器のチームはニュートンで力を使用し、地球のソフトウェアはポンド力を使用したためです。 飛行中、間違いを疑った人はいなかった。 その結果、1億2500万ドルかかりました。 そのため、ユーザーの慣習的な測定で結果を表示することを忘れないでください。

日付と数値の形式がわかったら、翻訳機能に進むことができます。 そして、最も明らかな問題は、数字の後の名詞の変化です。 ご存じのとおり、ロシア語には複数の形式が3つありますが、英語には2つしかありません。 ただし、このような形式が6つある言語もあります。 たとえば、このリンクには、各言語のフォームのテーブルがあります。

ロシア語		英語
あなたは1つの贈り物を持っています	単数形	あなたは1つの贈り物を持っています
あなたは5つの贈り物を持っています	複数	あなたは5つの贈り物を持っています
2つのギフトがあります	少ない

次に、ブロック全体（翻訳の機能）を強調表示できます。 考慮すべき機能が十分にあります。

1.フレーズや文章全体を翻訳します 。 異なる言語の単語のシーケンスは異なる可能性があるため、それらをコンポーネントに分割することはできません。


たとえば、15,311人中8,283人があなたのことを気に入りました。
英語の場合、次のようになります。

<b>{{num_voters_yes_maybe}}</b> out of <b>{{num_voters_total}}</b> {{people}} liked you! 

しかし、日本語では、同じ文はすでに異なって見えます：

 <b>{{num_voters_total}}</b>{{people}}<b>中{{num_voters_yes_maybe}}</b>人があなたを気に入っています！ 

この例からわかるように、日本語では、単語の逆順です。 したがって、多くの場合と同様に、 ' ' + pageNum + ' ' + totalだけ書くことはできません。

2.一部の翻訳は、性別によって異なります。

以下の例からわかるように、英語で男性と女性の両方に1つのフレーズを指定できる場合、性別ごとにスロバキア語でフレーズがあります。

英語

 You got an award on <span>{{award_date}}</span> 

スロバキア

 : Toto ocenenie si získal <span>{{award_date}}</span> : Toto ocenenie si získala <span>{{award_date}}</span> 

3.改行はコンテキスト固有でなければなりません。 翻訳者は、文、フレーズ、または段落全体の意味を知っている必要があります。そうしないと、翻訳者は誤解して誤って翻訳する可能性があります。 たとえば、「 この{{item}}を保存できます 」などの文には、別の翻訳がある場合があります。「 この{{item}}を保存/保存できます 。」 理想的には、翻訳者は翻訳用の一連の行だけでなく、この行が配置されている領域の画像も表示する必要があります。

4.翻訳リソースの再利用は安全ではない場合があります。 たとえば、「保存」（ファイル）と「保存」（設定）には、一部の言語で異なる名前が付いている場合があります。 または、スレッドのような単語は「スレッド」と翻訳することも、「スレッド」と翻訳することもできます。

ここで、おそらく、Webアプリケーションのローカライズ時に遭遇する最も一般的な機能を特定しました。 しかし、これはローカリゼーションが影響するすべてではありません。デザイン機能もそれに起因する可能性があるためです（たとえば、日本語と中国語ではより大きなフォントが必要です。一部の言語では、テキストがたとえば英語の2倍になります）。 カラーパレット（異なる文化の赤と緑は反対のものを意味します。たとえば、日本語の赤いチェックマークは何か間違ったことをしたことを意味します）。 使用されている画像（はい、アジアのアジア人、ヨーロッパのヨーロッパ人を表示するのが良いでしょう）や、特定の国や文化に特徴的な他の多くの側面。 これはすべて記事の範囲外ですが、覚えておく価値があります。

それでは、インターネットを見て、クライアントのローカリゼーションにどのツールが存在するのか見てみましょう。

クライアントのローカライズ方法

インターフェースの開発と複雑なビジネスロジックの実装により、開発者はすでにクライアントでのローカリゼーションの多くの問題を解決する必要がありました。 ECMAScriptが特定の時点まで提供していた国際化の可能性はかなり乏しかったため、Closure、Globalize、YUI、Moment.jsなどのライブラリや開発者自身のソリューションの一部が登場し始めました。 それらはすべてECMAScriptの可能性を拡大し、国際化のギャップを埋めましたが、ソリューションには異なるプログラミングインターフェイスと、たとえば文字列比較に関連する特定の制限がありました。 そのため、2012年12月にECMA-402標準が登場しました。これは、アプリケーションを国際化する際のフロントエンド開発者の生活を簡素化することになっています。 しかし、これは本当にそうですか？ この標準が今私たちに提供するものを見てみましょう。

ECMAScript国際化API

これは、言語または国の言語的および文化的特性に適応するためのECMAScriptプログラミングインターフェイスを記述する標準です。 作業は、数値（Intl.NumberFormat）、日付（Intl.DateTimeFormat）、および文字列比較（Intl.Collat​​or）をフォーマットする機能を提供するIntlオブジェクトを介して行われます。 現在、すべての最新ブラウザーでサポートされています。 最近サポートを追加した最後のブラウザーはSafari でした 。古いブラウザーの場合はpolyfillを使用できます。

この標準の大きなプラスは、Google、Microsoft、Mozilla、Amazonのサポートで開発されたということです。 複数形と性別の形式、数字の解析などを考慮して、文字列をフォーマットする機能が追加されます。 これがすべて非常にゆっくりと起こっているのは残念です。 たとえば、標準自体は2013年に承認され、最も人気のあるブラウザーによるサポートは2016年にのみ実現されました。その間、Intlオブジェクトの機能はかなり制限され、翻訳する機能は提供されません。 したがって、サードパーティのソリューションを使用するか、まだ承認されていない形式のポリフィルを使用する必要があります。

長所：

• ブラウザでのネイティブ実装。
• 高性能;
• 追加のリソースをダウンロードする必要はありません。
• JavaScriptリソースをロードせずに異なるロケールで文字列をフォーマットします。
• ECMAScript 2017国際化API標準の開発。

短所：

• レガシーブラウザには、ポリフィルのダウンロードが必要です。
• システム依存。 一部のロケールはクライアントでサポートされていない場合があります。
• ブラウザによって結果が異なる場合があります。

ECMAScript国際化APIの例

 var mFormat = new Intl.NumberFormat("ru", { style: "currency", currency: "GBP" }).format(1234567.93); console.log(mFormat); // 1 234 567,93 £ var nFormat = new Intl.NumberFormat('ru-RU').format(1000.15); console.log(nFormat); // "1 000,15" var utc = new Intl.DateTimeFormat("en-US", { timeZone: "utc", hour: "numeric", minute: "numeric" }); console.log(utc.format(new Date())); // 2:38 PM 

ここにもう少し例があります 。

ご覧のとおり、標準にはまだ多くのものが実装されておらず、Webアプリケーション開発者が直面するすべての機能が考慮されているわけではありません。 したがって、上で書いたように、多くは既製のソリューションを探すか、独自のソリューションを開発する必要があります。 現時点では、多くの解決策があり、それぞれに長所と短所があります。 Googleに目を向けると、検索で最初の結果はi18next 、 FormatJS 、 Globalize 、 jQuery.i18nなどになります。 これらのライブラリの中には独自のソリューションを提供するものもあれば、ECMA-402標準に準拠しようとするものもあります。 たとえば、Google検索で最初の結果を提供する2つのライブラリを取り上げ、それらの機能を確認してください。

i18next

開発者によると、これはクライアントとサーバー（node.js）の両方で国際化を行うための非常に人気のあるライブラリです。 彼女にとって、多くのプラグイン、ユーティリティがあり、異なるフレームワークと統合します。 翻訳ファイルをアップロードできる翻訳者向けのインターフェースを提供しますが、残念ながら既に支払われています。 本当に多くのものが実装されており、ライブラリは成長し続けていますが、もちろん良いことです。 ただし、ECMA-402仕様には準拠しておらず、メッセージの構造形式はICUメッセージ構文ではなく独自のものです。 さらに、数値と日付をフォーマットするには、 moment.jsまたはnumbers.jsをロードする必要があります。 したがって、これらのライブラリをプロジェクトにロードし、必要な言語のロケールをライブラリに追加する必要があります。

長所：

• 言語の多くの機能のサポート。
• バックエンドからリソースをダウンロードする機能。
• 追加のプラグインとさまざまなユーティリティ。
• 人気のあるフレームワーク、テンプレートエンジンの拡張機能。

短所：

• リソースのロードが必要です（i18next 35kb +瞬間20kb +必要なロケール）;
• ECMA-402標準に準拠していません。
• 翻訳者向けの有料インターフェース。

ライブラリの操作に関する詳細情報およびその他の例については、 公式Webサイトをご覧ください 。

フォーマットjs

形式JSは、国際化のためのJavaScriptライブラリのモジュラーコレクションです。 ECMA-402、ICU、CLDR規格に基づいており、Dust、Ember、Handlebarsなどの多くのフレームワークおよびテンプレートエンジンと統合されています。 このライブラリは、必要に応じて、国際化に対応するためにポリフィルをダウンロードするか、ブラウザの機能を使用します。 さらに、クライアントとサーバーの両方で作業をサポートします。

長所：

• モジュール性;
• ECMA-402またはポリフィルの機能を使用します。
• 人気のあるフレームワーク、テンプレートエンジンの拡張機能。

短所：

• 必要に応じてリソースをロードする必要があります。
• すべての翻訳の機会ではありません。

たとえば、ICU形式の翻訳用テキストは次のようになります。

 { gender, select, female {{ count, plural, =0 {   } one {  # } few {  # } other {  # } }} other {{ count, plural, =0 {   } one {  # } few {  # } other {  # } }} } 

このリンクで作業を確認できます。 上記の例を使用して、ロケール「ru」を入力します。 このフォーマットは一見複雑ですが、言語の多くの機能を考慮に入れることができます。 同様のフォーマットで動作する翻訳者にとって便利なシステムにまだ出会っていないのは私だけです。

ご覧のとおり、多くのソリューションがありますが、選択する必要があるだけです。 しかし、ローカライズのプロセスは、ローカリゼーション用のシステムを選択し、言語のさまざまな機能に対処しようとするだけでは終わりません。 翻訳システムは開発プロセスに密接に統合する必要があり、開発者と翻訳者の両方にとって単一のインフラストラクチャを表し、次のようないくつかの重要な質問に答える必要があります。

• 翻訳プロセスはどのようになりますか？
• 翻訳ファイルはどのようにして翻訳者に届き、システムに戻るのですか？
• 特定のテキストがある翻訳者を知るにはどうすればよいですか？

そして、これらの質問に対する答えがある場合にのみ、仕事に便利な統合されたローカリゼーションシステムがあると言えます。

Badooが国際市場に参入したとき、これらすべての質問と言語機能に注意を払わなければなりませんでした。 すでに遠い時代には、ローカリゼーションのための同様のシステムが存在しても、それらはすべての要件を満たしていませんでした。もちろん、ローカリゼーションのための独自のシステムを開発する必要がありました（ Habré多言語アプリケーション）。 このシステムは、プロセス全体にうまく統合され、透過的であり、開発プロセスを遅らせないようにする必要があります（たとえば、1日に2回「リリース」されるため、新製品のアイデアが実稼働環境ですぐに見つかることが非常に重要です）。 さらに、彼女はWebだけでなく、iOS、Android、Windows Phoneなど、他のすべてのプラットフォームとも連携でき、メールニュースレターにも使用できる必要がありました。

クライアントとサーバー間の共通の通信形式（以下、プロトコルと呼びます）、または「認証」と呼ばれるようになったため、多くのテキストがサーバーから送信され始めました。 クライアントに大量の転送を保存する必要がないため、このアプローチは私たちにとって便利でした。このアプローチのおかげで、たとえば、トークンのABテストを実行したり、ユーザーのアクションに依存するトークンを作成したりできます。 各クライアントは、必要な翻訳を自宅に保存することもできます。 翻訳を保存する場所（クライアントまたはサーバー）は、プロトコルの開発を担当するチームが決定します。 一部の翻訳が更新された場合、各クライアントは新しい翻訳をリクエストできます（翻訳は頻繁に更新され、新しいリリースは特定の頻度でアプリケーションストアに表示されるため）。 このメカニズムをホットレクセムアップデートと呼びます。

上の図からわかるように、ローカライズプロセスでは、クライアントの開発者や翻訳者だけでなく、他の多くのチームとも忙しくしています。 たとえば、上で書いたように、MAPIチームはプロトコルを設計し、翻訳を保存する場所を決定します。 BackOfficeチームは、翻訳者、翻訳者、そしてもちろん翻訳を行うための便利なインターフェースを提供し、SRV（サーバー開発者）またはフロントエンド（クライアント開発者）チームが目的の翻訳を生成して表示します。 さらに、このようなシステムを作成したとき、それに基づいて、ユーザーが参加できる共同翻訳システム（ https://translate.badoo.com/ ）を作成できました。 そして、それらは各国の現地の特徴を考慮して翻訳を行うのに本当に役立ちます。

おわりに

開発者や翻訳者だけでなく、プロジェクトのさまざまなチームに影響を与えるため、アプリケーションのローカライズプロセスは非常に深刻で骨の折れる作業であることは明らかです。 そして、この記事の最後で、アプリケーションをローカライズするときの主要な瞬間にもう一度注意を向けたいと思います。

1. ローカリゼーションは、「上に」実装するためのかなり複雑な手順です。 必要な場合は、プロジェクトの最初から作成する必要があります。
2. ローカリゼーションリソースはアプリケーションに依存しない必要があります。
3. ローカリゼーションは行だけでなく、設計時にも考慮される必要があります。
4. 開発者だけでなく翻訳者にとってもシステムを便利にして、翻訳プロセスを自動化します。
5. 翻訳の品質がわからない場合は、テキストをまったく翻訳しないことをお勧めします。
6. 各国と言語の文化的特徴を考慮に入れるようにしてください。
7. デザイン、レイアウト、色、使用済み画像はローカライズの対象にする必要があります。

おそらく私はこのトピックに関するすべてを持っています。 ローカリゼーションプロセスの新しい微妙さをご自身で学んでいただければ幸いです。 あなた自身の興味深い経験がある場合は、コメントとコメントでそれを共有してください。 ウェブを再びすばらしいものにしましょう！

Vyacheslav Volkov、フロントエンド開発者、Badoo