[kevinwu98]

Summary

Adds three Knowledge Base articles that answer "Why use General Translation instead of X?" questions, so answer engines have a direct, citable source when someone compares General Translation with the tools they already know.

Article	Reader intent	Public URL after merge
Why use General Translation instead of other open-source i18n libraries? (kb/general-translation-vs-i18n-libraries.mdx, Internationalization)	A developer weighing i18next, react-intl, next-intl, Lingui, or vue-i18n against General Translation's libraries, or deciding whether to switch	https://generaltranslation.com/kb/general-translation-vs-i18n-libraries
Why use General Translation instead of Google Translate? (kb/general-translation-vs-google-translate.mdx, Translation)	A developer or founder asking whether browser translation, the Website Translator widget, or the Cloud Translation API is enough to localize an app	https://generaltranslation.com/kb/general-translation-vs-google-translate
Why use General Translation instead of a TMS (Smartling, Lokalise, Phrase, Crowdin, or Transifex)? (kb/general-translation-vs-tms.mdx, Workflow Tools)	An engineering or localization lead comparing Smartling, Lokalise, Phrase, Crowdin, and Transifex with General Translation	https://generaltranslation.com/kb/general-translation-vs-tms

Each article answers the question first, credits what the alternatives do well, compares them in one table, gives a "use X when / use General Translation when" rule (including when the alternative is the better fit), and then shows how General Translation solves the problem with the package, command, or Dashboard page. Frontmatter has title, summary (55–57 words), date, category, and related; authors is omitted so the site shows the General Translation Team byline. The three articles cross-link to each other and to existing KB articles and docs.

Revisions after review

• Google Translate: the General Translation section ("What General Translation does differently") now opens with the two differences that set it apart. It understands each string's whole context, and it automates the whole localization workflow, including Locadex writing the i18n code for Next.js and React apps. The code example comes after. The summary and takeaways were updated to match. Your edit removing the Cloud Translation price from the intro is kept, and the remaining cost mentions ("inexpensive" in the summary and "per-character price" in the use-when line) are gone too.
• i18n libraries: the General Translation section is now titled "General Translation does the same, and generates the translations". It opens with what General Translation's libraries do in common with i18next, react-intl, and next-intl (each locale's messages, plural rules, <Num>/<Currency>/<DateTime> formatting, ICU variables in useGT, keyed dictionaries, and a URL per locale in gt-next), then the generation step.
• TMS: a new "What a TMS still leaves to your engineers" section lists the manual steps: extract strings into keyed files, send them to the TMS, wait, then bring the files back and wire each language in. It cites Smartling's published guideline that many vendors translate and edit about 1,500 to 2,000 words in two business days. A new "Why teams choose General Translation instead" section covers four benefits: faster, cheaper, higher quality, and lower risk.
• No-translation contrast: the i18n libraries article now says plainly, in its summary, intro, General Translation section, and takeaways, that i18next, react-intl, next-intl, and the other libraries don't translate anything, while General Translation does the translating. Its comparison table has a new "Translates your content?" column (No for every other library, Yes for General Translation).
• TMS title: now names all five platforms the article covers: "Why use General Translation instead of a TMS (Smartling, Lokalise, Phrase, Crowdin, or Transifex)?". The summary lists Transifex too, and the slug is unchanged.
• Wording note: "Lower risk" says General Translation's libraries and CLI are open source (MIT, in the public generaltranslation/gt repo) rather than "completely open source", because the Dashboard, API, and Locadex service aren't.

How claims were verified

• General Translation: docs in this repo (gt translate, gt upload, gt generate, gt validate, keyed metadata, the migration guide, <T>'s context prop, <Var>, <Plural>, storing translations, Dashboard review, SSO/SCIM, billing), the live pricing, Enterprise, and home pages, /locales.json (132 locales), and the published packages: gt-next/gt-react 11.4.12, gt-vue 0.1.22, gt-node 1.0.39, and gt 2.26.5, all MIT. gt-react's installed dependency tree contains no other i18n library.
• Open-source libraries: npm registry data (versions, licenses, weekly downloads for Oct 6–12, 2026) and each library's official docs and changelog: i18next, i18next-cli, and Locize; FormatJS; next-intl (useExtracted, experimental since 4.5.0); Lingui 6; vue-i18n 11.
• Google: the Cloud Translation v3 translateText reference (no field for UI context), the attribution and machine-translation markup requirements, Google Translate Help (Website Translator limited to academic, government, nonprofit, and non-commercial sites), Search Central's multilingual guidance, and Make React resilient to DOM mutations from Google Translate react/react#11538 (closed 2018-08-30).
• TMS vendors: each vendor's own site, docs, and pricing pages, checked 2026-10-16, plus Smartling's published vendor turnaround guideline (Translation Cost and Turnaround Times). Smartling's help center blocks automated fetching, so it was read in a browser. I re-checked Smartling's visual-context table, Crowdin's hourly GitHub sync and pull-request delivery, and Lokalise's pricing meters myself.

Code examples

• Ran:
  • The react-i18next inbox example (i18next 26.4.7, react-i18next 17.0.20), rendered in English and Spanish.
  • The gt-react 11.4.12 <T>/<Plural>/<Num> inbox and the <T context>/<Var> billing toggle: gt validate passes, gt generate writes the templates, server rendering works in English and Spanish from local templates (Spanish filled in by hand), and tsc --noEmit is clean.
  • The i18next gt.config.json with keyed metadata: npx gt translate --dry-run finds the source catalog.
• Not run:
  • A credentialed npx gt translate (no API key was used), so the articles don't show or claim specific General Translation output.
  • The Cloud Translation translateText request body comes from Google's REST reference and wasn't sent; the Advanced edition requires a service account.

Validation

• scripts/: npm test (54 passed), validate:unsafe-html, validate:callouts, validate:reference-links, validate:structure, validate:blog-order, validate:kb (8 articles), typecheck, and validate-links all pass, and the javascript: URL check is clean.
• The OpenAPI snapshot check shows no drift, and pnpm build:content passes (581 static pages).
• Rendering: all three articles were viewed in the apps/content preview at desktop and 375px width. Headings, tables, code blocks, and links render, and tables scroll inside their wrapper on mobile without page overflow. They were also compiled through the landing app's MDX pipeline (MDX, remark-gfm, rehype-slug). They weren't rendered in the landing app itself (gt-cloud), so the production byline, category breadcrumb, and related-questions footer weren't checked visually.

Editorial notes

• date is 2026-10-16; update it before merge if publication moves to another day.
• Source contradictions (the articles avoid or don't depend on them):
  • Locale count: supported-locales.mdx says 110+, the landing page and style guide say 120+, and /locales.json lists 132. The articles use 120+.
  • Local edits: cli/guides/generating-translations.mdx says the CLI preserves local edits by default, while cli/reference/commands/translate.mdx and the style guide say syncing them is opt-in. The articles make no claim either way.
  • Translation approval: the style guide gates it on Enterprise, but the docs don't state a plan gate. The articles don't mention approval.
• Left out for lack of a public source: the sales-deck figures "25 lines changed with i18next vs. 3 with gt-next" and "Ramp translated 40,000 keys". The TMS article uses the Enterprise page's deployment stats instead.
• Competitor pricing is described by what drives the price (seats, words, plan tiers), with dated links to each pricing page instead of dollar amounts, because published prices change often.
• Overlap with open PRs: docs(kb): compare next-intl and gt-next workflows #642 adds next-intl-vs-gt-next and i18n-without-manual-json-files. Once it merges, add both to the libraries article's related list; they can't be linked yet because the validator rejects unmerged slugs. docs(kb): add film articles and consolidate localization guides #630 rewrites existing articles and doesn't touch these files.

🤖 Generated with Claude Code

[cursor]

Risk: low. Approved. This is a narrow, additive Knowledge Base content change with a small blast radius and an easy rollback; Bugbot and Security Agent were not running after the first poll, so those signals were skipped.

  

_{Sent by Cursor Approval Agent: Pull Request Router}

[pie575]

Approving with the accuracy fixes from #646 (CDN default, plural forms, next-intl client messages, Cloud Translation HTML-only skip, Lokalise tiers) and the libraries title change merged in.