ソースデータ
1つの会社の枠組み内で、ロシア語のコンテンツとイデオロギー的に接続されたいくつかのWebサービスが存続し、開発されています。 ある時点で、彼らは国際化の美しいが厄介な道に足を踏み入れる運命にありました。 さらに、サポートされる言語のリストは、うらやましいほど拡大する予定でした。
次の段階を経る必要がありました。
- 国際化のためのプロジェクトの準備;
- テキスト翻訳プロセスの開発のワークフローへの統合。
- 翻訳サービスを使用するためのツールの選択と構成。
- 開発者と翻訳者間の相互作用を確立します。
このタスクの一部として発生した問題と解決策について説明します（また、ダンスノームについても少し）。
最初のステップ
彼は一番難しいです。 時期尚早な最適化のサポーターではない（また、このための時間もありません）ため、単純な「打たれた」道を進むことにしました。
私たちの武器には何がありますか？ プロジェクトは、組み込みの国際化メカニズムを備えたPHP Yiiフレームワークに基づいて実装されています。 まあ、素晴らしい、それを使わないのは愚かなことだ。
始めましょう。各プロジェクトには「言語」ディレクトリがあり、最初はソースと最愛のRUだけがありました。 次に、テンプレート、エラーメッセージ、およびその他の国際化されたコンテンツのすべてのテキストが、Key-Value形式の辞書の形式でそこに移動されました。 ここで最初のキャプテンの教訓を学びました 。 事前にプロジェクトを内部化することを考えてください 。 今日、別の言語をサポートする必要がない場合、明日表示される可能性があります。 最初のステップは最も難しいことではありません。
サービスには共通のイデオロギー的基盤があるため、さまざまなプロジェクトの辞書に散在する多数の重複キーにすぐに遭遇しました。 論理的な解決策は、重複を削除し、すべてのプロジェクトの共通辞書を「共有」することです。 これにより、既存の翻訳を変更するコストが削減され、このグループの新しいプロジェクトの開発にも貢献します。
その結果、一般的な辞書がフレームワークレベルに配置され、次のスキームに到達しました。
ふふ。 私たちのプロジェクトは「翻訳」する準備ができているようです。 何が起こるか見てみましょう。
国際化する
ああ、私たちには独自の翻訳チームがいることを忘れていました。 確かに、彼らはWebサービスの開発と対話する前に、彼らのタスク、ツール、プロセスに従事していました。 しかし、外部の請負業者と仕事をすることは私たちの生活をさらに複雑にするため、それでもすばらしいことでした。
最初は、ブラックボックスモードで翻訳者と協力しました。 開発者は辞書をアーカイブに詰め（すべてのプロジェクトから収集した後）、翻訳者に手紙で送り、期限の予備的な予測を受け取って、翻訳された辞書の同様のアーカイブを待ちました。
そして今、私たちのサービスが第二言語バージョンを取得したとき、待望の瞬間が来ました。
虹は空で遊び始め、ノームは踊り始めました。 しかし、私は何かについて沈黙していませんでしたか？ 辞書をアーカイブに詰めてからノームのダンスを始めるまでの間、人生は止まらず、最初の警鐘が鳴りました。
まず、翻訳は翻訳ですが、他のタスクもあります。 国際化された各プロジェクトは、多かれ少なかれ積極的に開発されました。 新しい機能が作成され、バグ修正が導入され、多くの場合、これがコンテンツ部分に影響を与えました。新しいテキストが追加され、既存のテキストが編集されました。 最初の完全な翻訳は約3週間続き、この間、開発者リポジトリの辞書は非常に大きな変更を受けました。
ここで、レッスン2を学びました。 開発プロセスと翻訳の同期を検討してください 。 私たちの場合、翻訳用の辞書を小さな部分で送信する方が合理的であるため、数日でそれらを取り戻し、開発者リポジトリに追加できます。 現時点では、これらの辞書に影響するすべての作業を凍結する必要があります。 これにより、2つのバージョンの辞書を手作業で組み合わせて、未翻訳または編集済みのキーを強調表示し、翻訳のために再送信する必要がなくなります。
次の注目すべき問題は、恐ろしい規則性で繰り返される翻訳者による同様の質問でした：「あなたは「口座を開設できません」というフレーズを持っています」。 金融口座ですか、それともスポーツ口座ですか？」 はい、サッカーシミュレーターはありませんが、翻訳者が事前に対象地域にアクセスできることを確認する必要がありました。 したがって、3番目のレッスン： 高品質の翻訳はコンテキストなしでは不可能です。
少し遅れて、翻訳チームにテストスタンドへのアクセスを許可し、正しい翻訳に重要なユーザーストーリーを再生する機会を与えました。 これに加えて、すでに接続されている新しい言語バージョンのサービスの最終レビューが実施されました。
待望のリリース後、サービスの新しい「国際的」ステータスを考慮して、使い慣れた開発プロセスの変更について考える時間です。
翻訳の難しさ
機能を作りました-翻訳してください！ これが私たちのチームの人生に新しい時代を与えるモットーです。 正確な翻訳方法の問題は、開発者の肩にかかっています。 場合によっては、言語の知識を誇示して、「Hello、{userName}！」のようなものを辞書に追加することもできます。 しかし、ほとんどの場合、翻訳者は何度も引き抜かなければなりませんでした。
これにより、手作業の量、機能の開発時間、そしてもちろんテスト時間が増加しました。 多くの場合、サービスの腸に隠された不注意に追加された翻訳がすでに事実上発見され、チームが翻訳の編集のみを含む完全なリリースサイクルを強制することから始まる場合がしばしばありました。
この問題についての激しい議論の結果、すべてのプロジェクトから別のライブラリに辞書が削除されました。
これにより、機能部分に影響を与えることなく、「コンテンツ」リリースを個別に実施できました。 さらに、翻訳の作業に伴うノイズがプロジェクトリポジトリから排除されました。 もちろん、そのような変更は無料ではありませんでした。 フレームワークレベルでの国際化のモジュールが拡張され、ビルドサーバーのビルドおよび構成システムが改善されました。 しかし、結果として、これらの手順は正当であると考えました。
別の言語バージョンの出現を見越して、開発者と翻訳者間の相互作用のプロトコルは合理的な懸念を引き起こしました。
次の問題が翻訳者によって表明されました。
- 着信転送用の統一フォーマットの欠如。 開発者は辞書、辞書の断片、文、さらには単語を送りました。
- このスキームでは効果的ではなく、独自の言語ツールの使用。
- レビュー、ディスカッション、変更履歴の表示のための翻訳がある現在のリポジトリへのアクセスの欠如。
開発者は、主に多数の手動操作、および送信された辞書が構文およびフォーマット規則に準拠しているかどうかをチェックする必要性について不満を述べました。
翻訳を処理するための集中サービスが必要でしたが、検索を開始しました。
自動化する
最初のステップは、ドリームサービスが満たす必要がある要件のリストをまとめることでした。
- 開発者、翻訳者、その他の利害関係者のアクセシビリティ。
- アカウント、グループ、プロジェクト内の権利を区別する機能。
- 必要な辞書形式のサポート。
- 完全な外部API。
- 翻訳の追加機能：
- 未翻訳キーのフィルタリング。
- 翻訳履歴の追跡。
- 特定のケースについて議論する機会。
- 重複および類似のフレーズを検索します。
- 柔軟な通知モデル：
- 翻訳者向け-新しいキーの外観と既存のキーの編集について。
- 開発者向け-翻訳の状況と翻訳者に生じた質問について。
- てんかん発作を引き起こさない健全なインターフェース。
独自のサービスの開発とサポートに費やさなければならない時間とリソースの迅速な評価により、ターンキーソリューションによる検索の方向性が制限されました。
そのようなサービスの可用性だけでなく、その機能の多様性にも嬉しい驚きがありました。 この市場セグメントのレビューは、別の記事の良いトピックになるので、スクロールして、この記事が私たちに最も適しているとしか言えません。 4番目のレッスンにのみ注意する必要があります。 外部国際化サービスを選択するときは、最初にテストプロジェクトで確認してください 。 開発者と翻訳者からフィードバックを収集し、サービスの信頼性、サポートのレベル、および使用コストを評価することによってのみ、意味のある決定を下すことができますが、後悔する必要はありません。
新しいサービスを紹介する頃には、開発チームはすでにそのAPIを実装しており、翻訳を使用してリポジトリのカスタマイズされたミラーを作成していました。
もちろん、プライマリは辞書を備えた独自のリポジトリであり、外部サービスでは「ウェブフェイス」のみになりました。 ある不幸な日に空中に溶けてしまうと、もちろん動揺しますが、開発プロセスを妨げることなく、すぐに古いスキームにロールバックします。
国際化に関する作業規則は、次の形式を取りました。
- 新しいテキストが登場しました。
- 開発者はそれらを「メイン」言語（この場合はロシア語）の辞書に追加します。
- 開発者はAPIを使用して、辞書を翻訳サービスに送信します。
- 翻訳者は、翻訳されていないテキストの出現の通知を受け取り、翻訳します。
- 開発者は翻訳の到着に関する通知を受け取り、再びAPIを使用して、辞書を同期し、リポジトリを更新します。
- 既存のテキストが変更されました：
- 状況をアイテム1に移行しようとしています。 辞書の既存のキーを編集せずに、新しいキーを追加して使用します。
- 前のオプションが適合しない場合、開発者は「メイン」言語の辞書キーを直接変更し、それらを翻訳サービスに送信します。
- スマートサービスは、既存のキーのテキストが変更されたことを理解し、他の言語で繰り返し翻訳が必要なものとしてマークします。
- 翻訳者は、古い翻訳を残して（たとえば、文法エラーが単に修正された場合）、新しい翻訳を指定することができます。
- 開発者は通知を受け取り、辞書を同期します。
- 変換エラーが検出されました：
- 誰でも（これは開発者である可能性があります）を検出した人は、独立して、または翻訳者の助けを借りて、翻訳サービスで編集します。
- 辞書の次の同期で、この変更はリポジトリに反映されます（必要な場合、開発者への直接の訴えによって同期が強制されます）。
- 新しい言語のサポートが追加されました。
- 新しい言語が翻訳サービスに追加されます。 彼の辞書はすべて、最初は未翻訳としてマークされていました。
- この言語を話す翻訳者のスタッフのスタッフの空き状況に応じて、翻訳は単独で、またはサービスへのアクセスを制限してサードパーティの翻訳者を引き付けることにより行われます。
- 翻訳が完了した後、開発者はプロジェクト構成を変更し、辞書を同期するときに新しい言語がリポジトリに追加され、さらに一般的なプロセスに参加するようにします。
これらのシンプルなルールは私たちの生活を少し良くし、また国際化という言葉に言及する神経質なカチカチを部分的に排除しました。 手動操作の数を大幅に削減し、チームインタラクションのプロトコルを合理化し、機能開発の国際化のオーバーヘッドを削減し、人的要因に関連するエラーのほとんどを排除しました。
5番目の最後のレッスン： ほとんどの技術プロセスと同様に、国際化プロセスは自動化できます 。 自動化の程度は、特定の状況とプロジェクトのニーズに基づいて決定する必要があります。
まとめ
スクロールした人と最後まで読んだ人のために、彼らは最初に議論されたことを忘れていました。
- プロジェクトを事前に内部化することを検討してください。
- 開発プロセスと翻訳プロセスの同期を検討してください。
- コンテキストなしでは高品質の翻訳は不可能です。
- 外部の国際化サービスを選択するときは、まずテストプロジェクトでそれを確認します。
- ほとんどの技術プロセスと同様に、国際化プロセスは自動化できます。
この記事以外にも、Webサービスの国際化の興味深い側面が残っています-多言語主義の世界でのテストの自動化。 しかし、その別の時間についての詳細。
私が説明した経験が将来の国際主義者に役立つことを願っています。
ありがとう