UAIX Translation and Localization Audit

Full report

On this page

Executive Summary

UAIX publicly exposes five locale surfaces—en-us, zh-cn, es-us, fr-fr, and es-es—and declares English (US) as the default locale in the sitemap. robots.txt does not block normal crawling beyond /wp-admin/, so there was no robots-based obstruction to a public audit. The main crawl limitation was different: the locale XML sitemap endpoints were referenced by the site, but the audit tool could not reliably retrieve them, so this review relied on the root and locale HTML sitemaps, plus direct inspection of public pages and search-indexed pages.

The highest-risk localization defect is structural, not cosmetic: the localized HTML sitemaps for fr-fr, es-es, zh-cn, and es-us are supposed to surface the same public inventory through locale-prefixed route space, but in practice they point many entries back to /en-us/... URLs. This directly contradicts the site’s own tooling guidance, which says locale-prefixed sitemap routes should resolve the same inventory for localized readers and tooling. In other words, discovery is broken before translation quality is even assessed.

Beyond routing, every non-English locale shows material quality problems. es-us behaves like a shadow locale with English copy on Spanish-prefixed routes. fr-fr and es-es are partially translated: navigation and some introductory copy are localized, but major schema, example, sitemap, news, metadata, sidebar, and footer strings remain English. zh-cn is the worst surface: besides untranslated English fragments, it contains repeated placeholder-like Chinese text such as 公开记录项 and 此处说明当前公开记录、证据路径和支持边界。, plus awkward or likely machine-translated terminology such as 工装, 主要刀具路径, and 小路.

There is also a source-language quality issue that will contaminate any downstream translation workflow unless fixed first: on the English schemas page, multiple entries for uaix.ability-profile.l2.v1 through uaix.ability-profile.l5.v1 are all mislabeled as “UAIX Ability Profile L6 v1.” This is not a translation error; it is a source-record defect. If left untouched, translators and locale QA will propagate incorrect labels.

The remediation priority should therefore be: fix locale discovery and route mapping first; fix source English defects second; then clean shared templates, metadata, and sidebars; then do a full page-by-page locale sweep with enforced CI and human review.

Crawl Scope and Discovery Inventory

The root HTML sitemap states that UAIX publishes five locale sitemap surfaces, and the English HTML sitemap states “Coverage 179 public URLs.” The same 179-URL coverage claim appears on the fr-fr, es-es, and es-us HTML sitemaps. The public site is clearly WordPress-backed, based on robots.txt rules for /wp-admin/ and the site’s use of /wp-json/uaix/v1/... routes. Repo access was unspecified, so this audit is limited to public HTML, public REST routes, public sitemap surfaces, and search-indexed page variants.

The English sitemap exposes the site’s public page families. The discovered corpus includes the home page and onboarding pages; the AI Memory cluster; specification pages; guides; about/reference/contact pages; compatibility and capability pages; evaluation packet pages; standards pages; schema and registry families; implementations; tools; reports; governance; press; the news archive; and a long list of individual news entries. Representative route families visible in the HTML sitemap include /en-us/ai-memory/..., /en-us/spec/..., /en-us/guides/..., /en-us/about/..., /en-us/evaluation-packets/..., /en-us/standards/..., /en-us/registry/..., /en-us/implementations/..., /en-us/tools/..., /en-us/reports/..., /en-us/governance/..., and /en-us/news/, followed by named news entry routes.

A notable content-quality issue surfaced during inventory: the English sitemap still lists a generic “Sample Page” at /en-us/sample-page/, and non-English sitemaps surface that same route as well. That page contains stock WordPress sample copy and should either be removed from public discovery or intentionally localized and justified.

The locale selector is also functionally ambiguous. The public header shows English 简体中文 Español Français Español, while the sitemap distinguishes both es-US and es-ES. Because the switcher shows two identical “Español” options without regional labels, users cannot tell which Spanish variant they are choosing.

Localization Findings

The matrix below is a heuristic completeness estimate based on the public DOM inspected during this audit. It is not a repo-level key count, because translation keys, locale files, and storage locations are not publicly exposed. A score of 100 means “no obvious localization leak in the sampled visible UI”; lower scores reflect increasing English fallback, placeholder leakage, wrong-route linking, or likely machine translation.

Two short DOM excerpts capture the overall pattern.

The French schemas page is visibly mixed-language in a single section.

Jump to section
Published UAI-1 schemas
Open schema JSON
Open example JSON

The Chinese sitemap shows a broken placeholder pattern that has escaped into production.

# 公开记录项
此处说明当前公开记录、证据路径和支持边界。

A second structural contradiction matters for SEO and machine readers. UAIX’s Tools page explicitly says localized readers and tooling should be able to resolve the same page inventory through locale-prefixed sitemap routes, but the localized sitemaps themselves repeatedly output English-route paths such as /en-us/, /en-us/get-started/, and /en-us/ai-memory/. That means locale discovery is misleading for both crawlers and users.

The metadata pipeline is also inconsistent. Search-indexed French pages such as /fr-fr/examples/, /fr-fr/tools/, and /fr-fr/schemas/ surfaced with page titles like “Exemples | UAIX | 通用人工智能交换” and “Outils | UAIX | 通用人工智能交换”, which mixes French page titles with a Chinese site-name fragment. That is a cross-locale metadata leak, not merely a missing body translation.

Missing Strings and Suspect Resource Gaps

Because the public site does not expose translation key IDs, message catalogs, or repository file paths, exact internal key names are mostly unspecified. Publicly, the best-mappable “locations” are the route, template area, and DOM block where the issue appears. The evidence strongly suggests that many problems live in shared WordPress page templates or CMS-authored page bodies rather than in a single clean locale-resource system.

Several broader resource-level gaps are observable even without repo access. First, locale resources are clearly incomplete or misapplied: the same English helper labels reappear across multiple non-English page families, which points to shared template strings that were never translated or never bound to locale resources. Second, es-us appears to have routes without effective Spanish resource application. Third, zh-cn shows evidence of placeholder injection and unreviewed machine translation in shared UI labels, which is worse than simple incompleteness because it creates false confidence.

Pluralization and formatting are also weak. GNU gettext documentation correctly treats localization as more than message translation, including date/time, number, and currency conventions. On UAIX, French metadata still shows English forms like Published April 21, 2026 and Part of a 18-source build record, while Chinese news sidebars still expose English month labels like May 2026 and April 2026. Those are visible signs that locale-aware formatting and plural logic are either missing or bypassed in some templates. Currency formatting could not be meaningfully tested because no public monetary UI was encountered in the sampled pages, so currency support is unspecified from the public surface alone.

Right-to-left support is effectively absent from the public site. The published locale surfaces are only en-us, zh-cn, es-us, fr-fr, and es-es, and no sampled pages surfaced any visible rtl marker. That does not prove the codebase cannot support RTL, but it does mean public RTL support is unpublished and unverified.

Reproducible Detection and CI Pipeline

The most reliable public starting point is the root HTML sitemap, not the locale XML sitemap endpoints, because the public audit tool could inspect the HTML surfaces consistently while locale XML fetches failed. The commands below are therefore designed to crawl the HTML sitemaps first, then inspect locale pages for wrong-prefix links, English leakage, placeholders, and broken metadata.

#!/usr/bin/env bash
set -euo pipefail

BASE="https://uaix.org"
LOCALES=(en-us fr-fr es-es zh-cn es-us)

mkdir -p audit

echo "== robots =="
curl -fsSL "$BASE/robots.txt" | tee audit/robots.txt

echo
echo "== root sitemap =="
curl -fsSL "$BASE/sitemap.html" -o audit/root-sitemap.html

for locale in "${LOCALES[@]}"; do
  url="$BASE/$locale/sitemap.html"
  out="audit/$locale-sitemap.html"

  echo
  echo "== $locale =="
  curl -fsSL "$url" -o "$out"

  # Extract any locale-like paths that appear in the HTML.
  grep -oE '/[a-z]{2}-[a-z]{2}/[^" <]+' "$out" | sort -u > "audit/$locale-paths.txt" || true

  echo "paths found: $(wc -l < "audit/$locale-paths.txt" | tr -d ' ')"

  echo "-- wrong-prefix links (should be empty for non-en locales) --"
  grep -n '/en-us/' "$out" | sed -n '1,40p' || true

  echo "-- suspicious untranslated or placeholder strings --"
  grep -nE 'Jump to section|Published UAI-1 schemas|Open schema JSON|Search|Archives|May 2026|April 2026|公开记录项|此处说明当前公开记录、证据路径和支持边界。' "$out" \
    | sed -n '1,80p' || true
done

For browser-level verification, Playwright is a strong fit because it supports browser automation across Chromium, Firefox, and WebKit. The script below renders representative locale routes, pulls visible text, flags suspect English strings on non-English routes, and checks whether locale pages still contain too many /en-us/ links.

// audit-locale-pages.mjs
// Usage: node audit-locale-pages.mjs
import fs from "node:fs/promises";
import { chromium } from "playwright";

const pages = [
  "https://uaix.org/en-us/sitemap.html",
  "https://uaix.org/fr-fr/sitemap.html",
  "https://uaix.org/es-es/schemas/",
  "https://uaix.org/fr-fr/schemas/",
  "https://uaix.org/fr-fr/examples/",
  "https://uaix.org/zh-cn/tools/",
  "https://uaix.org/zh-cn/uaix-adoption-packet-and-sitemap-surface-update/",
  "https://uaix.org/es-us/memory-firewall/"
];

const blockedOnLocalizedPages = [
  "Jump to section",
  "Published UAI-1 schemas",
  "Published keyless field-order registry",
  "Open schema JSON",
  "Open example JSON",
  "Search",
  "Archives",
  "May 2026",
  "April 2026",
  "公开记录项",
  "此处说明当前公开记录、证据路径和支持边界。"
];

function localeOf(url) {
  const match = url.match(/https:\/\/uaix\.org\/([a-z]{2}-[a-z]{2})\//i);
  return match ? match[1].toLowerCase() : "root";
}

const browser = await chromium.launch({ headless: true });
const page = await browser.newPage();

const results = [];

for (const url of pages) {
  const locale = localeOf(url);

  try {
    await page.goto(url, { waitUntil: "networkidle", timeout: 30000 });

    const title = await page.title();
    const bodyText = await page.locator("body").innerText();
    const hrefs = await page.$$eval("a[href]", nodes => nodes.map(n => n.getAttribute("href") || ""));

    const leakedStrings =
      locale === "en-us" || locale === "root"
        ? []
        : blockedOnLocalizedPages.filter(s => bodyText.includes(s) || title.includes(s));

    const wrongPrefixLinks =
      locale === "en-us" || locale === "root"
        ? []
        : hrefs.filter(h => h.includes("/en-us/"));

    results.push({
      url,
      locale,
      title,
      leakedStrings,
      wrongPrefixLinkCount: wrongPrefixLinks.length,
      sampleWrongPrefixLinks: wrongPrefixLinks.slice(0, 10)
    });
  } catch (error) {
    results.push({
      url,
      locale,
      error: String(error)
    });
  }
}

await browser.close();
await fs.writeFile("uaix-locale-audit.json", JSON.stringify(results, null, 2), "utf8");
console.log("Wrote uaix-locale-audit.json");

If repository access becomes available later, use framework-native extraction and catalog validation instead of trying to infer everything from rendered HTML. For i18next projects, note that the old i18next-parser is now archived/deprecated; i18next’s own documentation now recommends the official i18next-cli for extraction, locale sync, linting, and type generation. For gettext projects, msgcmp compares catalogs against the template, msgattrib --untranslated isolates missing work, and msgfmt validates PO syntax and format strings.

# gettext-based catalog QA
msgcmp locales/fr_FR.po messages.pot
msgcmp locales/es_ES.po messages.pot
msgcmp locales/zh_CN.po messages.pot

msgattrib --untranslated locales/fr_FR.po > audit/fr_FR.untranslated.po
msgattrib --untranslated locales/es_ES.po > audit/es_ES.untranslated.po
msgattrib --untranslated locales/zh_CN.po > audit/zh_CN.untranslated.po

msgfmt --check-format -o /dev/null locales/fr_FR.po
msgfmt --check-format -o /dev/null locales/es_ES.po
msgfmt --check-format -o /dev/null locales/zh_CN.po

flowchart LR
  A[Author changes source copy or UI] --> B[Pre-commit hook]
  B --> C[Extract keys and diff catalogs]
  C --> D[Reject new raw strings in localized templates]
  D --> E[CI crawl of public and preview routes]
  E --> F[Check locale-prefixed sitemap links]
  F --> G[Check placeholders and English leakage]
  G --> H[Check date, number, and metadata formatting]
  H --> I[Playwright DOM and visual regression]
  I --> J[Native-speaker review]
  J --> K[Release gate]
  B --> X[Fail commit]
  E --> Y[Fail CI]
  K --> Z[Deploy]

Strict Translation Governance and QA

A safe workflow here must be explicit: source English is authoritative only after it passes content QA, and no non-English locale may ship automatically from source diffs or machine translation alone. That matters especially on UAIX because at least one English source defect is already visible in production on the schemas page.

What counts as cheating in this project should be written into policy and enforced in CI:

• Shipping English fallback strings on a non-English route, except for an approved glossary of product names, standard identifiers, code literals, and API/profile names.
• Adding a locale route but leaving the body effectively in English, as seen on es-us.
• Auto-accepting machine translation without human review.
• Shipping placeholder content such as TODO, lorem ipsum, 公开记录项, or 此处说明当前公开记录、证据路径和支持边界。
• Translating only the hero/body copy while leaving metadata, breadcrumbs, sidebars, search widgets, archive labels, sitemap text, and footer text in English.
• Letting localized sitemaps point to the default-language routes.
• “Fixing” missing translations by changing the source copy to a vaguer phrase instead of translating it.

Enforcement cannot rely on local hooks alone. Git’s documented pre-commit hook can stop bad commits, but it can also be bypassed with git commit --no-verify, so protected-branch CI checks must be mandatory. A pre-commit framework is still worthwhile for fast local feedback, but it is not the final gate.

A production-grade QA checklist for UAIX should require all of the following before release:

• Source copy approved by the standards/content owner.
• Extracted catalogs synchronized with no missing additions for all supported locales.
• Zero blocked placeholder strings on locale routes.
• Zero non-approved English helper labels on locale routes.
• Locale sitemap routes matching the locale prefix for that locale.
• <title>, breadcrumbs, on-page headings, search widgets, archives, month labels, and footer content localized.
• Locale-aware date and number formatting in user-facing UI.
• Human review by a native or professionally fluent reviewer for fr-FR, es-ES, and zh-CN.
• Visual or DOM regression tests passing for all supported locales.
• Release notes including locale QA sign-off and any intentionally untranslated glossary terms.

Acceptance should be binary, not aspirational: if one public locale is supported, it must be supportable end to end. If es-US cannot be translated and reviewed, it should be unpublished or hidden until it can.

Prioritized Remediation Plan

A realistic first pass to make the multilingual site credible again is roughly 68–114 hours before the full corpus sweep, assuming one platform engineer, one localization engineer, one QA automation engineer, and native reviewers in French, Spanish, and Chinese. The larger 179-URL sweep will add material review time beyond that.

Open Questions and Limitations

This audit was public-surface only. Repository access, CMS access, and locale-file access were unspecified, so exact internal translation key IDs, file names, and storage paths are mostly unavailable from the evidence gathered here. Public route locations and template areas were therefore used instead.

The locale XML sitemap URLs were announced by the site, but the audit tool could not directly retrieve those locale XML endpoints; the review therefore relied on the root and locale HTML sitemaps, direct page inspection, and search-indexed public pages. robots.txt itself did not prevent crawling.

Currency formatting and true RTL rendering could not be functionally tested from the public pages sampled, because no public monetary UI and no RTL locale were found. Their status is therefore unspecified rather than confirmed absent. The visible evidence still supports a firm conclusion: UAIX’s current multilingual publication is not release-grade, and it should not be treated as such until routing, shared templates, placeholders, and review enforcement are fixed.