導入とオンライン

i18n.siteではシングルページアプリケーションアーキテクチャを採用しており、Webサイトの入口ページとWebサイトのコンテンツが独立して展開されています。

上記の変換を実行すると、ディレクトリmd/out/devの下にディレクトリhtmとv生成されます。

ここで、 dev .i18n/htm/dev.yml設定ファイルに基づいて構築されることを意味します。

devディレクトリー:

htmディレクトリは Web サイトの入り口ページです。

vディレクトリには、バージョン番号が付いた Web サイトのコンテンツが含まれています。

ローカルプレビューではバージョン番号は考慮されず、すべてのファイルがout/dev/v/0.1.0ディレクトリにコピーされます。

正式リリースの場合、変更されたファイルは新しいバージョン番号のディレクトリにコピーされます。

設定ファイルを`-c`で指定

異なる設定ファイルは、 outディレクトリに対応するディレクトリを作成します。

たとえば、 .i18n/htm/main.yml指定するとout/mainディレクトリが作成されます。

dev.ymlとmain.ymlデフォルトの構成です。

devはdevelopmentの省略形で、開発環境を示し、ローカルプレビューに使用され、デフォルトの構成ファイルでもあります。 olはonlineの省略形で、正式リリースに使用されるオンライン環境を示します。これは、コマンドラインパラメータ-n ～ npm使用してリリースする場合のデフォルトの設定ファイルでもあります。

他の構成ファイルを作成することもできます。コマンドラインで--htm_conf使用して、使用する構成ファイル名を指定します。

例えば:

i18n.site --htm_conf dist --save

ここで、 --saveアップデートのリリースのバージョン番号を表します。

コンテンツを npmjs.com に公開する

コンテンツをnpmjs.comに公開することが推奨されるデフォルトのソリューションです ( 「フロントエンドの高可用性」を参照)。

npmログイン&投稿

nodejsインストールし、 npm loginでログインします。

md/.i18n/htm/main.ymlを編集し、 md: YOUR_NPM_PACKAGE値を独自のnpmパッケージ名として変更します。 npmjs.com上の任意のパッケージ名を使用できます。

次に、 md/.i18n/htm/main.package.json変更します

mdディレクトリでi18n.site --npmまたはi18n.site -n実行して、翻訳して公開します。

継続的統合環境を使用して公開する場合、 nodejsインストールする必要はありません。ログイン済みの公開権限~/.npmrc環境にコピーするだけです。

main.ymlのv:のパッケージ名を変更する場合は、必ず.i18n/v/main削除してから公開してください。

npm によって公開されるプロキシサーバー

中国本土のユーザーがネットワークの問題に遭遇し、 npmパッケージを公開できない場合は、環境変数https_proxy設定してプロキシサーバーを構成できます。

プロキシサーバーのポートが7890であると仮定すると、次のように記述できます。

https_proxy=http://127.0.0.1:7890 i18n.site -n

自己ホスト型コンテンツ

コンテンツをセルフホストする場合は、まずmd/.i18n/htm/main.ymlを編集し、 v: //unpkg.com/i18n.site URL プレフィックス ( v: //i18n-v.xxx.comなど) に変更します。

mdディレクトリに入って実行します。

i18n.site --htm_conf ol --save

または略語

i18n.site -c ol -s

次に、 md/out/main/vディレクトリのコンテンツをv:で設定した URL プレフィックスパスに設定します。

最後に、末尾が/.vから1sパスのキャッシュ時間を構成します。そうしないと、新しくリリースされたコンテンツにすぐにアクセスできなくなります。

他のパスのキャッシュ時間を 1 年以上に設定して、不要なリクエストを減らすことができます。

コンテンツを s3 にホストする

コンテンツをセルフホストするには、独自のサーバーを使用することに加えて、 S3 + CDNを使用することも一般的なオプションです。

rclone使用してS3サーバーにログインし、次のスクリプトを参照して変更し、リリースごとに増分変更をS3にコピーするだけです。

i18n.site -c ol -s
s3=your-s3
bucket=your-bucket
ver=$(head -1 .i18n/v/main/v.hash | cut -c 2-)
rclone copy --overwrite-dir out/main/htm/v/$ver $s3:/$bucket/$ver
rclone copy out/main/v/.v "$s3:/$bucket/"

/.vで終わるパスのキャッシュ時間が1sになるようにCDNを構成することを忘れないでください。そうしないと、新しくリリースされたコンテンツにすぐにアクセスできなくなります。

ウェブサイトを公開する

Web サイトはどこにでも展開できます。 github pageとcloudflare pageは適切な選択です。

Web サイトは単一ページのアプリケーションアーキテクチャを使用しているため、 . 含まない URL パスを必ずindex.htmlに書き換えてください。

Web サイトのエントリページを展開する必要があるのは 1 回だけであり、その後のコンテンツ更新のために Web サイトのエントリページを再展開する必要はありません。

githubページにデプロイする

まずここをクリックして組織を作成しgithub 。以下の組織名は例としてi18n-demoです。

次に、この組織の下にウェアハウスi18n-demo.github.ioを作成します ( i18n-demo作成した組織名に置き換えてください)。

前回の記事の内容を公開するとout/main/htm生成されていますので、このディレクトリに入って:を実行してください。

ln -s index.html 404.html

github page URL パスの書き換えをサポートしないため、代わりに404.html使用されます。

次に、 htmディレクトリで次のコマンドを実行します ( i18n-demo/i18n-demo.github.io.git自分のウェアハウスのアドレスに置き換えることを忘れないでください) :

git init
git branch -M main
git remote add origin [email protected]:i18n-demo/i18n-demo.github.io.git
git push -u origin main -f

コードをプッシュした後、(以下に示すように) github pageのデプロイメントが正常に実行されるまで待ってから、それにアクセスしてください。

デモページについては、以下を参照してください。

https://i18n-demo.github.io

Cloudflareページでのデプロイ

cloudflare page github pageと比較して、パスの書き換えが可能であり、中国本土にとってより親しみやすく、使用することをお勧めします。

cloudflare pageの展開は通常、上記のgithub pageの展開に基づいています。

プロジェクトを作成し、上記のi18n-demo.github.ioウェアハウスをバインドします。

プロセスを次の図に示します。

組織i18n-demoへのアクセスを許可するには、 Add Accountをクリックしてください。

別の組織のウェアハウスをバインドしている場合は、新しい組織が表示される前に、 Add Account 2 回クリックして承認する必要がある場合があります。

次に、ウェアハウスi18n-demo.github.io選択してからBegin setupをクリックし、後続の手順ではデフォルト値を使用します。

初めてバインドした後、アクセスできるようになるまで数分間待つ必要があります。

展開後、カスタムドメイン名をバインドできます。

カスタムドメイン名をバインドした後、以下に示すように、ドメイン名に移動してシングルページアプリケーションのパス書き換えを構成してください。

上の図のルールは次のとおりです。以下の最初の行のi18n.siteバインドしたドメイン名に置き換えてください。

(http.host in {"i18n.site"}) and not (
substring(http.request.uri.path,-3) in {".js" ".gz"} or
substring(http.request.uri.path,-4) in {".htm" ".rss" ".css" ".svg" ".ico" ".png" ".xml" ".txt"} or
substring(http.request.uri.path,-5) in {".html" ".avif" ".json"} or
ends_with(http.request.uri.path,".webmanifest")
)

さらに、以下のようにキャッシュルールを設定し、キャッシュ期間を 1 か月に設定してください。

上の図の 2 番目の手順で一致するドメイン名を、バインドしたドメイン名に変更してください。

中国本土での Web サイト展開の最適化

中国本土のネットワーク環境でより良いアクセシビリティ性能を獲得したい場合は、最初にドメイン名を登録してください。

次に、中国本土のクラウドベンダーのオブジェクトストレージを使用します+ CDN out/main/htmのコンテンツを展開します。

エッジコンピューティングを使用して、単一ページアプリケーションに適応するようにパスを書き換えることができます。たとえば、 Baidu Smart Cloud CDN次のように構成できます。

const uri = r.uri, p = uri.lastIndexOf(".");
if (
  p < 0 ||
  !"|js|css|htm|html|md|avif|json|ico|xml|rss|gz|mp4|png|svg|txt|webmanifest|".includes(
    "|" + uri.slice(p + 1) + "|",
  )
) {
  const ua = r.headersIn["User-Agent"].toLowerCase()
  if (/facebookexternalhit|slurp|bot|spider|curl/.test(ua)) {
    r.return(
      302,
      (/baidu|yisou|sogou|360|byte/.test(ua) ? "/zh" : "/en") + r.uri + ".htm",
    )
  } else {
    r.uri = "/index.html"
  }
}

r.respHeader(() => {
  const t = [], out = r.headersOut;
  ["Content-MD5", "Age", "Expires", "Last-Modified"].forEach(
    i => delete out[i]
  )
  r.rawHeadersOut.forEach(i => {
    const key = i[0].toLowerCase()
    if (key.startsWith("x-") || key.startsWith("ohc-")) {
      delete out[key]
    }
  })
  out["Cache-Control"] = "max-age=" + 9e5
  // 応答ヘッダーは、out.XXX = 'MSG'; などのデバッグ出力に設定できます。
})

レコードMXとレコードCNAME共存できないため、ドメイン名メールを同時に受信したい場合は、レコードAにcname_flattenスクリプトをレベルCNAMEで連携させる必要があります。

さらに、中国本土のクラウドベンダーの海外トラフィック料金は比較的高価であるため、コストを最適化したい場合は、 Huawei DNSの無料の地理的解像度とCloudflare for SaaSのカスタムドメイン名を使用して実現できます。トラフィックの迂回──中国本土のトラフィックルーティングは Baidu Cloud CDN 、国際トラフィックはcloudflareになります。

これらの展開最適化ソリューションはより複雑であり、将来的には別の章で紹介される予定です。

汎用ドメイン名のリダイレクト

i18n.site使用して Web サイトをメイン Web サイトとして生成する場合、通常はパンドメインリダイレクトを構成する必要があります。つまり、アクセスを*.xxx.com ( www.xxx.comを含む) からxxx.comにリダイレクトします。

この要件は、Alibaba Cloud CDN EdgeScript (英語ドキュメント/中国語ドキュメント) の助けを借りて達成できます。

Alibaba CDNでドメイン名を追加し、Alibaba Cloud CDNでドメイン名*.xxx.comからCNAME指します。

たとえば、上の図の*.i18n.siteのパンドメイン名リダイレクト構成は次のとおりです。

rewrite(concat('https://i18n.site',$uri), 'redirect',301)

nginxでデプロイする

! のserver段落に次のような設定を追加してくださいnginx /root/i18n/md/out/main/htm独自のプロジェクトのパスに変更してくださいout/main/htm :

location / {
  root  /root/i18n/md/out/main/htm;
  add_header Cache-Control "max-age=9999999";
  if ($uri !~* \.(avif|css|html|ico|js|json|png|svg|txt|webmanifest|xml)$) {
     rewrite ^ /index.html last;
  }
}

`github action`継続的インテグレーションに基づく

github action設定するには、以下を参照してください。

name: i18n.site

on:
  workflow_dispatch:
  push:
    branches:
      - main
      - dist

jobs:
  i18n:

    permissions:
      repository-projects: write
      contents: write

    runs-on: ubuntu-latest

    steps:
      - name: checkout
        uses: actions/checkout@v4

      - name: https://i18n.site
        uses: i18n-site/github-action-i18n.site@main
        with:
          I18N_SITE_TOKEN: ${{ secrets.I18N_SITE_TOKEN }}
          NPM_TOKEN: ${{ secrets.NPM_TOKEN }}

構成からわかるように、このワークフローはブランチmainとブランチdistにプッシュするときにトリガーされます。

ワークフローは、ブランチ名に対応する構成ファイルを使用してドキュメントを公開します。ここでは、公開構成として.i18n/htm/main.ymlと.i18n/htm/dist.ymlそれぞれ使用されます。

ドキュメントのリリースプロセスについては、次のベストプラクティスをお勧めします。

変更がブランチmainにプッシュされると、ドキュメントの作成がトリガーされ、プレビューステーションに展開されます (プレビューステーションは使用可能ですgithub page )。

プレビューサイトでドキュメントが正しいことを確認した後、コードがマージされてブランチdistにプッシュされ、正式なビルドとデプロイがオンラインになります。

もちろん、上記のプロセスを実装するには、さらに構成を記述する必要があります。

ワークフロースクリプトについてはgithub.com/fcdoc/doc実際のプロジェクトを参照できます。

構成でsecrets.I18N_SITE_TOKENとsecrets.NPM_TOKEN使用するには、コードベースでシークレット変数を構成する必要があります。

I18N_SITE_TOKEN i18n.site/token

NPM_TOKEN 、構成内のパッケージnpmの公開トークンです。 npmjs.comにアクセスして、公開権限を持つトークンを作成します (以下を参照)。

ディレクトリ構造

`public`

Web サイトの静的ファイル ( favicon.ico 、 robots.txtなど)。

ここでのアイコンファイルはrealfavicongenerator.netで生成できます。

`.i18n`

.i18nディレクトリの下には、 i18n.siteの設定ファイルや翻訳キャッシュなどが置かれます。詳細については、次の章「設定」を参照してください。

`en`

ソース言語ディレクトリ.i18n/conf.yml構成ファイルのfromToに対応しますen

i18n:
  fromTo:
    en: zh

翻訳i18