「kubernetes.io」ドキュメントの日本語翻訳に貢献する

はじめに

本連載では、Kubernetes Upstream Training Japanの講師陣が、Kubernetesを例にOSSへのコントリビューションについての実践的な知識を紹介しています。第1回ではOSSとコントリビューションの基本概念や組織的なオープンソース活動について、第2回〜4回ではKubernetesへのコントリビューションの具体的な方法やハンズオン、コードレビューやテストの実践などを扱ってきました。

また、前回の第5回ではkubernetes.ioのドキュメントへの貢献の意義やSIG Docsの活動、Localization sub-projectについて野宮壮大(nasa9084)さんが解説しました。コードを書くコントリビューション以外にもドキュメントの翻訳という重要な貢献の形があり、日本語翻訳チームが活動していることを理解できたと思います。

今回の第6回では、前回の内容を受けて実際に開発環境を構築し、Kubernetesドキュメントへ翻訳のPull Requestを送るまでの流れを解説します。ドキュメントの翻訳は比較的技術的なハードルが低く、かつKubernetesコミュニティへの大きな貢献となる活動です。本記事では環境構築から実際のPR作成、レビュー対応まで、翻訳コントリビューションで押さえるべき重要なポイントを紹介します。

kubernetes.ioへの
コントリビューションを始める前に

翻訳のコントリビューションを始める前に、Kubernetesドキュメントがどのように運営されているかを理解することが重要です。Kubernetesのドキュメントはkubernetes/websiteリポジトリで管理されており、「Hugo」という静的サイトジェネレーターでWebサイトが生成されています。翻訳作業は、このリポジトリにPull Requestを送ることで貢献します。

最初に読むべきリソース

Kubernetesプロジェクトには、コントリビューターのための包括的なドキュメントが用意されています。翻訳を始める前に、まず「Kubernetes Contributor Guide(k8s.dev)」を確認しましょう。このサイトにはPull Requestの出し方、Issue管理、テストの実行方法など、コントリビューターが知っておくべき基本的な情報が網羅的にまとまっています。特にPull RequestsプロセスのガイドはGitHubのワークフローやKubernetes特有のbot(Prow)、マージに至るまでの一連のプロセスについて説明されているため、一読することをお勧めします。

日本語翻訳に特化した情報はkubernetes.io/ja/docs/contribute/localization/にまとめられています。このページには翻訳の流れ、スタイルガイド、用語の表記方法などが詳しく記載されており、日本語翻訳する上で最も参考になるドキュメントです。翻訳作業を進める上で迷ったときは、常にこのページを参照してください。

コミュニティとのつながり

Kubernetesのコントリビューションは1人で完結するものではありません。日本語翻訳チームは主にKubernetesの公式Slackの#kubernetes-docs-jaチャンネルでコミュニケーションをしています。誰でも翻訳に関する質問、スタイルガイドの解釈、用語の使い方などについて気軽に質問できます。またレビューの依頼や新しい翻訳者への歓迎も行われています。コミュニティとつながることで、より深い学びや、より楽しい翻訳作業ができるようになります。

なお、すべての翻訳作業はGitHubのIssueで管理されています。GitHub Issueにより誰がどのページを翻訳しているかを可視化し、重複作業を防いでいます。メンテナはラベルやコメントを活用することで効率的にトラッキングを行い、翻訳状況を把握できます。

開発環境の準備

翻訳のコントリビューションを始めるには、ローカルで開発環境を構築し、翻訳した内容をプレビューできるようにする必要があります。具体的な手順はリポジトリのREADME.mdに詳しく記載されていますが、ここでは環境構築で理解しておくべきポイントを説明します。

コンテナを使った環境構築

kubernetes/websiteはコンテナ(Docker)を使った実行とHugoを直接インストールして実行する2つの方法をサポートしています。2026年3月現在はコンテナを使った実行が推奨されています。理由は明確でHugoのバージョンやその他の依存関係を気にする必要がなく、コンテナ内ですべてが完結するためです。本番環境との一貫性も高く、依存関係の管理が簡単になります。

Hugoを直接使う方法もありますが、こちらはnetlify.tomlで指定されているバージョンのHugo Extended versionをインストールする必要があり、バージョン管理の手間がかかります。特別な理由がない限り、コンテナを使った実行を選ぶことをお勧めします。

環境構築でつまずいたら

環境構築でエラーが発生することもあります。よくある原因はDockerに割り当てられたCPU/メモリが不足していることです。設定からリソースの割り当てを増やすことで解決することが多いです。また、Hugoを直接使う場合はExtended versionを使用しているか、バージョンが正しいかを確認してください。

それでも解決しない場合はCONTRIBUTING.mdを確認するか、Slackの#kubernetes-docs-jaチャンネルで質問できます。コミュニティには同じ問題を経験した人がいるはずで、快く助けてくれるでしょう。英語でのコミュニケーションに抵抗がなければ#kubernetes-new-contributorsチャンネルのような、より広範なコミュニティチャンネルでも質問ができます。

翻訳作業の実践

環境が整ったら、実際に翻訳作業を始めましょう。ここでは翻訳作業のワークフローと、翻訳する際に押さえるべきポイントを説明します。

翻訳の流れ

翻訳の具体的なワークフローは日本語版ローカライゼーションガイドに記載されていますが、基本的な流れは以下の通りです。

1. Issue一覧から翻訳したいページのIssueを探すか、存在しない場合は新しく作成します。
2. Issueのコメント欄に/assignと書き込み、自分自身をアサインします。これにより作業中であることを他のコントリビューターが把握できるようになります。
3. 自分のForkのmainブランチから新しいブランチを作成し、翻訳作業を実施します。

なお、具体的なGit/GitHubの操作方法についてはkubernetes.ioのPRガイドなどを参照してください。

迷ったときの判断基準

翻訳中に用語や表現に迷った場合は、まずスタイルガイドに記載があるか確認します。次にAPIリソースの一覧や標準化用語集で用語を確認します。

それでも分からない場合は、既存の日本語翻訳ページで同じ用語がどう訳されているかを検索したり、Slackの#kubernetes-docs-jaチャンネルでコミュニティに質問したりすることができます。1人で悩まずにコミュニティの知恵を活用してください。

Pull Requestの作成とレビュー対応

翻訳が完了したら、変更をコミットしてPull Requestを作成します。Pull Requestは単に変更を提出するだけではなく、レビュアーとのコミュニケーションの場でもあります。

レビューは学びの機会

Pull Requestを作成すると、多くの場合は日本語翻訳チームのメンバーがレビューしてくれます。実際のPRの例としてkubernetes/website #44182を見てみましょう。このPRは筆者の初めてのコントリビューションです。(この記事の執筆時点で)約2年前に作成されたもので、当時は右も左も分からない状態で取り組みました。

レビューは学びの機会です。レビュアーからのフィードバックを通じて、より良い翻訳のスキルやスタイルガイドの理解が深まります。特に貢献を始めて間もない方は、多くのコメントを受け取ることになるでしょう(実際、上記のPRでも多くのレビューコメントが確認できます)。これらのコメントは決して批判的なものではなく、スキルを向上させる絶好の機会です。すべてのコメントが解決するとマージプロセスに進むことができます。

Kubernetesプロジェクトのマージプロセス

KubernetesではPull Requestのマージに2つの承認が必要です。/lgtmはレビュアーが内容を確認し「問題ない」と判断したことを示します。/approveはApproverが最終的な承認を実施します。両方のコマンドが実行されるとPRはマージキューに追加され、自動的にマージされます。

現状の課題と今後の展望

kubernetes.ioの日本語翻訳プロジェクトは活発に活動していますが、いくつか課題も抱えています。

継続的な翻訳元への追従

Kubernetesは活発に開発が続けられており、英語のドキュメントも頻繁に更新されます。そのため、一度翻訳したページも英語版の更新に追従して更新する必要があります。更新の頻度は高く、特に人気のあるページや新機能に関するページは頻繁に更新されます。どのページが更新されたかを把握するのが難しく、新規翻訳に比べて更新の翻訳は見落とされがちです。

もし古くなったページを見つけたときは、コントリビューションするための第1歩です！ぜひ古くなっていることをIssueとして報告してください。もちろんそのIssueを自分自身で取り組むこともできるし、他のコントリビューターにも任せることもできます。

表記揺れとスタイルガイドの重要性

多くの人が翻訳に貢献することで、同じ用語や表現が異なる訳語で翻訳されてしまう「表記揺れ」が発生することがあります。これを防ぐために日本語版スタイルガイドが定義されています。スタイルガイドには基本的な文体や句読点の使い方、カタカナ語の長音の有無、よくある表記のルール、頻出する用語の表記方法などが含まれています。

しかし、長い期間が経つにつれてページ間での表記揺れやガイドラインでは明確に定義されていない新しい技術用語の登場により、徐々にスタイルの一貫性が損なわれていくことがあります。特にオープンソースプロジェクトでは人の入れ替わりが頻繁に発生するため、人が変わってもスタイルを維持する重要性が求められます。

まとめ

本記事ではkubernetes.ioへの日本語翻訳のコントリビューションについて、環境構築から実際のPR作成、レビュー対応までの流れを解説しました。重要なのは細かい手順ではなく「コントリビューションの考え方」と「コミュニティとの関わり方」です。

具体的な手順はREADME.mdに環境構築の詳細が、ローカライゼーションガイドに翻訳の流れとスタイルガイドが、k8s.devやkubernetes.ioのPRガイドにGitやGitHubの具体的な操作方法、Pull Requestの流れが記載されています。

ドキュメントの翻訳は、コードを書くコントリビューションとは異なり比較的技術的なハードルが低く、かつKubernetesコミュニティへの大きな貢献となります。日本語のドキュメントを充実させることで日本のエンジニアがKubernetesをより理解しやすくなり、コミュニティ全体の成長につながります。

第一歩として、まずKubernetes公式Slackに参加し、#kubernetes-docs-jaチャンネルで挨拶してみてください。次にGitHubのIssue一覧から翻訳したいページを探し、公式ドキュメントを参照しながら実際に翻訳のPull Requestを作成してみましょう。レビューを通じて学び、さらに貢献を続けることで、あなたもKubernetesコミュニティの一員として成長していくことができます！

最初は小さな一歩でも、コミュニティ全体にとって大きな価値があります。ぜひ、あなたもkubernetes.ioの日本語翻訳に貢献して、Kubernetesコミュニティの一員として活動してみてください！