静的サイトジェネレータ「Hexo」日本語ドキュメントの翻訳
コントリビューションへ至った動機と作業の記録


静的サイトジェネレータ「Hexo」のドキュメント日本語訳を行った。翻訳対象は全45ページ、元は原文の英語を含む全6言語での提供だったが、これに日本語を加えるプルリクエストを作成、レビュー含め作業期間2週間ほどで、公開に至ることができた。

Hexo
Hexo
HexoはNode.js製の高速でシンプルかつ強力なブログフレームワークです。

この記事では、思い立って翻訳を開始した動機、作業の進行や気付きについて記録したい。

Hexoとは

公式ドキュメントでは、トップページでこのように紹介されている。

高速・シンプル・強力な ブログフレームワーク

無論、これも私が翻訳した文章だ。大まかな特徴としては以上の通り。

主にMarkdownで執筆した記事原稿をhtml形式で静的サイトとして出力する。基本的にはどのような用途にも使えるが、リードにも記されている通り、主にブログサイトの構築に有用な機能が多い。

加えて、サイトの見た目を変更するテーマシステム、Hexo自体の機能を強化するためのプラグインシステムが実装されており、これらの拡張もまた、単独のOSSとして公開可能だ。

参考

このブログもHexoで構築されている。記事へのスライド埋め込みPlantUMLで作図した画像の埋め込みはプラグインシステムによる拡張だ。ここには詳細は書けないが、とある業務で公開しているウェブサイトでもHexoを使っている。

翻訳の動機

「日本国内の利用者が増えて欲しい」に尽きる。

私自身は自作プラグインを公開する程度にHexoを使いこなしている。一方、何せ周囲にユーザーが少ないため情報交換には苦労している。

「Hexo ブログ」等でGoogle検索すると、日本語の紹介記事は主に2018年から2021年頃に書かれたものが多くヒットする。少なくとも日本国内では、人気のピークは過ぎたようだ。

これはおそらく、Next.jsやNust.jsなどSPAフレームワークが「SSG」という名称でほぼ同等の機能を提供するようになったことが大きい。SPA遷移の優位性もあり、今からブログを始めるのであればこれらが有利なのは間違いない。

だが求められる技術スキルも高くなってしまった。ブログの見た目の変更にtsxやコンポーネント管理の知識が必要となるのは、人によってはハードルが高い。

そこまでは対応できない、しかしWordPressに全てを任せることはしたくない。この層のユーザーにはHexoが最適と考えている。

そう思っていた矢先の2023年後半、Hexoによるブログ構築に関する日本語の記事を立て続けに見つけた。新たなプラグインを公開してくださる方も現れた。これであれば、施策として翻訳をしてみる価値があるのでは、そう今年はじめから考えていた。

翻訳の開始とChatGPT

ところで、翻訳を開始する直前まではPHPerKaigi 2024レギュラートーク資料の作成に多くの時間を費やしていた。

資料作成ではChatGPT(GPT-4)やGPTsが大活躍した。トークの中でも、独創性やアイディアの必要のない、単純な「文章に関する作業」のほとんどはChatGPTに任せられるノウハウや感触を掴んだ。このノウハウは「翻訳」に活かせる、そう確信したことが翻訳の着手のきっかけだ。

思い立って作業を開始したが、翌日にはChatGPTによる荒訳はほぼ完了していた。

翌日になってしまった理由はChatGPTのトークン制限によるものだ。APIを使うなどトークン制限を気にしなくて良い環境であれば、おそらく数時間で終わっただろう。

余談:荒訳でのChatGPTの活用

まず試しに数ページだけ自分の力で翻訳した。これを通じ、翻訳や原稿の体裁(HexoのドキュメントもまたHexoで書かれているため体裁はそれに準拠)に関する要件を一通り洗い出した。

洗い出したこの要件をChatGPTが解釈しやすそうなプロンプトとして書き下しまずはそれを入力。後は各ページの原稿をChatGPTへひたすらコピー・ペーストすれば良い流れを作った。

プロンプトは一発で作成できたわけではない。「プロンプト入力 → 原稿を数ページ入力」を何度か繰り返し、結果に問題が見つかった場合はプロンプト自体をブラッシュアップ。結果、翻訳開始時点では、次のようなプロンプトになっていた。

プロンプト

Webサイトのローカライズをお願いします。私からは原文となる英語の原稿を渡しますので日本語に翻訳した原稿を出力してください。

翻訳するWebサイトの概要

  • JavaScript製静的サイトジェネレータ Hexo の公式サイト
  • 現在は、英語、韓国語、中国語(繁体字)、中国語(簡体字)、ポルトガル語、ロシア語の6か国対応。
  • 英語が原文。それ以外は英語からの翻訳。
  • 一部のページは英語のみの提供
  • 英語以外に対応しているページは、全言語、内容は同じ。特定の言語のみに対応しているページや、特定の言語で欠落しているページは無い。

原稿の形式

  • 基本的にはMarkdown形式のテキストですが、以降の通りある程度の拡張構文が含まれます。
  • 冒頭にはYAML形式のメタデータ(Yaml Front Matter)が含まれます。
  • プレーンなMarkdownで表現できない部分はhtmlが含まれます。
  • 本文中に {{ ... }}{% ... %} などNunjucksの構文が含まれます。

翻訳の要件

  • Front Matterの項目名(titleなど)は変更しないで下さい。
  • Front Matterの値は日本語に翻訳してください。
  • 特定の固有名詞や専門用語を翻訳すべきかは、同等の話題に関する日本語の検索結果を参考にして下さい。例えば Static Site Generator が日本語で「静的サイトジェネレータ」と呼ばれていることは検索結果より確認できます。これらは訳して下さい。判断できない場合は私に確認を求めてください。
  • 本文は基本的に全て翻訳してください。ただし次の箇所は除きます。
    • 複数行コードブロック ``` やインラインコードブロック ` の内部のコード。ただし、プログラム中のコメントは訳す。
    • Nunjucks中のタグ(関数)の内部のコード。ただし、その中に、ユーザーへ表示することを想定した文言が含まれていた場合はそれを訳す。
  • Markdownのアウトライン構造は保持してください。つまり、見出しのレベルやリストの階層は変更しないでください。翻訳の都合で段落を分割する等は構いません。
  • 翻訳の際に特定のコンテキストやニュアンスを理解するため、例えば、冒頭で伝えたHexo公式サイトの情報や、例えば「Hexo 静的サイトジェネレータ」「Hexo ブログ」等の日本語検索結果を利用して構いません。
  • 日本語には「主語を省略できる」という特徴があります。原文の主語が明らかであれば、訳文では主語は省略しても構いません。

手順

  • 私からは1ファイル(1ページ)ずつ渡しますので、その都度翻訳してください。
  • 翻訳結果について私から改善や解説を求めることがあります。その際は解答をお願いします。
  • 翻訳の順序は原文の順序の通りです。読者も同じ順序で読み進める可能性が高いので、後のページを翻訳する際は以前に入力された前のページの知識を利用して構いません。

出力フォーマット

  • 翻訳後の原稿はMarkdown形式で出力してください。
  • 翻訳全体をコードブロック ``` で囲って下さい。
  • Markdown中のコードブロック構文は \``` とエスケープしてください。

これだけでかなり楽なのだが、後半は、トークン制限回復後のプロンプト再入力の手間も省けるよう、ほぼ同じ内容でプロンプトをGPTs向けに書き直しHexoドキュメント翻訳用のMy GPTsを作成した。

更に余談:ChatGPTのWebインターフェースは出力をどのように装飾しているか

これを行っている際、ChatGPTのWebインターフェースの少し微妙な挙動を発見してしまった。

ChatGPTは箇条書きや引用をそれらしいスタイルで表示してくれるが、内部ではそれをMarkdownで扱っているらしい。そして翻訳済原稿もMarkdownである。従って、ChatGPT自身が開始したコードブロックを原稿中のコードブロックが閉じてしまうことがある、

結果、Markdown形式でコピーしたい出力が途中からレンダリング済htmlに変わってしまうことがあった。上記プロンプト末尾の、エスケープに関する指示はこの現象への対策だ。

HTMLインジェクションならぬMarkdownインジェクション。何らかのいたずらを出来る気がするが、それはまだ試していない。

この類のプロンプトで出力される文章の質は直前までやっていたトーク資料作成で確認済。同じ品質で出力されるのなら、ここまでで作業の大部分が完了。最初はそう考えたのだが、あまりにも見込みが甘かった。

Pull Requestの作成と本格作業の開始

ここまでの内容をDraft Pull Requestとして作成し、「日本語ドキュメントを追加したいが、その後のメンテナンスコスト含め問題ないか?」というIssueと共に提出した。

方針が固まるまで数日かかると予想していたため、その間に校正することにした。ここであまりにも予想外に「納得のいかない翻訳」が多かった。そして、これを通じて「翻訳」という作業の難しさを知ることになる。

まず第一に、これは当たり前のことだが、原文の品質が完璧であるとは限らないことに気づいた。

決して元の文章が悪いわけではない。しかしよく考えてみると、私がこれまで読んできた技術文章の中で、「完璧な説明」に出会ったことは一度もない。

人間が書いた文章である以上当然だ。何らかの欠陥やノイズがあったとして、原文の段階で看過できるレベルであったとしても、機械翻訳というフィルタによって幾つかの情報が欠落したことにより看過できないレベルまで露呈してしまう、ということだろう。

加えて、これは推測だが、原文の多くは中国語圏の方が書いているという側面も大きい。原文をどう正確に訳しても、文中の主従関係や文同士の繋がりの不自然さを拭えない。

うまく言語化出来ないのだが、不自然な箇所には一定の共通点が見られる。”I have a pen”は日本人特有の言い回しだそうだが、中国語圏にも同じように「中国語英語」があるということだろうか。

ChatGPTは頭が良いため、これに該当するような箇所でもパッと見「それらしく」読めてしまう。斜め読みでは気付けないような細かい箇所での論理の破綻が主だったため、これに気づいた瞬間、自分の中で「全ての文章を再翻訳」が確定した。

また同時期に、全く別のXでの会話で、機械翻訳の結果をOSSに反映することのライセンス上のリスクに関する言及を目にした。今回は問題なしと判断できそうだったが、リスクはリスク、上述の課題含め、やはり再翻訳は必須と考えた。

思い立ったが吉日で開始、滑り出しも好調、実際に難なく完了。と思った矢先に気づいてしまったため、最初はかなり頭を抱えた。実際、ここから先が長かった。

再翻訳とレビュー

ここから先は「ひたすら(再)翻訳する」のみだ。夜3時間ほどを作業時間に宛て、数日かけて全ての原稿を見直した。

基本的には単純作業だが、実は「腰を据えて」「まとまった分量の文章を」「不特定多数へ公開」という翻訳は初だった。ここで1つの気付きがあった。

これまで、私が取り組んだことのある翻訳は「2」までだった。意訳して構わない(直訳では意味が通じないと判断できる明確な理由がある)箇所はある意味楽だ。原文をさほど気にせず自分の言葉を使えば良い。仮に原文の意味がわからない時も、OSSである以上、実際の挙動や該当箇所のコードを見れば何とでもなる。

ところで、今回まとまった分量を翻訳するにあたり、参考のため、同じような目的を持つアプリケーションを幾つか選び英文と訳文とを見比べたりした。その過程で「3」まできちんと行っている文章を幾つか目にした。

これは自分にとって青天の霹靂。最初は「言葉の選び方だけで、こんなことが出来るのか」といささかショックを受けた。こうなると語彙力との戦いになってしまう。目の前の翻訳で本当に良いのか疑問を抱きながら自分と戦うような感覚だ。

この点に関して、今回、納得のいく仕事は出来ていない。予め作成していたDraft Pull Requestをメンテナの方がレビューし始めてくださったため、そうするといたずらに時間はかけられない。土日を中心に活動している方のようなので「次の週末まで」と期限を切ってベストを尽くすことにした。

マージまでの段取り

日本人のメンテナと週末2日間をかけてレビューや修正のやり取りをしていたが、その間、なんと中国語を第一言語とする方が、日本語はあまり明るくないと前置きしながらレビューに参加してくださった。

内容は主にMarkdown上の構文の調整や日本語文書の存在する外部リンクの変更提案などだが、この作業、思いのほか大変だったと推察している。日本語の読める私が見ればと一瞥しただけで判断できる箇所なのだが、レビュアーの方は対象の文章を読めない中でそれをやっている。

助かったと当時に、本当に嬉しかった。中国語でブログを公開しているようなので拝見したところ、日本のアニメをとても好きな方のよう。今回のやり取りでは文化的な交流は一切なかったが、「プログラム言語」という共通言語を入口に言葉の通じない相手とすらコミュニケーションを取れる、これはプログラマーたる私達の大きな楽しみの1つだ。

翻訳のレビューを担当してくださった日本人のメンテナの方にも感謝している。

前述の通り、隅から隅まで全て文章を見直したつもりではあったが、不思議なもので、自分の文章にこそ間違いが見つけられないのだ。指摘されて初めて気づいたあまりにもわかりやすいミスが多数あった。大変なお手数をおかけした申し訳無さと共に、週末の限られた時間で対応し最初のDraft Pull Requestから2週間かからず公開まで漕ぎ着けてくださったことに、大変感謝している。

まとめ

冒頭に書いた通り、作業の動機は「日本国内の利用者が増えて欲しい」のみだ。

ところで、目的が何であれ、プロプライエタリな製品に対して第三者たる自分たちが何らかの影響力を行使するのは非常に難しい。道が用意されていないばかりか、禁止されていることすらある。

だがOSSであればその道は常に開けている。そして、その道には、おそらく誰かしらの協力者がいる。

今回改めて、それを実感できた。もしあなたが、好きなOSSに対して何らか課題や不満を見つけていたとしたら、是非、それを解決できるようなあなたのコントリビューションを見つけて欲しい。


SNSへシェア
はてなブックマーク