すべてのアプリケーションを翻訳する必要があります。 一部の言語は6言語、一部は20言語です。一部は13言語ですが、これはまったく異なる言語のセットであり、前の20言語には含まれていません。
異なる行形式（js、json、ts、yaml、yml）の結果として、誰もが異なるスタックを持っています。 また、テキストをデータベースに保持している人もいます。
あなたはアジャイルに取り組んでいます：毎日の価値提供、2週間のスプリント。 DoRには、必要なすべての翻訳が含まれます。 もちろん、昨日はテストするために翻訳が必要でした。
テクニカルライターの部署があります。 テクニカルライターは誰ですか？ これは、外部ドキュメントを作成する人であり、内部ドキュメントも作成します。 ユーザーまたはパートナーが表示できるすべての種類のテキストを書き込みます：フロントエンドテキスト、メッセージテキスト、API応答、エラー。 開発プロセスに付随して、テクノロジーとビジネスロジックに没頭します。 アプリケーションへの翻訳のタイムリーな配信を提供します。
コピーライター翻訳者およびローカリゼーションマネージャーの役職もあります。 これは、すべてのテキストを英語で作成し、翻訳の一貫性を監視し、翻訳者を任命し、関連するすべての問題を解決する人です。
重要なのは、開発を妨げず、技術部門全体を傷つけないために、いくつの技術仕様、コピーライター、ローカリゼーションマネージャーが必要なのかということです。
私たちの場合、4つの技術証明書と1つのローカリゼーションコピーライターマネージャーで管理しました。 転送の配送は平均して1営業日以内で、3営業日を超えることはありません。 面白いと思います。
どうやってこれに来たの？
6年前、GoogleシートとDBで働いていました。 つまり、開発プロセス中に翻訳用の行が表示された場合、それらをプレートにコピーしてから、メールで翻訳に送信しました。 翻訳の準備ができたら、手動でデータベースに流し込みました。 このソリューションの唯一の利点は、新しい行を表示するためにアプリケーションを再配置する必要がないことです。 ただし、翻訳にエラーがある場合、ロールバックすることはできません。 翻訳メモリも用語集もありません。 翻訳の一貫性は注視法によって達成されます。
最初の試み
このプロセスを自動化する最初のバージョンは次のようになりました。開発者が行を作成したら、翻訳用の特別なリポジトリの新しいブランチに追加しました。 次に、同じブランチでパイプラインが起動され、APIによってすべてのdiff行が翻訳のために送信されました。 確かに、翻訳はすでにデータベースに戻るはずでしたが、APIを介して外部リソースから内部データベースに行をロードできませんでした。
そのような統合は何をもたらしましたか？ テクニカルライターがすべてを1つのテーブルに収集し、手動で送信し、受信した翻訳をアプリケーションおよび言語の数で分割する必要があるステップが削除されました。 この場合、行は、目的のアプリケーションと同じ名前のプロジェクトの一部としてすぐに翻訳のために送信されました。 その結果、テクニカルライターは、作業が実行された各アプリケーションのアーカイブセットを受け取りました。 これにより、手作業の割合が大幅に削減されました。 さらに、翻訳メモリはプロバイダー側に実装されました。 しかし、このソリューションにはいくつかの欠点もありました。データベースに行を格納すると、私たちの側では本格的な行管理ができず、以前のように、手作業の大部分を意味しました。
痛みと継続的なローカリゼーション
次の統合は、開発者に多くの苦痛をもたらしました。 私は、それを捕まえた人々が「ローカライゼーション」という言葉にまだ目をそらしているように思えます。 これは、SergeおよびSmartcatとの最初の統合でした。
ここでは、SergeとSmartcatが何であるかを伝えることが重要です。
Sergeはgitをサポートするユーティリティです。 彼女は、ブランチから必要な行を取得し、それらを翻訳のために送信し、これらの行の翻訳のみを同じブランチに返すことができます。 また、翻訳するCATシステムのAPIを呼び出すプラグインも必要です。 プラグインはSergeから新しい行を受信し、Sergeにすぐに翻訳を返す必要があります。
Smartcatは、用語集、翻訳メモリ、プレースホルダーをサポートするCATシステムです。 また、Smartcatはフリーランサーとの相互決済のプロセスを集約および簡素化し、翻訳ベンダーの接続をサポートします。
このステップでは、データベースからプロジェクトリポジトリに行を転送しました。 ここで、行をアプリケーションリポジトリから直接送信して、そこに戻す必要がありました。
開発者はどのブランチから機能ブランチを作成したかを知っており、これら2つのブランチ間のリソースファイルの差分はまさに翻訳する必要があるものです。 開発者が翻訳用の一連の行を作成すると、Serge構成を使用してブランチでジョブを開始します。 Sergeはdiffを計算し、新しい行を抽出し、プラグインを呼び出して、翻訳のために行を送信します。 翻訳の準備ができたら、開発者は次のジョブを呼び出します。前のステップで作成したSergeインスタンスをデプロイし、完成した翻訳を受け取り、元のブランチにコミットします。
ソリューションは不安定であることが判明しました：Sergeはパイプラインが起動されるたびにゼロからデプロイすることを意図していなかったため、開発者はブランチ間の差分について考えることを望まず、Smartcatプラグインは更新と改善を緊急に必要としていました。 新しいラインを提供するプロセスには数時間かかる場合があります。 そして、悲しいかな、それは常に成功したわけではありません。
理論的には、プロセスのすべての段階は自動化されており、実際、メンテナンス、パイプラインを開始する前の差分の計算、およびトラブルシューティングは同じタスクを完全に手動で行うよりも時間がかかりました。
トンネルの終わりの光
2018年8月までに、最新バージョンの統合を開始しました。 ローカリゼーションサーバーがあります。 各リポジトリのサーバーには、Sergeの個別のインスタンスがあります。 Sergeはリポジトリ内のすべてのブランチをスキャンし、翻訳のために新しい行を送信し、完成した翻訳を元のブランチにコミットします。 現在の統合では、すべてが高速で安定しています。 翻訳用のブランチを作成した後、行は5〜6分以内にSmartcatで終了します。 転送を確認した後、同じ5〜6分以内に同じ方法でコミットが行われます。 翻訳の配信時間は、翻訳者の作業負荷、タイムゾーンの違いなどのヒューマンファクターによってのみ制限されます。
次の記事では、Serge-Smartcat-Gitlab統合をゼロから設定する方法と、さまざまな非標準タスクをどのように解決したかを説明します。
継続：
昨日20のプロジェクト、20の言語、締め切り。 パート2
昨日20のプロジェクト、20の言語、締め切り。 パート3