ソフトウェアのローカリゼーションとは何ですか？

ソフトウェアのローカリゼーションには次のようなステップが含まれます:

• 翻訳用のコードを準備しています
• ソフトウェア文字列のエクスポート
• 解析戦略とセグメンテーション戦略の微調整
• 重要な用語リスト（用語集）を作成する
• ソフトウェア翻訳プロジェクトを作成します
• 翻訳者の割り当て
• レビュー担当者への割り当て
• クエリ管理
• 自動QAチェック
• 翻訳された文字列を再インポートしています
• QAは、ステージング環境またはスクリーンショットのいずれかでチェックします
• テスト

この記事では、これらのさまざまなコンポーネントと、全体的なローカライゼーションプロセスへの影響について説明します。

翻訳用のコードの準備

一部のソフトウェア は翻訳を念頭に置いてコーディングされていますが、ソフトウェアがすでに成熟しているときに翻訳が必要になることがよくあります。 翻訳のためにコードを準備するには、変数、日付、および翻訳可能なコンテンツとコードの全体的なアーキテクチャに注意を払う必要があります。 日付、通貨、その他の要因は、地域によって形式が異なります。 それらがハードコードされている場合は、異文化間の柔軟性を可能にするために、動的なエンティティとして再コード化する必要があります。 コードの記述方法によっては、翻訳可能なテキストからコードを分離するのは非常に簡単な場合もあれば、難しい場合もあります。 これは文字列のエクスポートの次のステップに影響を与えますが、ソフトウェアのローカリゼーションの最も見落とされがちで過小評価されている側面かもしれません。 コードとテキストのシンプルさの違いによる一つ一つの波紋が、ローカライゼーションプロセス全体に影響を与える無数の波を引き起こします。 コードの整合性を保つか、翻訳者にとって使いやすくするかのどちらかが難しいシナリオを引き起こす可能性があります。 もちろん、これらの課題の一部は解析やセグメンテーション戦略を通じて克服できますが、コードが干渉しない形で翻訳可能なコンテンツをよりクリーンにエクスポートできればできるほど、あなたのソフトウェアのローカリゼーションプロセスはより良く（より持続可能でスケーラブルに）なります。

ソフトウェア文字列のエクスポート

文字列のエクスポートは簡単なプロセスであるべきです。 しかし、そうではありません。 特定の形式は頼りになりますが、他の形式は避けるべきです。 頼りになるフォーマットの例: XML、YAML、JSON。 構造化されており、予測可能で、簡単に解析でき、コード内でパターンを見つけるのが比較的容易であり、異なる言語への翻訳に伴う問題を減らします。 避けるべき形式の例: TXT、CSV、混合コード。 たとえば、CSVエクスポートは悪夢になる可能性があります。 セミコロンのような区切り文字は、言語学的なツールとして必要です。 アルゴリズム的に、コードの区切りとして意図されたセミコロンと、翻訳者のツールとして意図されたセミコロンを区別するのは事実上不可能です。 これは、品質保証プロセス中に確認が必要な数百の誤検知や、コードの再インポート時の問題を作成します。 XML内にJSONが含まれているような混合コードを例として挙げると、それは解析とセグメンテーションのプロセスの複雑さを追加する例です。 エンコーディングも重要な痛点です:

• HTML エンコーディング
• URLエンコーディング
• Unicode エンコーディング
• Base64エンコーディング
• ヘックスエンコーディング
• ASCIIエンコーディング

これらのエンコーディングフレームワークはそれぞれ、包含される言語による文字の非互換性など、ローカライゼーションプロセスに影響を及ぼします。

解析とセグメンテーションの戦略の微調整

上記のベストプラクティスに従った場合、解析とセグメンテーションの戦略はプロセスオプティマイザーになります。 まだの場合、解析とセグメンテーションがプロセスイネーブラーになります。 プロセスの最適化を行う者として、細かく調整されたセグメンテーション戦略は、翻訳者やレビュアーにとって親しみやすい方法でコンテンツがあなたの翻訳管理システムに取り込まれることを保証します。 ここで、変数が保護され、残りのコードが保護され、テキストが翻訳プロセスにとって意味のある方法で分割されることを確認できます。宿題をしていない場合、これは物事がおかしくなる可能性のあるステップです。 コードや変数を保護するための解析を十分に作成することが不可能であるか、またはソフトウェアのコンテンツをより翻訳しやすくするために、十分な正規表現を書くのに非常に多くの努力が必要であるためです。 いずれにせよ、これは極めて重要なステップです。 解析とセグメンテーションの戦略を時間とともに変更すると、翻訳メモリの活用が失われ、追加のコストとプロセスの複雑さを作成することになります。 それがあなたの顔に爆発するまでは大したことではないように思えるかもしれません。 例えば、あなたの全体のソフトウェアが100,000ワードあり、10のlanguagesに翻訳していて、1ワードあたりの平均コストが$0.15であると仮定しましょう。 ソフトウェアを翻訳したと仮定しましょう。しかし、解析戦略を繰り返すと、10%の活用損失が発生します（これは解析の小さな変更の予想される結果です）。その結果、最初から$15,000が失われ、さらに必要な時間や他の影響も考慮しなければなりません。

重要な用語リスト（用語集）を作成する

誰でも用語集を作成できます。 素晴らしいものを開発できる人はほとんどいません。 一部の人々は統計的な方法を取り、最も頻繁に出現するキーワードを探すためにコンテンツデータベースを利用します。 その方法は物事を迅速に進め、頻度に基づいて重要な用語を捉える一方で、いくつかの重要な用語は必ずしも頻繁に使用されるわけではありません。ある人々は質的アプローチを取り、翻訳者が大量のコンテンツを調べて手動で関連する用語を特定します。 他の人々はAIを使用して言語パターンを探し、頻度だけでなく全体的な意味の関連性に基づいてエンティティや用語を特定します。アプローチに関係なく、用語集に関しては、少ない方がより良いです。 重要な用語を確実に捉えたいと思う一方で、あまりにも多くの用語を用語集の用語として指定すると、適切な適用を管理することはほぼ不可能になります。 誤検知やアラートが多すぎると、翻訳者やレビュアーが用語の提案を管理し、自動QAチェッカーを実行するのが難しくなります。 用語集に関するもう1つのヒントは、特定の種類の翻訳が必要な用語と同様に、翻訳すべきでない用語にフラグを立てることが重要であるということです。

ソフトウェア翻訳プロジェクトを作成する

このステップは、使用している翻訳管理システムのフレームワークに大きく依存します。 一部のシステムでは、同じ環境とプロジェクト内でプロジェクトの全体のライフサイクルを管理することができますが、他のplatformsでは、文字列またはファイルベースの異なるアプローチが必要になることがあります。 実際の翻訳プロジェクトを設定することは形式的なものに見えるかもしれませんが、重要なチェックポイントがあります。例えば:

• ファイルが完全に取り込まれたことを確認します
• 言語ペアがロケールレベルまで正しいことを確認する
• 日付が正しいことを確認する
• ワークフローのステップが必要なものであることを確認する
• 翻訳者への割り当て

このステップでは、言語ペアごとに事前に審査された翻訳者のチームがすでに利用可能であると仮定しています。 重要なことは、以下のような翻訳者と協力することです:

翻訳者と同様に、重要な識別力に重点を置いています。 スタイルとエラーの違いを理解するのに十分な批判力を持つレビュアーが必要です。 プロセスのこの段階で変更しすぎるレビュー担当者は、翻訳プロセス全体の整合性を損ないます。 ここでBureau Worksの独自の品質管理フレームワークが役立ちます。

クエリ管理

ソフトウェア翻訳の重要な部分は、翻訳プロセス中に生じる質問に対応できることです。 たとえば、ボタン「X」は何を表しているのか、この変数は何を指しているのか? プロジェクトの翻訳者全員が言語ペアに関係なく、元の言語に関する質問をすることができ、その回答が利用可能であるプロセスを持つことは重要です。同じ質問に何度も答える必要を最小限に抑えるためです。 クエリに新規、割り当て済み、解決済みなどの異なるステータスを割り当てる方法を持つことも重要なですので、プロジェクト管理チームがクエリにタイムリーに対応できるようにすることができます。

自動品質保証チェック

は、あらゆるソフトウェアのローカリゼーションプロセスにとって重要であり、特定の重要な項目がフラグ付けされることを保証します。

• 末尾のスペース
• 文字数制限
• 句読点に一貫性がありません
• 用語集 non-adherence
• スペリング
• 一貫性のないタグ（ソースコードと翻訳済みコードの不一致）
• 翻訳された文字列の再インポート

ここまで生き延びたなら、何かを正しくやっていますね！:) 痛みが少ないかもしれませんが、あなたはここにいます。 次に、文字列をリポジトリに再インポートして、ソフトウェアを再構築します。 前に概説したベストプラクティスのいずれかを見逃したり、管理を誤ったりした場合、コードの中断、タグの不一致、またはコードの再取り込みの成功に影響を与える可能性のあるその他の問題による再インポートプロセスの問題に、この段階で苦労する可能性があります。

自動化されたQAプロセスは、セキュリティを強化し、ローカリゼーションの取り組み中にデータの正確性を確保するために、自動化された本人確認のようなツールと統合することもできます。

ソース: Linkedin

QAは、ステージング環境またはスクリーンショットのいずれかでチェックします

このステップはテストと統合されている場合は無視できますが、翻訳者にステージング環境または主要画面のスクリーンショットへのアクセスを提供することは、文字列が正しく表示され、テストの開始を妨げる重大な問題がないことを確認するのに役立ちます。

テスト

これは、明らかなバグ検出と修正を超えて品質を向上させる段階です。 テストにより、翻訳された文字列をコンテキストでもう一度新しく見ることができます。 翻訳プロセスでは完璧と思われていた翻訳の中には、ユーザーエクスペリエンスの観点からは最適ではないものもあります。 ユーザーエクスペリエンスの向上を目指すことにコミットし、単にバグを事後的に探すだけでないテスターと協力することが重要です。

結論

ソフトウェアのローカリゼーションは広範囲で高価かつ複雑なプロセスです。 しかし、それだけではありません。 反復的で継続的であるため、ソフトウェアが進化し続ける中で、同じプロセスを何度も通過してソフトウェアを更新することになります。 これは、処理が無限に微妙で複雑になる可能性のあるプロセスの高レベルで表面的な概要です。 しかし、重要なポイントは、最初からフレームワークとベストプラクティスに投資することが、すべてのペニーに値するということです。 船が出航すると、それを修理するのは徐々に困難になり、費用がかかります。