<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>翻訳</title><link>https://blog.ast.moe/tags/%E7%BF%BB%E8%A8%B3/</link><description>最近の記事: 五里霧中</description><generator>Hugo</generator><item><title>Sarashina Translate APIでブログの技術記事を英語にしてみた</title><link>https://blog.ast.moe/blog/2026-10-15/</link><pubDate>Thu, 15 Oct 2026 20:35:05 +0900</pubDate><guid>https://blog.ast.moe/blog/2026-10-15/</guid><description>&lt;p&gt;ブログに英語版を追加した。サイト側の言語切り替えを作ったあと、2026年に書いた技術記事51本を一つずつ英語の記事にする作業が残った。短い案内文だけなら手で書けるが、コードやリンクの多い長文をまとめて訳すには別の方法が欲しい。そこで&lt;a href="https://sarashina.ai/"&gt;Sarashina&lt;/a&gt;の&lt;a href="https://docs.sarashina.ai/api-reference/translate"&gt;Translate API&lt;/a&gt;を使ってみた。&lt;/p&gt;
&lt;p&gt;結果から書くと、本文を英語にするところまでは進められた。一方で、返ってきたテキストをそのままHugoへ入れることはできなかった。Markdownのリンク、ショートコード、コード例を原文と照合する作業の方が、思ったより重要だった。&lt;/p&gt;
&lt;h2 id="長い記事をどう渡したか"&gt;長い記事をどう渡したか&lt;/h2&gt;
&lt;p&gt;Translate APIは&lt;code&gt;ja&lt;/code&gt;から&lt;code&gt;en&lt;/code&gt;への翻訳に対応する。リクエストの&lt;code&gt;text&lt;/code&gt;は一つで、上限は空白や改行も含めてUnicodeのコードポイントで5000文字。利用した&lt;code&gt;sarashina3-translate&lt;/code&gt;の制限は1分あたり6リクエストだった。&lt;a href="https://docs.sarashina.ai/api-reference/translate"&gt;文字数の仕様&lt;/a&gt;と&lt;a href="https://docs.sarashina.ai/rate-limits"&gt;レート制限&lt;/a&gt;を見て、記事を段落の境界で分け、1回の入力を上限より小さくした。呼び出しの間隔も空け、429が返ったときは待ってから再試行した。&lt;/p&gt;
&lt;p&gt;APIキーは環境変数&lt;code&gt;SARASHINA_API_KEY&lt;/code&gt;から読む小さなヘルパーに渡した。キーの値を記事やリポジトリ、コマンドの引数へ書かないためだ。翻訳する前に、front matterの&lt;code&gt;date&lt;/code&gt;や&lt;code&gt;draft&lt;/code&gt;などの設定は取り出しておき、&lt;code&gt;title&lt;/code&gt;と&lt;code&gt;description&lt;/code&gt;、本文だけを翻訳対象にした。英語側のタグは、既存のタグに対応する表記を選んで組み直した。&lt;/p&gt;
&lt;p&gt;本文中のコードフェンスは最初から英訳の対象にしなかった。実行例の識別子や記号が変わると、説明とコードが食い違う。数式とインラインコードも目印に置き換えてから翻訳し、返答後に戻した。Mermaidの図のラベルと、手順を示す&lt;code&gt;text&lt;/code&gt;ブロックは、本文を訳し終えたあとに別途英語へ直した。&lt;/p&gt;
&lt;h2 id="翻訳後に壊れたもの"&gt;翻訳後に壊れたもの&lt;/h2&gt;
&lt;p&gt;最初に目立ったのはリンクだった。本文の意味は通っていても、Markdownのリンク記法だけが消えたり、URL中のコミットIDの一部が変わったりした。この原稿の英語版でも、APIの返答からMarkdownリンクが外れていた。Hugoの&lt;code&gt;link&lt;/code&gt;ショートコードも、消えた箇所と入れ子になった箇所があった。長い&lt;a href="https://blog.ast.moe/blog/2026-10-10/"&gt;Omoikaneの記事&lt;/a&gt;では、HTMLタグ名の説明が生の&lt;code&gt;&amp;lt;script&amp;gt;&lt;/code&gt;になり、Hugoのビルドが止まった。ここはコード表記に戻した。&lt;/p&gt;
&lt;p&gt;そのため、原文と英訳でURLとMarkdownリンク先の出現回数を照合し、数式、インラインコード、ショートコード、コードフェンスも確認した。足りないリンクは前後の段落を見て戻し、余計なURLや壊れた入れ子は手で直した。最後にHugo Extended 0.164.0でビルドし、51本すべての英語HTMLが生成されることを確認した。変更とCIは&lt;a href="https://github.com/ieee0824/blog-base/pull/137"&gt;ブログのPR #137&lt;/a&gt;に残っている。例えば&lt;a href="https://blog.ast.moe/en/blog/2026-10-10/"&gt;Omoikaneの記事の英語版&lt;/a&gt;は、元記事と同じURLの日付部分を持つ別ページになった。&lt;/p&gt;
&lt;h2 id="使ってみて"&gt;使ってみて&lt;/h2&gt;
&lt;p&gt;自分が困ったのは、英訳の一文を作るところより、記事として保ちたい構造をどこまでAPIへ任せられるかだった。Translate APIの応答は翻訳済みのテキストで、MarkdownやHugoの構文を保持する契約ではない。長文の技術記事では、翻訳を呼ぶ前に保護する箇所を決め、返答後に原文と照合する工程が必要だった。&lt;/p&gt;
&lt;p&gt;今回はリンクや構文が残っていることと、サイトがビルド・表示できることを確認した。英訳の意味の正確さを全51本について採点する評価セットは作っていない。今後、個々の記事で説明が分かりにくい箇所が見つかれば、日本語の原文とコードを見直して直していく。&lt;/p&gt;</description></item></channel></rss>