コンピューティングにおいて、国際化とローカリゼーション(アメリカ)または国際化とローカリゼーション(イギリス連邦)は、それぞれi18nとl10nと略されることが多く、対象となる地域の異なる言語、地域特性、および技術的要件に適応するための手段です。
国際化とは、ソフトウェアアプリケーションを設計する際に、技術的な変更を加えることなく、様々な言語や地域に対応できるようにするプロセスです。ローカライゼーションとは、国際化されたソフトウェアを特定の地域や言語に合わせて、テキストを翻訳したり、地域固有のコンポーネントを追加したりすることで、適応させるプロセスです。
ローカリゼーション(異なる地域向けに複数回実行される可能性がある)は、国際化(理想的にはローカリゼーションの前に一度だけ実行されるか、進行中の開発の不可欠な部分として実行される)によって提供されるインフラストラクチャまたは柔軟性を利用します。[ 1 ]
これらの用語は、単語の 長さから、しばしばi18n (ここで18 はinternationalization という単語の最初のiと最後のnの間の文字数を表し、1970 年代または 1980 年代にDigital Equipment Corporationで考案された用法) [ 2 ] [ 3 ]およびlocalizationのl10nという略語で表されます。[ 4 ] [ 5 ]一部の著者は、両者を区別するために後者の用語を大文字 ( L10n ) で表記しています。 [ 6 ]
IBMやOracleなどの一部の企業は、国際化とローカリゼーションを組み合わせたものをグローバリゼーション(g11n)と呼んでいます。[ 7 ]
Microsoft は国際化を世界対応とローカライズの組み合わせと定義しています。世界対応とは、製品を複数のスクリプトと文化で使用できるようにし (グローバル化)、ユーザー インターフェイス リソースをローカライズ可能な形式に分離する (ローカライズ性、略称L12y ) 開発者のタスクです。[ 8 ] [ 9 ]
ヒューレット・パッカードとHP-UXは、ローカライズ可能なソフトウェアを作成するために、「National Language Support」または「Native Language Support」(NLS)と呼ばれるシステムを作成しました。[ 10 ]
IBM [ 11 ]を含む一部のベンダーは、特定のロケールのみをサポートするソフトウェア製品のローカライズ版に対して、 National Language Version (NLV)という用語を使用しています。この用語は、異なる市場向けに同様の NLV バージョンが存在することを示唆しています。この用語は、国際化とローカライズが行われておらず、ソフトウェア製品がどのバージョンでも 1 つの言語とロケールのみをサポートしている場合は使用されません。

『Software without frontiers』によると、製品を国際化する際に考慮すべき設計上の側面は「データエンコーディング、データとドキュメント、ソフトウェア構築、ハードウェアデバイスのサポート、およびユーザーインタラクション」であり、完全に国際化された製品をゼロから作成する際に考慮すべき主要な設計領域は「ユーザーインタラクション、アルゴリズム設計とデータ形式、ソフトウェアサービス、およびドキュメント」である。[ 10 ]
翻訳は通常、言語ローカライゼーションの中で最も時間のかかる要素である。[ 10 ]これには以下が含まれる可能性がある。
コンピュータソフトウェアは、単語やフレーズの単純な翻訳を超えた差異に遭遇することがあります。これは、コンピュータプログラムがコンテンツを動的に生成できるためです。これらの差異は、翻訳の準備段階で国際化プロセスにおいて考慮する必要がある場合があります。これらの差異の多くは非常に規則的であるため、言語間の変換は容易に自動化できます。Unicodeの共通ロケールデータリポジトリは、このような差異のコレクションを提供します。そのデータは、Microsoft Windows、macOS、Debianなどの主要なオペレーティングシステム、およびGoogleやWikimedia Foundationなどの主要なインターネット企業やプロジェクトで使用されています。このような差異の例としては、次のものがあります。
国によって経済慣習は異なり、以下のような違いが見られる。
特に、米国と欧州はこれらの事例のほとんどにおいて異なっている。その他の地域は、多くの場合、これらのいずれかに倣っている。
オンライン地図、天気予報、決済サービスプロバイダーなどの特定のサードパーティサービスは、同じ通信事業者から世界中で利用できるとは限らず、そもそも利用できない場合もあります。
世界各地でタイムゾーンは異なるため、製品が元々単一のタイムゾーンのユーザーのみを対象としていた場合は、この点を考慮する必要があります。国際化においては、多くの場合、内部的にUTCを使用し、表示目的で現地のタイムゾーンに変換します。
国によって法律上の要件は異なり、例えば以下のようなことが言えます。
ローカライゼーションでは、以下のような文化的な違いも考慮に入れる必要がある。
製品を国際化するには、製品が将来参入すると予想されるさまざまな市場を検討することが重要です。[ 10 ]番地のフィールドの長さ、住所の固有の形式、郵便番号のない国への住所のために郵便番号フィールドをオプションにする機能、州のない国への州フィールド、さらに現地の法律に準拠した新しい登録フローの導入など、国際化を複雑なプロジェクトにする詳細のほんの一例です。[ 6 ] [ 17 ]より広範なアプローチでは、たとえばビジネス プロセスのロジックの適応や個々の文化的 (行動的) 側面の組み込みに関して、文化的要因を考慮に入れます。[ 10 ] [ 18 ]
1990年代にはすでに、Bullなどの企業は翻訳活動のすべてにおいて機械翻訳(Systran)を大規模に使用しており、人間の翻訳者は事前編集(入力を機械が読み取れるようにする)と事後編集を担当していた。[ 10 ]
既存のソフトウェアを再設計する場合でも、新しい国際化ソフトウェアを設計する場合でも、国際化の最初のステップは、潜在的にロケールに依存する部分(コード、テキスト、データなど)をそれぞれ別のモジュールに分割することです。[ 10 ]各モジュールは、標準ライブラリ/依存関係に依存するか、各ロケールに応じて必要に応じて個別に置き換えることができます。
現在主流となっているのは、アプリケーションがテキストをリソースファイルに格納し、必要に応じてプログラム実行中に読み込むという方法です。[ 10 ]リソースファイルに格納されたこれらの文字列は、比較的簡単に翻訳できます。プログラムは、選択されたロケールデータに応じてリソースライブラリを参照するように構築されることがよくあります。
翻訳可能な文字列と翻訳済みの文字列を格納する場所は、文字列がメッセージと呼ばれることから、メッセージカタログ[ 10 ]と呼ばれることがあります。カタログは通常、特定のローカライズ形式のファイルセットと、その形式を処理する標準ライブラリで構成されます。これを支援するソフトウェアライブラリと形式の1つがgettextです。
したがって、アプリケーションが複数の言語をサポートするには、実行時に適切な言語リソースファイルを選択するようにアプリケーションを設計する必要があります。データ入力検証やその他多くのロケールに依存するデータ型を管理するために必要なコードも、異なるロケール要件をサポートする必要があります。最新の開発システムやオペレーティングシステムには、これらのデータ型を国際的にサポートするための高度なライブラリが含まれています(上記の「標準ロケールデータ」も参照)。
ローカライズに関する多くの問題(例えば、書き順やテキストの並べ替えなど)は、テキスト翻訳以上の、ソフトウェアの根本的な変更を必要とします。例えば、OpenOffice.orgはコンパイルスイッチを使ってこれを実現しています。
グローバル化の方法には、計画の後、国際化、ローカライゼーション、品質保証という3つの実施ステップが含まれます。[ 10 ]
ある程度(例えば品質保証のため)、開発チームには、プロセスの基本的/中心的な段階を担当し、他のすべての段階を可能にする担当者が含まれます。[ 10 ]こうした担当者は通常、外国語や外国文化を理解し、ある程度の技術的なバックグラウンドを持っています。複雑な概念に対して文化的に適切な構文を構築するには、専門のテクニカルライターが必要であり、ローカライズ要素を展開およびテストするためのエンジニアリングリソースも必要です。
適切に国際化されると、ソフトウェアはより分散型のローカライズモデルに頼ることができるようになります。フリーソフトウェアやオープンソースソフトウェアは通常、エンドユーザーやボランティアによる自己ローカライズに依存しており、時にはチームを組織しています。[ 19 ]例えば、GNOMEプロジェクトには100以上の言語に対応するボランティア翻訳チームがあります。[ 20 ] MediaWikiは500以上の言語をサポートしており、 2023年9月時点で100言語はほぼ完成しています。 [ 21 ]
既存のテキストを他の言語に翻訳する場合、製品のライフサイクル全体を通してテキストの並行バージョンを維持することは困難です。[ 22 ]例えば、ユーザーに表示されるメッセージが変更された場合、翻訳されたすべてのバージョンを変更する必要があります。
Microsoftなどの独立系ソフトウェアベンダーは、開発者向けにソフトウェアのローカライズに関する参考ガイドラインを提供する場合があります。[ 23 ]ソフトウェアのローカライズ言語は、書き言葉とは異なる場合があります。
商業的な場面では、ローカライズの利点はより多くの市場へのアクセスです。1980年代初頭、Lotus 1-2-3はプログラムコードとテキストを分離するのに2年かかり、ヨーロッパでMicrosoft Multiplanに市場リーダーの座を奪われました。[ 10 ] 1985年までに、Ashton-Tateの年間売上高8,000万ドルの約4分の1は米国以外からのものでした。同社は製品を11のヨーロッパ言語にローカライズしました。MicroProは、西ドイツ市場向けにオーストリアの翻訳者を使用した結果、 WordStarのドキュメントが「本来あるべきトーンになっていない」ことを発見しました。幹部によると、そのトーンは「あるべきもの」ではなかったとのことです。[ 24 ] Tandy CorporationがTRS-80 Model 4の英語のエラーメッセージのフランス語とドイツ語の翻訳を必要としたとき、同社のベルギーのオフィスと米国の5人の翻訳者が、コンピュータコンポーネントの性別に応じて異なる6つの異なるバージョンを作成しました。[ 25 ]
しかしながら、エンジニアリング以外にも相当なコストがかかります。さらに、事業運営においては、複数の個別の地域製品の生産、保管、流通を管理する必要があり、これらの製品は多くの場合、全く異なる通貨、規制環境、税制の下で販売されます。
最後に、販売、マーケティング、テクニカルサポート部門も、ローカライズされた製品の顧客をサポートするために、新しい言語での業務を円滑に進める必要があります。特に言語人口が比較的少ない地域では、ローカライズされた製品を提供することが経済的に成り立たない場合もあります。たとえ言語人口が多く、特定の製品のローカライズが正当化され、製品の内部構造が既にローカライズに対応している場合でも、ソフトウェア開発者やパブリッシャーは、複数の地域での事業運営に伴う付随的な機能を管理するための規模や高度な技術力を備えていない可能性があります。
ローカライズの落とし穴の一例として、Microsoftが一部のキーボードショートカットを現地語でも有効にしようとした試みが挙げられます。その結果、Microsoft Officeのイタリア語版では、一部のプログラム(すべてではありませんが)で、ほぼ普遍的な「保存」機能ではなく、「Ctrl + U」(下線)の代わりに「Ctrl + S」(下線)が使用されるようになりました。「自動保存」機能が登場する以前は、保存されていない文書の改訂版に下線付きの単語が多数含まれてしまうという事態が発生していました。
Microsoft Excelのローカライズを担当するチームは、数値と日付の書式をローカライズする過程で、数式で使用されるトークンも翻訳することにしました。例えば、=SUM(A1:A10)はフランス語では=SOMME(A1:A10)、ドイツ語では=SUMME(A1:A10)となります。
英語の知識がないユーザーにとって数式を理解しやすくする一方で、ウェブページの機械翻訳が普及する以前は、インターネットでヘルプを検索しても他言語の例文は得られなかった。マニュアルやチュートリアルでは、例文や練習問題に出てくるすべての数式を翻訳する必要があった。
簡単に言うと、ローカライゼーションとは、言語とテクノロジーを組み合わせて、文化や言語の壁を越えられる製品を作り出すことです。それ以上でもそれ以下でもありません。
i18n
と
l10n
と書く習慣を身につけ
、各単語の最初と最後の文字を引用し、中間の文字の連続を、そのような文字がいくつあるかを示すだけの数字に置き換えました。
の大文字の L は、i18n の小文字の i と区別するのに役立ちます。