この記事の対象: ShopifyでのEC構築・リニューアルを検討している事業者、公開後に「英語が残っている」で困っている運用担当者
読了時間: 約12分
Shopifyを触りはじめて最初につまずくのが、日本語化です。管理画面を日本語にしたのにストアのボタンは「Add to cart」のまま。ストアを日本語にしたのに、お客さまに届く注文確認メールが英語で戻ってくる。テーマを日本語にしたはずなのに、検索結果の見出しだけ英語が残る。
原因はシンプルで、Shopifyの言語設定は1か所ではなく4か所に分かれているからです。しかも4つは連動しません。どれか1つを日本語にしても、残り3つは英語のまま放置されます。
この記事では、その4か所がそれぞれどこにあるのか、どの順番で設定すべきか、そして「設定画面をいくら探しても日本語にならない箇所」をテーマの言語ファイルからどう直すかまでを扱います。制作会社として構築を請けている立場と、自社でもShopifyストア（Dawnをベースにカスタマイズし、機能によってはアプリを使わず自前で実装しています）を運用している立場、その両方から見て「ここで詰まる」というポイントを中心に書きました。
なお、Shopifyの管理画面のメニュー名や設定の場所は更新が入ることがあります。本記事の記載と画面が食い違う場合は、Shopifyの公式ヘルプの最新の記載を優先してください。
日本語化が1か所で終わらない理由
4つの言語設定は、それぞれ別の対象を持っている
Shopifyの言語まわりを整理すると、次の4層になります。
① 管理画面の言語
- スタッフ個人ごとの設定
- お客さまには影響しない
② ストアの言語（公開言語）
- ストアフロントの基準言語
- デフォルト言語と追加言語がある
③ テーマの固定文言
- 「カートに追加」などのUI文言
- テーマの言語ファイルが持つ
④ 通知メール・SMS
- 注文確認・発送通知など
- テンプレートは別管理
①はスタッフ向け、②③④はお客さま向け。混同すると「自分の画面では日本語なのにお客さまには英語」が起きる。
この図で押さえてほしいのは、①だけが「中の人向け」で、②③④は「お客さま向け」という点です。担当者が自分の管理画面を日本語にして「日本語化できた」と思い込み、公開後にお客さまから「英語のメールが来たんですが」と連絡が来る——これがいちばん多い事故の形です。
どの層で英語が残っているかを切り分ける
「英語が残っている」という報告を受けたら、まず場所を特定します。切り分けの目安は次の通りです。
| 英語が残っている場所 | 原因の層 | 直す場所 |
|---|---|---|
| 管理画面のメニュー・設定名 | ① 管理画面の言語 | スタッフのアカウント設定 |
| 商品名・商品説明・ページ本文 | 入力データそのもの | 商品・ページの編集画面 |
| 「Add to cart」「Sold out」などのボタン | ③ テーマの固定文言 | テーマの言語編集 |
| 「Search results for」「Your cart is empty」 | ③ テーマの固定文言 | テーマの言語編集（見落としやすい） |
| チェックアウト画面の項目名 | ② ストアの言語 | ストアの言語設定 |
| 注文確認メール・発送通知メール | ④ 通知テンプレート | 通知設定 |
| アプリが表示している文言 | アプリ側の設定 | 各アプリの管理画面 |
最後の行が地味に厄介です。レビューアプリやポイントアプリを入れると、そのアプリが出す文言はShopify本体の言語設定を見ていません。アプリごとに翻訳設定を持っているものもあれば、日本語に対応していないものもあります。この点は後半の「アプリで足りる範囲、テーマ改修が要る範囲」で扱います。
設定する順番
4層は独立していますが、作業の順番には合理的な並びがあります。②ストアの言語 → ③テーマの固定文言 → ④通知メール → ①管理画面の順です。
②を先に決めるのは、デフォルト言語が翻訳漏れのフォールバック先になるからです。ここが英語のまま③④を進めると、「直したはずなのに英語が出る」箇所と「そもそも翻訳が無いから英語が出る」箇所が混ざり、切り分けに余計な時間がかかります。①を最後に置いているのは、スタッフ個人の設定であってお客さまの見え方に影響しないためです。作業者自身は英語表示のままでも構築は進みますが、納品前には必ずクライアントが使うアカウントで確認します。
① 管理画面の言語を日本語にする
設定はスタッフ個人ごと。ストア全体の設定ではない
管理画面の表示言語は、ストアの設定ではなくログインしているスタッフごとの設定です。管理画面右上のアカウント名から自分のプロフィールを開き、言語の項目で「日本語」を選びます。
ここがスタッフ個人ごとであることには実務上の意味があります。
- 制作会社の担当者が英語表示のまま作業していても、クライアント側の担当者の画面には影響しない
- 逆に、クライアント側の複数人が触る場合、新しく招待したスタッフの初期表示は日本語とは限らない
- 海外のパートナーを招待しても、その人の画面だけ英語にできる
構築案件では、納品前に「クライアント側で実際に使うアカウントでログインして表示を確認する」ところまでやっておくのが安全です。制作側のアカウントで見た画面と、クライアントが見る画面は別物になり得ます。
管理画面が日本語でも、翻訳が追いつかない箇所はある
Shopifyは新機能を英語で先行リリースし、日本語のUI翻訳が後から追いつくことがあります。管理画面を日本語にしていても、リリース直後の機能の設定名やヘルプ文言が英語のまま、というのは珍しくありません。
これは設定ミスではないので、直しようがありません。運用担当者に「新しい機能のところは英語が出ることがある」と一言伝えておくだけで、問い合わせが1本減ります。
② ストアの言語（公開言語）を設定する
デフォルト言語と追加言語の関係
ストアフロント側の言語は、管理画面の「設定 → 言語」で管理します。ここで押さえる概念は2つです。
- デフォルト言語：ストアの基準となる言語。翻訳が用意されていないときに表示される言語
- 追加言語（公開言語）：デフォルト言語に加えて公開する言語。多言語ストアにするときに追加する
日本国内向けのストアなら、デフォルト言語を日本語にするのが基本です。ここが英語のままだと、翻訳が用意されていない箇所がすべて英語にフォールバックします。「ほとんど日本語なのに、たまに英語が顔を出す」状態の主犯はここであることが多い。
デフォルト＝日本語
- 翻訳漏れは日本語で表示される
- 国内客に英語が出にくい
- あとから英語を追加言語にできる
デフォルト＝英語のまま
- 翻訳漏れがすべて英語で露出
- チェックアウトに英語が混ざる
- 原因の特定に時間がかかる
デフォルト言語は後から変更できますが、変更すると既存の翻訳データとの対応関係が動きます。多言語運用を始めたあとで基準言語を入れ替えるのは、翻訳の入れ直し作業を伴うことがある。構築の初期段階で決め切っておくべき項目です。
多言語ストアにするかどうかの判断
「将来的に海外にも売るかもしれないので、最初から英語も入れておきたい」という要望はよく出ます。ここは冷静に判断したほうがいい論点です。
多言語を有効にすると、以下が増えます。
- 翻訳対象が増える（商品名・商品説明・コレクション名・ページ・メタフィールド・テーマ文言・通知メール）
- 商品を1点追加するたびに、言語の数だけ翻訳作業が発生する
- 翻訳が抜けている箇所はデフォルト言語で表示されるため、中途半端な混在が起きる
- URLの構造が言語ごとに分岐し、SEOの管理対象が増える
つまり、多言語化のコストは構築時ではなく運用時に効いてきます。商品を月に何十点も入れ替える運用なら、翻訳の運用フローを先に決めておかないと、半年後には英語版が更新されていないストアができあがります。
判断の目安としては、「海外向けの売上目標が具体的に立っているか」「翻訳を誰がやるのか（社内・翻訳会社・機械翻訳＋校正）が決まっているか」。この2つが決まっていないなら、多言語化は後回しにして、まず日本語を完成させるほうが合理的です。多言語対応そのものはあとから追加できます。
URL構造まわりの制約については、こちらの記事で詳しく扱っています。
③ テーマの固定文言を日本語にする
ここが「日本語化の本丸」
Shopifyの日本語化で最も手間がかかり、かつ最も見落とされるのがこの層です。
テーマには、商品データとは別にテーマ自身が持っている文言があります。「カートに追加」「売り切れ」「在庫あり」「送料は購入手続き時に計算されます」「検索結果」「該当する商品がありません」——こういった文字列は、商品登録画面のどこを探しても出てきません。テーマの言語ファイル（ロケールファイル）に入っています。
海外製の有料テーマを使う場合、この言語ファイルに日本語が含まれていないことがあります。その場合、テーマの設定をどれだけいじっても英語のままです。
言語ファイルを編集する2つの入口
テーマの文言を日本語にする方法は、大きく2つあります。
ルートA（管理画面） は、オンラインストア → テーマ → 対象テーマのメニューから「言語を編集」を開くルートです。カテゴリごとにタブが分かれていて、各項目のテキストを日本語に打ち替えられます。コードを触らずに済むので、運用担当者に引き継げるのが利点。
ただし欠点があります。項目数が多く、どこにどの文言が対応するのかが画面からは分かりにくい。「Search results for」を直したいのに、それが「一般」タブなのか「検索」タブなのか探し回ることになります。
ルートB（コード編集） は、テーマのコード編集画面で locales/ ディレクトリの中にあるJSONファイルを直接編集するルートです。ファイル名は次のような構成になっています。
| ファイル | 中身 |
|---|---|
ja.json |
ストアフロントに表示される日本語文言 |
en.default.json |
ストアフロントに表示される英語（デフォルト）文言 |
ja.schema.json |
テーマエディタ上の設定項目名（管理画面側） |
en.default.schema.json |
同上の英語版 |
.schema.json が付くほうは、お客さまには見えません。テーマエディタでセクションを編集するときのラベル（「見出し」「画像」「表示件数」など）です。ここが英語でも売上には影響しませんが、クライアントがテーマエディタを触る運用なら日本語にしておくと問い合わせが減ります。
どちらのルートを選ぶかの目安は、直す件数です。数か所の言い回しを変えるだけならルートAが速い。テーマ全体に日本語が入っていない状態から立ち上げるなら、ルートBでファイルを開いて一気に埋めるほうが確実です。ルートAは「どの項目がまだ英語か」を一覧で見渡せず、埋め漏らしが起きやすいという弱点があります。
編集は次の手順で進めます。
この手順で外せないのが最初の「複製」です。ライブテーマのJSONを直接編集して構文を壊すと、ストアフロントが表示できなくなります。カンマ1つの入れ忘れで全ページが落ちる種類のファイルなので、必ず複製で作業してください。
編集するときの3つの注意点
キー名は絶対に変更しない。 JSONは "add_to_cart": "Add to cart" のような形で、左のキー名をテーマのコードが参照しています。キー名を日本語にするとテーマ側から参照できなくなり、その箇所が空欄になります。書き換えるのは右側の値だけです。
プレースホルダを消さない。 {{ count }}件の商品 のような二重波かっこの部分は、数字や商品名が動的に入る場所です。ここを消すと数字が表示されなくなります。翻訳するときは、かっこの中身はそのまま残して周りの日本語だけを整えます。単数形と複数形でキーが分かれている（one / other のような形）箇所もあり、英語では文法上必要な区別ですが、日本語では両方に同じ訳を入れて構いません。片方だけ訳して片方を英語で残すと、件数によって英語が顔を出します。
テーマをアップデートすると編集内容が消える可能性がある。 有料テーマの新バージョンに更新すると、ロケールファイルも上書きされます。翻訳を大量に当てている場合、更新のたびに作業が再発する。編集内容を別途控えておくか、更新前に差分を取れる体制にしておくのが実務上の対策です。
テーマの選び方そのもの——無料テーマ・有料テーマ・オリジナル制作のどれを選ぶかは、日本語化の手間にも直結します。
日本語対応テーマを選べば楽になるか
「最初から日本語対応のテーマを選べばいい」という考え方は正しいのですが、「日本語対応」の中身はテーマによって差があります。
確認したいのは次の点です。
- ロケールファイルに
ja.jsonが含まれているか（含まれていなければ全文自前） ja.schema.jsonもあるか（テーマエディタまで日本語化されているか）- 訳文の品質（機械翻訳をそのまま入れているテーマもある。「カートに加える」「かごに入れる」など表記ゆれが残る）
- テーマの最終更新日（更新が止まっているテーマは、Shopify本体の新機能に追随しない）
Shopify公式が配布しているDawnのような基本テーマは、日本語のロケールファイルが用意されており、この点では扱いやすい部類です。海外の有料テーマは見た目が魅力的でも、日本語まわりの整備が薄いことがあります。デモを見るときに、可能なら言語切り替えで日本語表示を確認してから選ぶと、あとの作業量が変わります。
もう一点、テーマを見る段階で確認しておきたいのが日本語を入れたときのレイアウト耐性です。欧文は単語の途中で折り返さない前提で組まれているため、ボタンやナビゲーションの幅が英単語の長さに合わせて決め打ちされていることがあります。そこに日本語を入れると、文字数が変わって2行になる、はみ出す、逆にスカスカに見える、といったずれが出ます。デモで日本語表示が確認できないテーマなら、購入後に複製テーマへ実際の文言を流し込んで、ボタンとナビゲーションだけでも早い段階で見ておくと手戻りが減ります。
④ 通知メール・SMSを日本語にする
通知テンプレートは独立して管理されている
注文確認、発送通知、パスワード再設定、放置カートのリマインド——これらのメールは、テーマの言語ファイルとは別に管理されています。「設定 → 通知」から各テンプレートを開いて編集します。
ストアのデフォルト言語を日本語にしていれば、標準の通知テンプレートは日本語で送られます。それでも英語が混ざるケースは主に3つです。
| 症状 | 原因 |
|---|---|
| メール全体が英語 | ストアのデフォルト言語が英語のまま |
| 一部の項目名だけ英語 | テンプレートを過去にカスタマイズしていて、その部分が英語 |
| 特定の顧客にだけ英語で届く | その顧客の言語設定・多言語ストアの言語判定 |
2番目は、制作会社がテンプレートをカスタマイズした案件でよく起きます。デザインを当てるためにHTMLを書き換えたとき、そこに英語のラベルが残っている。引き継ぎ後の担当者からすると原因が全く見えないので、カスタマイズした通知テンプレートは、どれを触ったかを一覧で残しておくのが親切です。
なお、通知の対象はメールだけではありません。SMS通知を有効にしている場合、発送通知などの短文テンプレートが別に存在します。メールだけ確認して公開すると、SMSが英語のまま残ることがあります。SMSを使う運用なら、確認対象に加えてください。
通知メールで確認しておく実務項目
日本語化そのものとは少しずれますが、通知メールは実際にテスト送信して確認する工程を必ず入れてください。見るポイントは以下です。
- 差出人のメールアドレスと表示名（デフォルトのままだと不信感につながる）
- 件名の日本語が途中で切れていないか（スマホの通知欄は表示文字数が短い）
- 金額表記が「¥」で出ているか
- 日付の表記形式（英語圏形式のまま残っていないか）
- 住所の並び順（郵便番号・都道府県の順序が日本の慣習に合っているか）
- テキスト版（HTMLを表示しない環境向け）でも読めるか
住所の並び順は、日本のストアで意外と指摘が来る箇所です。海外テンプレートをベースにしていると、番地から先に来る並びのまま残っていることがあります。
テスト送信は、できれば複数のメール環境で受け取って見比べてください。同じHTMLでも、Gmailのアプリ・iPhoneの標準メール・PCのOutlookで改行位置や文字サイズの出方が変わります。日本語は英語より1行あたりの情報量が多く、幅が狭い環境では意図しない位置で折り返して読みにくくなることがあります。
アプリで足りる範囲と、テーマ改修が必要になる線引き
翻訳系アプリが解決するのは「量」の問題
Shopifyには翻訳を支援するアプリが複数あります。Shopify公式が提供している翻訳機能を使うものもあれば、サードパーティ製で機械翻訳と連携するものもあります。無料枠のあるものから月額課金のものまで幅があります（料金も提供内容も変更されるため、最新の情報は必ず各アプリのページで確認してください）。
これらのアプリが本当に解決するのは、「多言語ストアで、大量の商品データを言語ごとに管理する」という量の問題です。日本語だけの単一言語ストアで「英語が残っている箇所を直したい」という課題に対しては、アプリを入れても解決しないことがあります。テーマのロケールファイルに日本語が無いなら、結局そこを埋める作業が必要だからです。
線引きを整理すると次のようになります。
アプリで足りる
- 多言語ストアで商品データを翻訳したい
- 言語切り替えUIを付けたい
- 翻訳の一括管理・一括更新をしたい
- 訪問者の地域で言語を出し分けたい
テーマ改修が要る
- テーマ固有の文言が英語のまま
- 日本語のフォント・行間・改行位置を整えたい
- 縦書きや禁則処理を扱いたい
- アプリが触れない箇所に文言がある
右側の「日本語のフォント・行間」は、日本語化を語るときに抜けやすい論点です。海外テーマは欧文フォント前提で行間や文字サイズが設計されているため、日本語を流し込むと詰まって見える、あるいは間延びして見えることがあります。文字は日本語になったのに読みにくい、という状態はアプリでは直りません。CSSの調整が要る領域です。
具体的には、見出しの行間が欧文基準のまま狭くて漢字がぶつかって見える、本文のletter-spacingが欧文用の値のまま入っていて日本語が間延びする、といったずれが起きます。改行位置も同様で、日本語は単語の区切りが空白で示されないため、意味の切れ目と関係ない場所で折り返されます。キャッチコピーのような短い文なら、意図した位置で改行を制御する必要が出てきます。
フォントの選択肢と費用感については、こちらで整理しています。
アプリを入れる前に見ておくべき4点
翻訳系に限らず、Shopifyアプリを検討するときに確認する項目です。制作側が案件で必ず見るのは次の4つです。
最終更新日。 更新が長く止まっているアプリは、Shopifyの仕様変更に追随できていない可能性があります。Shopifyはテーマの仕組みやチェックアウトの拡張方法を継続的に更新しているため、放置されたアプリは動かなくなるリスクを抱えます。
対応言語と、日本語の扱い。 アプリの管理画面が英語なのは我慢できても、アプリがストアフロントに出す文言が日本語にできないなら致命的です。「翻訳のアプリなのに、アプリ自身のUIが翻訳できない」という笑えない事態は起こり得ます。導入前に、お客さまの目に触れる文言をカスタマイズできるかを確認してください。
サポート体制。 日本語サポートがあるか、返信までにどれくらいかかるか。時差のある海外ベンダーだと、質問1往復に丸1日かかることがあります。運用が止まる性質の機能なら、ここは金額より重要です。
自社テーマとの相性。 アプリの中には、テーマのコードに埋め込みを追加するタイプがあります。これはカスタマイズしたテーマと衝突することがある。とくに、テーマを独自に組んでいる場合は、アプリ側が想定しているテーマ構造と噛み合わないケースがあります。導入するなら複製テーマで試してからライブに入れる、という手順は崩さないほうがいい。
導入後に効いてくる論点
アプリは「入れた瞬間」ではなく「入れて半年後」に効いてきます。制作会社として何度も見ている構図を挙げます。
- 月額の積み上がり。 1つ1つは小さくても、翻訳・レビュー・ポイント・在庫連携・レコメンドと積むと、月々の固定費として無視できない額になります。年間で見たときに、その機能をテーマ側に作り込んだ場合の費用と比較する視点は持っておくべきです。
- 表示速度。 アプリはストアフロントにJavaScriptやCSSを追加します。数が増えるほどページの読み込みが重くなる。ECの表示速度はコンバージョンに直結するので、「使っていないアプリを消す」は定期的にやる価値のある運用作業です。
- 解約時に残る要素。 アプリをアンインストールしても、テーマに埋め込まれたコードが残ることがあります。残骸が積もると、表示崩れの原因を追うのが難しくなる。解約時は、テーマのコードに残っていないか確認する工程を入れてください。
- 管理画面を触る人の負担。 アプリが増えるほど、運用担当者が覚える管理画面が増えます。担当者が1人しかいない体制で管理画面を5つも6つも増やすと、その人が退職した瞬間に誰も触れなくなる。
このあたりは、Shopifyでできることの限界とセットで考えると判断しやすくなります。
実際に運用している側から見た温度感
Shopifyでストアを自分たちでも運用していると、「アプリで解決するか、自前で作るか」の判断は、機能の重さよりもその機能を今後何年触り続けるかで決まる場面が多くなります。
短期のキャンペーン用の機能なら、アプリを入れて終わったら消すほうが早い。一方で、カート周りや商品ページの表示など、ストアの中核にあって毎日効いてくる部分は、アプリを重ねるほど後で身動きが取りにくくなります。テーマ側に持たせておくと、デザインの整合も速度も自分たちでコントロールできる。
日本語化に関して言えば、テーマのロケールファイルは自前で管理する領域だと考えたほうが素直です。アプリに依存させると、そのアプリを解約した瞬間に文言が戻る可能性を抱え込むことになります。
Shopifyをコーポレートサイトと兼ねる場合の日本語化
Shopifyを「ECだけ」ではなく、会社概要やお知らせを含めたコーポレートサイトと兼用する構成にする企業が増えています。この構成をとる場合、日本語化で追加の確認項目が出てきます。
コーポレート側のページ（会社概要、プライバシーポリシー、お問い合わせ）はShopifyの「ページ」機能で作ることが多く、ここは入力したデータそのものなので言語設定の影響を受けません。一方で、ページを取り囲むテーマのUI——パンくず、ページネーション、フォームのラベルやエラーメッセージ——はテーマの言語ファイルが持っています。
とくにお問い合わせフォームは要注意です。入力エラー時のメッセージが英語で出るフォームは、コーポレートサイトとしての信頼感を大きく損ないます。商品ページばかり確認して、フォームのエラー状態まで見ていない——という抜けは実際によく起きます。フォームは「わざとエラーを出して確認する」ところまでやってください。
ブログ機能を使う場合も同じです。記事本文は入力データですが、「投稿者」「タグ」「前の記事／次の記事」「コメントを残す」といった周辺のUI文言はテーマ側が持っています。お知らせを載せるためにブログを使う構成なら、記事を1本入れた状態で記事詳細ページまで開いて確認してください。トップと商品ページだけ見て終わると、ここが英語のまま残ります。
Shopifyをコーポレートサイトと兼用する考え方そのものは、こちらの記事で構造から整理しています。
日本語化チェックリスト：公開前に見る箇所
構築の最終確認や、リニューアル後の検収で使えるチェック項目をまとめます。すべて、実際にお客さまと同じ導線で確認するのが前提です。管理画面のプレビューだけでは見えない箇所があります。
| 確認する場所 | 見るポイント |
|---|---|
| トップページ | ナビゲーション、フッター、ニュースレター登録欄 |
| コレクションページ | 並べ替えの選択肢、絞り込み、「◯件の商品」の表記 |
| 商品ページ | カートボタン、在庫表示、数量、バリエーションのラベル |
| カート | 「カートは空です」、小計、送料の注記、備考欄 |
| チェックアウト | 各項目名、決済方法名、エラーメッセージ |
| 検索結果 | 「〜の検索結果」、ヒット0件のときの文言 |
| お問い合わせ | フォームのラベル、必須表示、エラーメッセージ |
| アカウント関連 | ログイン、新規登録、パスワード再設定 |
| ブログ・お知らせ | 投稿者、日付、タグ、前後の記事への導線 |
| 404ページ | 「ページが見つかりません」、戻る導線 |
| 通知メール | 注文確認、発送通知、パスワード再設定（テスト送信） |
| モバイル表示 | ハンバーガーメニュー内、モバイル専用UI |
見落としが集中するのは、エラー状態と0件状態です。正常系だけ確認して公開すると、お客さまがミスをした瞬間に英語が出る。検索して0件だったとき、フォームの必須項目を空で送信したとき、在庫が切れたとき——このあたりを意図的に発生させて確認してください。
もう一つ、確認そのものを漏らさないための工夫として、チェックした人と日付を残すことを勧めます。複数人で分担して見ると「誰かが見たはず」の箇所が生まれ、そこが本番で英語のまま出ます。上の表をそのままコピーして、確認者と確認日を書き込む列を足すだけで十分です。
リニューアル案件では、この確認工程をスケジュールに組み込んでおかないと、公開直前に時間が足りなくなります。
制作会社に依頼するときの伝え方
「日本語化してください」だけでは伝わらない
見積もりや要件のやり取りで「日本語対応込みで」とだけ書かれていると、制作側は範囲を判断できません。ここまで見てきた通り、日本語化は4層に分かれていて、層ごとに作業量が全く違うからです。
依頼時に明確にしておくと齟齬が減るのは、次の点です。
- 多言語にするのか、日本語のみか（ここで作業量が大きく変わります）
- テーマは何を使うか（日本語ロケールを持つテーマかどうか）
- 通知メールをデザインカスタマイズするか（標準テンプレートのままなら作業は軽い）
- テーマエディタの項目名も日本語にするか（クライアントが自分で触るなら必要）
- 既存の翻訳データを引き継ぐか（他カートからの移行案件で発生する）
とくに1つ目は、見積もりの金額差に直結します。「将来的に英語も」という含みのある表現で伝えると、その分の工数が見積もりに入っているのか入っていないのかが曖昧なまま進み、後で揉めます。今回やる範囲と、将来やるかもしれない範囲を分けて書いてもらうのが安全です。
なお、日本語化まわりの費用は「日本語化一式でいくら」という定額では出しにくい領域です。金額を左右するのは、使うテーマに日本語ロケールが入っているか、多言語にするか、通知メールをデザインから作り直すか、商品点数がどれくらいか、といった条件です。相見積もりを取るときは、この条件を各社に同じ文面で渡してください。条件が揃っていない見積もりを金額だけで比べると、安いほうが「テーマ標準の日本語をそのまま使う前提」だった、という食い違いが後から出ます。
見積もりの比較で金額差が出る理由については、こちらでまとめています。
納品時に受け取っておくべきもの
日本語化の作業を制作会社に任せた場合、納品時に以下を受け取っておくと、後々の運用が楽になります。
- 編集したロケールファイルの控え（テーマ更新時に再適用するため）
- カスタマイズした通知テンプレートの一覧
- 自分たちで文言を直したいときの手順（管理画面のどこから、何を触るか）
- テーマを更新するとどこが戻るかの説明
4つ目は、引き継ぎ後にいちばん困る点です。「テーマを最新にしたら英語に戻った」という問い合わせは、事前に説明がないと制作会社の不具合だと思われます。逆に、説明しておけば運用側で判断できます。
制作会社の乗り換えや引き継ぎが発生する場面でも、この控えの有無が作業量を左右します。
よくある質問
管理画面を日本語にすれば、ストアも日本語になりますか？
なりません。管理画面の言語はログインしているスタッフ個人の設定で、お客さまが見るストアフロントには一切影響しません。ストアフロント側は「設定→言語」のデフォルト言語と、テーマの言語ファイルの2つで決まります。管理画面だけ日本語にして安心してしまうのが、最も多い勘違いです。
「カートに追加」ボタンが英語のままです。どこで直しますか？
テーマの言語ファイル（ロケールファイル）です。オンラインストア→テーマ→対象テーマのメニューから「言語を編集」を開いて該当項目を日本語に打ち替えるか、テーマのコード編集で locales/ja.json を直接編集します。商品登録画面には無い文言なので、いくら商品データを探しても見つかりません。
注文確認メールだけ英語で届きます。原因は何ですか？
まずストアのデフォルト言語が日本語になっているかを確認してください。ここが英語だと通知も英語になります。デフォルトが日本語なのに英語が混ざる場合は、通知テンプレートを過去にカスタマイズしていて、その部分に英語のラベルが残っている可能性が高いです。設定→通知から該当テンプレートの中身を確認します。
海外の有料テーマを買っても日本語にできますか？
できますが、作業量はテーマ次第です。日本語のロケールファイル（ja.json）が同梱されていないテーマだと、UI文言をすべて自分で訳す必要があります。加えて、欧文フォント前提の行間や文字サイズで日本語が読みにくくなることがあり、CSSの調整も発生します。購入前にデモで日本語表示を確認できるなら、確認してから決めるべきです。
翻訳アプリを入れれば全部解決しますか？
多言語ストアで大量の商品データを翻訳するなら有効ですが、「日本語のみのストアでテーマ文言が英語」という課題には効かないことがあります。テーマのロケールファイルに日本語が無ければ、結局そこを埋める作業が必要です。またアプリに依存させると、解約したときに文言が戻るリスクを抱えます。テーマの言語ファイルは自前で管理する領域と考えるほうが安全です。
まとめ
Shopifyの日本語化は、次の4層をそれぞれ設定する作業です。
- 管理画面の言語 — スタッフ個人ごと。お客さまには影響しない
- ストアの言語 — デフォルト言語を日本語に。翻訳漏れのフォールバック先になる
- テーマの固定文言 — ロケールファイル（
ja.json）。最も手間がかかり、最も見落とされる - 通知メール — 独立管理。テスト送信で必ず確認する
この4つのうち、制作段階で判断が要るのは多言語にするかどうかとテーマ選びの2点です。多言語化は構築コストより運用コストが効くので、翻訳を誰が回すかが決まっていないなら日本語単体で完成させるほうが合理的です。テーマは、日本語ロケールの有無と訳文の品質で、後工程の作業量が大きく変わります。
公開前の確認では、正常系だけでなくエラー状態と0件状態を意図的に発生させてください。お客さまが操作をミスした瞬間に英語が出るのが、いちばん印象を損なう出方です。
