去年我們有一個客戶需要將他們 118 頁的工業設備網站翻譯成 30 種語言。我們獲得的第一份報價是什麼？Weglot 每年 $8,388。第二份？翻譯機構報價 $15,000。我們實際花費的？$660。總共。一次性。不是每年。

那是每種語言 $22，而且我們擁有每一個翻譯文件。沒有供應商鎖定，沒有月度費用，當流量激增時也沒有驚喜定價層級。我將逐步向你展示我們的確切做法，比較 2026 年市場上每個主要多語言網站工具，並向你展示為什麼網站翻譯的經濟學已經從根本上改變了。

目錄

Best Multilingual Website Tools 2026: 30 Languages at $22 Each

為什麼大多數多語言工具定價過高

這是多語言網站工具市場的骯髒秘密：大多數工具對本應是一次性成本的東西向你收取月度費用。

想想看。你的行銷頁面不會每天都改變。大多數企業有大約 50 到 200 個核心頁面。一旦這些頁面被翻譯，它們就被翻譯了。你可能每個月更新 5-10 頁。也許。那麼為什麼你要為一個工具支付 $199-699/月，該工具每次有人加載頁面時都會重新翻譯相同的內容？

答案很簡單：經常性收入比一次性銷售更有利可圖。Weglot 等工具已經在這種模式上建立了價值數十億美元的企業。他們攔截你的頁面，通過機器翻譯實時運行，並向你收取月度費用以享受這個特權。翻譯不屬於你。如果你取消，它就消失了。

我對 Weglot 個人沒什麼意見 -- 他們的產品有效且易於安裝。但當你計算 30 種語言的數據時，數字變得荒謬。而且在 2026 年，隨著 LLM 翻譯的品質，你不再需要租借翻譯。你可以擁有它們。

7 個工具對比

讓我詳細介紹多語言網站工具領域的每個重要競爭者。在過去三年中，我在生產環境中使用了所有這些，所以這不是理論上的。

1. Weglot ($29-699/月)

Weglot 是龐然大物。他們在「最佳翻譯工具」的 Google 搜尋結果中佔據主導地位，因為他們在廣告和聯盟計劃上支出巨大。公平地說：他們的安裝死板簡單。放入一個 script 標籤，選擇你的語言，完成。

但問題迅速堆積：

  • 永遠的月度成本。 你在租借翻譯，而不是擁有它們。取消，一切都消失。
  • 機器翻譯品質變化很大。 日語和韓語明顯不如歐洲語言。
  • 沒有按頁面自訂。 你不能告訴它「以不同於該著陸頁的方式翻譯此產品頁面。」
  • 與動態內容衝突。 如果你渲染客戶端內容（在 Next.js 應用中很常見），Weglot 很難捕捉到一切。
  • 定價層級懲罰增長。 他們的 Business 計劃 $699/月是 30+ 語言或高頁面計數所需的。

對於 3 種語言的 5 頁宣傳冊網站，Weglot 很好。對於任何規模，數學崩潰。

2. WPML ($49-199/年)

WPML 是舊版 WordPress 翻譯插件。自 2009 年以來就存在，感覺就是這樣。

  • 僅限 WordPress。如果你用 Next.js 或 Astro 構建，它是無關的。
  • 與 Elementor 和 WPBakery 等頁面建構器的衝突是傳奇性的。
  • 在 WPML 界面中管理 30 種語言是真正的痛苦。
  • 無法處理大型動態網站（我們的客戶有 91K 個跨變體的總動態頁面）。
  • 你仍然需要在插件成本之上支付實際翻譯。

WPML 在 2015 年有意義。在 2026 年，如果你在 WordPress 上構建多語言網站，我會質疑 WordPress 是否是正確的選擇。查看我們關於 headless CMS 開發 的想法，了解為什麼我們已經將大多數客戶遷移出傳統 WordPress。

3. next-intl + Claude Haiku 批量翻譯（我們的方法 -- $22/語言）

這是我們實際使用的。我將在下面詳細介紹實施，但這是摘要：

  • 在 Next.js 中使用 next-intl 進行國際化路由和訊息格式設定。
  • 使用 Anthropic API 通過 Claude Haiku 批量翻譯所有 JSON 訊息文件。
  • 通過 Winston AI 運行每個翻譯以進行品質評分（95%+ 閾值）。
  • 對每種語言的 10-15 個最高價值頁面進行人工審查。
  • 總成本：$22/語言 × 30 種語言 = $660。一次。

4. Crowdin ($0-99/月)

Crowdin 是一個專業翻譯管理系統。這是真正優秀的軟體 -- 很棒的 GitHub 集成、針對管理人工翻譯的扎實工作流程、不錯的機器翻譯預填充。

陷阱：它是為有持續翻譯需求和員工中有人工翻譯人員的團隊設計的。平台成本只是開始。你還將在頂部支付 $0.10-0.25 每字以獲得專業人工翻譯。對於 118 頁 × 30 語言，這輕易達到 $50,000-150,000，具體取決於頁面長度。

Crowdin 對於具有不斷變化的 UI 字符串和專門本地化團隊的軟體產品有意義。對於網站？過度。

5. Lokalise ($0-120/月)

與 Crowdin 類似的故事。Lokalise 是優秀的企業翻譯工作流軟體。如果你正在本地化一個有 10,000 個字符串每個衝刺更改一次的行動應用，Lokalise 賺得其價格。

要翻譯網站的行銷頁面？你正在為你不需要的工作流工具付費。這就像買一台 CNC 機器來切割 2x4。

6. DeepL API ($5.49-25/月 + 按字符)

DeepL 對歐洲語言的翻譯確實比 Google Translate 更好。他們的神經網絡在德語、法語和荷蘭語中處理細微差別和語境特別好。

但是：

  • 按字符定價在規模上很差。有 91K 頁面和動態內容，如果按即時翻譯，你每個月看數百萬個字符。
  • 沒有內置品質門控。你得到你得到的。
  • 與 Claude 或 GPT 相比，語言支持有限。DeepL 覆蓋約 30 種語言 vs. Claude Haiku 的 100+。
  • 沒有跨你的網站的語境意識。每個 API 呼叫都是隔離的。

對於翻譯個別文件或電子郵件，DeepL 是奇妙的。對於批量網站翻譯，經濟學不奏效。

7. Google Translate API（每 1M 字符 $20）

大規模最便宜的選項和最低品質。Google Translate 對於用戶生成的內容很好，其中「足夠好」是可接受的。對於行銷頁面，其中語調、品牌聲音和準確性重要？輸出讀起來像... 好吧，就像 Google Translate。

我們在 Winston AI 品質評估中對日語的相同 118 頁測試了 Google Translate API 對 Claude Haiku。Google 評分 78%。Claude Haiku 評分 96%。這個差距是你看起來專業和看起來你不關心你的日語客戶之間的區別。

改變一切的成本分解

這是讓我們客戶下巴掉下來的表格。這假設 30 種語言、118 頁、2026 年定價：

工具 第 1 年 第 2 年 第 3 年 3 年總計 品質控制
next-intl + Claude Haiku $660 $0 $0 $660 Winston AI 95%+
Weglot (Business) $8,388 $8,388 $8,388 $25,164 僅機器
Weglot (Pro) $2,388 $2,388 $2,388 $7,164 僅機器
WPML + 人工翻譯人員 $15,000 $5,000 $5,000 $25,000 人工（昂貴）
Crowdin + 人工翻譯人員 $51,000 $3,000 $3,000 $57,000 人工（昂貴）
DeepL API (批量) $1,800 $1,800 $1,800 $5,400 無內置
Google Translate API $240 $240 $240 $720 無（低品質）

看看我們方法的第 2 年和第 3 年欄。$0. 因為你擁有文件。它們坐在你的 repo 中。它們隨著你的代碼部署。沒有 API 呼叫，沒有 SaaS 依賴，沒有月度發票。

在三年內，我們的方法相比替代方案節省 $6,500-$56,000。而且你比任何純機器選項獲得更高品質。

Best Multilingual Website Tools 2026: 30 Languages at $22 Each - architecture

品質控制：Winston AI 評分

我聽到的最大異議：「但機器翻譯品質很糟糕。」而誠實地說，那在 2024 年之前是真的。Google Translate 和早期神經機器翻譯模型產生功能但明顯不是人工的輸出。

2025-2026 年的 Claude Haiku 是不同的野獸。這是我們的品質控制管道：

  1. 批量翻譯 所有 JSON 訊息文件通過具有特定於語境的提示的 Claude Haiku（更多詳細信息如下）。
  2. 運行每個輸出 通過 Winston AI 翻譯品質評估。
  3. 設置 95% 品質閾值。 任何低於此的內容都被標記為人工審查。
  4. 人工審查 每種語言的前 10-15 個收入產生頁面，無論評分如何。
  5. 母語使用者抽查 每種語言的 5 個隨機頁面。

我們在 30 種語言上的結果：

  • 平均 Winston AI 品質評分：96.2%
  • 評分最低的語言（泰語）：93.8%（標記為額外人工審查）
  • 評分最高的語言（西班牙語）：98.1%
  • 需要人工更正的頁面：總頁面的 4.2%

這與花費 4 小時每頁的專業人工翻譯一樣好？不。它是 95% 一樣好，成本是 2%？絕對。

實施：代碼實際如何運作

讓我展示你實際的架構。我們在 Next.js 上使用 next-intl 構建多語言網站，它處理路由、訊息格式設定和區域設定偵測。

項目結構

/messages
  /en.json
  /es.json
  /ja.json
  /ko.json
  /de.json
  ... (30 個總計)
/src
  /app
    /[locale]
      /layout.tsx
      /page.tsx
      /products/page.tsx
  /i18n
    /request.ts
    /routing.ts

next-intl 中間件配置

// src/middleware.ts
import createMiddleware from 'next-intl/middleware';
import { routing } from './i18n/routing';

export default createMiddleware(routing);

export const config = {
  matcher: ['/', '/(de|es|fr|ja|ko|zh|ar|pt|ru|hi|th|vi|id|ms|tl|tr|pl|nl|sv|da|no|fi|cs|el|he|hu|ro|uk|bg|hr)/:path*']
};

// src/i18n/routing.ts
import { defineRouting } from 'next-intl/routing';

export const routing = defineRouting({
  locales: [
    'en', 'es', 'fr', 'de', 'ja', 'ko', 'zh', 'ar', 'pt', 'ru',
    'hi', 'th', 'vi', 'id', 'ms', 'tl', 'tr', 'pl', 'nl', 'sv',
    'da', 'no', 'fi', 'cs', 'el', 'he', 'hu', 'ro', 'uk', 'bg', 'hr'
  ],
  defaultLocale: 'en',
  localePrefix: 'as-needed'
});

批量翻譯指令碼

這是魔法發生的地方。我們寫了一個 Node.js 指令碼，讀取英文 JSON 文件並通過 Anthropic API 翻譯它：

// scripts/translate-batch.ts
import Anthropic from '@anthropic-ai/sdk';
import fs from 'fs/promises';
import path from 'path';

const client = new Anthropic();

const LANGUAGES = {
  es: 'Spanish (Latin American)',
  ja: 'Japanese',
  ko: 'Korean',
  de: 'German',
  // ... 所有 30 個
};

async function translateMessages(
  sourceMessages: Record<string, any>,
  targetLang: string,
  langName: string
) {
  const prompt = `You are a professional website translator. Translate the following JSON from English to ${langName}.

Rules:
- Maintain all JSON keys exactly as-is (English keys, translated values)
- Preserve all {variables} in curly braces without translating them
- Maintain the tone: professional but approachable (B2B industrial equipment)
- For technical terms (CNC, ISO, API), keep them in English
- Adapt idioms naturally, don't translate literally
- Output valid JSON only, no explanations

${JSON.stringify(sourceMessages, null, 2)}`;

  const response = await client.messages.create({
    model: 'claude-haiku-20250401',
    max_tokens: 8192,
    messages: [{ role: 'user', content: prompt }]
  });

  const content = response.content[0];
  if (content.type === 'text') {
    return JSON.parse(content.text);
  }
  throw new Error('Unexpected response format');
}

async function main() {
  const enMessages = JSON.parse(
    await fs.readFile('messages/en.json', 'utf-8')
  );

  for (const [code, name] of Object.entries(LANGUAGES)) {
    console.log(`Translating to ${name}...`);
    const translated = await translateMessages(enMessages, code, name);
    await fs.writeFile(
      path.join('messages', `${code}.json`),
      JSON.stringify(translated, null, 2)
    );
    console.log(`✅ ${name} complete`);
    // 速率限制暫停
    await new Promise(r => setTimeout(r, 2000));
  }
}

main().catch(console.error);

翻譯文件結構

我們的英文源文件看起來像這樣：

{
  "homepage": {
    "hero": {
      "title": "Industrial Equipment for Global Markets",
      "subtitle": "Trusted by {count} manufacturers in {countries} countries",
      "cta": "Request a Quote"
    },
    "features": {
      "quality": {
        "title": "ISO 9001 Certified",
        "description": "Every component meets international quality standards."
      }
    }
  },
  "navigation": {
    "products": "Products",
    "about": "About Us",
    "contact": "Contact"
  }
}

和日文輸出：

{
  "homepage": {
    "hero": {
      "title": "グローバル市場向け産業機器",
      "subtitle": "{countries}カ国の{count}社以上のメーカーに信頼されています",
      "cta": "見積もりを依頼する"
    },
    "features": {
      "quality": {
        "title": "ISO 9001認証取得",
        "description": "すべての部品が国際品質基準を満たしています。"
      }
    }
  },
  "navigation": {
    "products": "製品",
    "about": "会社概要",
    "contact": "お問い合わせ"
  }
}

注意 {count} 和 {countries} 變數如何被保留。文化適應是微妙但重要的 -- 日文商務溝通更正式，Claude Haiku 自然地處理這一點。

hreflang 標籤以進行 SEO

這是關鍵。沒有適當的 hreflang 標籤，Google 不知道要向哪些用戶顯示哪個版本。我們自動生成這些：

// src/app/[locale]/layout.tsx
import { routing } from '@/i18n/routing';

export function generateMetadata({ params: { locale } }) {
  const alternates = {
    languages: Object.fromEntries(
      routing.locales.map(l => [
        l,
        l === routing.defaultLocale ? '/' : `/${l}`
      ])
    )
  };

  return {
    alternates,
    // ... 其他元數據
  };
}

我們已廣泛撰寫了 hreflang 實施 -- 弄錯可能會對你的國際 SEO 造成傷害，而不是幫助。

何時不應該使用這種方法

我想在這裡誠實。我們的方法對每種情況都不完美。

如果以下情況，請勿使用：

  • 你的內容每天都在改變。 如果你是一個新聞網站每天發佈 50 篇文章用 30 種語言，你需要 Weglot 或類似的實時解決方案。我們的批量方法適用於內容相對穩定的網站。
  • 你需要法律/醫療準確性。 對於法律合同、醫療信息或財務披露，你需要認證的人工翻譯人員。句號。LLM 翻譯在法律上不具約束力。
  • 你沒有開發者。 我們的方法需要有人熟悉 Next.js、JSON 文件和 API 指令碼。Weglot 的優勢是行銷人員可以設置它。
  • 你在 WordPress 上並停留在那裡。 如果你不會離開 WordPress，WPML 與翻譯服務插件是你最好的選擇。儘管我真心建議首先考慮 headless CMS 遷移。

這種方法在以下情況下閃耀：

  • 你有 50-500 頁相對穩定的內容
  • 你用 Next.js 或 Astro 構建
  • 你需要 5+ 種語言（成本節省在大規模時變得戲劇性）
  • 你想擁有你的翻譯資產
  • 你是一個重視自主權而非便利性的有成本意識的團隊

常見問題

Claude Haiku 與 GPT-4 的翻譯效果如何比較？

我們廣泛測試了兩者。GPT-4 為文學或細微差別的行銷文案產生略微更好的翻譯 -- 品質評分可能高 1-2%。但 Claude Haiku 便宜 85%，足夠快進行批量處理。對於運行品質檢查的網站翻譯，Haiku 是更好的價值。GPT-4o-mini 在價格上具有競爭力，但我們發現其對亞洲語言（特別是日語和韓語）的處理略差於 Haiku。

如何處理阿拉伯語和希伯來語等從右到左的文本的語言？

next-intl 使用 dir 屬性優美地處理 RTL。你根據區域設定在佈局中設置它，Tailwind CSS 的 rtl: 變體處理樣式。阿拉伯語的翻譯品質實際上是我們更強的結果之一 -- 96.4% Winston 評分。希伯來語達到 95.1%。關鍵是在你的翻譯提示中包含 RTL 特定說明。

當頁面改變時，你如何處理翻譯更新？

我們只針對改變的鍵重新運行批量指令碼。我們的 CI 管道將英文 JSON 與最後翻譯的版本進行差異比較，只將新的或修改的字符串發送到 API。一次典型的月度更新在 30 種語言上翻譯 20-50 個字符串 -- 總費用約 $2-3。這保持第 2 年及以後的成本對大多數網站實際上為零。

$22 每種語言真的准確嗎？有什麼隱藏成本嗎？

分解：118 頁平均每頁 800 字 = 約 94,400 字。以 Claude Haiku 的定價大約 $0.25 每 1M 輸入代幣和 $1.25 每 1M 輸出代幣（2025 年費率），翻譯 94K 字對每種語言成本約 $18-22，取決於目標語言的代幣密度。日語和中文每個概念使用更少代幣，而德語使用更多。我們四捨五入到 $22 作為安全平均值。Winston AI 品質檢查在所有語言中增加約 $15 總計。所以如果你想精確的話，稱之為 $675。

關於多語言網站的 SEO 怎樣？翻譯的頁面會排名嗎？

絕對。我們客戶的韓文和日文頁面在部署後 6 週內開始排名。關鍵因素：適當的 hreflang 標籤、翻譯的 URL slug（不只是 /ja/products 但 /ja/製品（如果合適）、翻譯的元標題和描述，以及在區域設定特定子資料夾上託管而不是單獨域。Next.js 與 next-intl 的路由配置本地處理所有這些。Google 的 John Mueller 確認了 AI 翻譯的內容很好，只要它對用戶有幫助。

我可以用 Astro 而不是 Next.js 使用這種方法嗎？

可以。Astro 自 Astro 4.0 起具有內置 i18n 路由，批量翻譯指令碼與框架無關 -- 它只生成 JSON 文件。我們已經使用 Astro 項目 用 Astro 的 getStaticPaths() 在構建時生成所有區域設定變體。實際上，Astro 的靜態生成使其更高效，因為沒有運行時翻譯成本。

我應該以 Winston AI 為目標什麼品質評分？

我們設置了 95% 的閾值。低於此，頁面被標記為人工審查。實際上，只有大約 4% 的頁面低於 95%。如果你在受管制行業，推至 97% 並預算更多人工審查。對於電子商務產品描述，其中「足夠好」確實足夠好，你可以降至 90% 並節省人工審查成本。評分有點主觀，所以首先根據你自己的母語使用者校準。

這與只在 Fiverr 或 Upwork 上雇傭翻譯人員相比如何？

我們也定價過了。Upwork 上的專業翻譯人員對網站內容收費 $0.05-0.15 每字。在 94,400 字 × 30 種語言，那是 $141,600-$425,000。甚至 Fiverr 上的預算翻譯人員以 $0.03/字來 $84,960。而且你仍然需要一個開發者將翻譯集成到你的網站。我們的方法便宜 99.5%，品質評分為 95%+。差距是驚人的，這是為什麼我們認為每個機構都應該採納這種方法。如果你想討論你特定項目的實施，聯繫我們 -- 我們很樂意分享更多關於工具鏈的詳細信息。

這適用於具有數千個 SKU 的動態內容（如產品目錄）嗎？

對於真正動態的內容 -- 像從數據庫生成的 91K 產品頁面 -- 你需要一個混合方法。用批量方法翻譯你的 UI 字符串和模板內容（$660），然後在產品管道中將相同的 Claude Haiku 指令碼用作翻譯步驟。我們通常將其設置為 CMS webhook 中的翻譯步驟：當英文中的產品被創建或更新時，它自動為所有 30 種語言隊列翻譯。每個產品的成本是微不足道的 -- 分數分 -- 它非同步運行，所以它不會減慢內容發佈。