@startsimpli/ui 0.4.102 → 0.4.103

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@startsimpli/ui",
-  "version": "0.4.102",
+  "version": "0.4.103",
   "description": "Shared UI components package for StartSimpli applications",
   "main": "./src/index.ts",
   "types": "./src/index.ts",
@@ -44,9 +44,9 @@
     "next": "^14.0.0 || ^15.0.0 || ^16.0.0",
     "react": "^18.0.0 || ^19.0.0",
     "react-dom": "^18.0.0 || ^19.0.0",
+    "@startsimpli/api": "^0.5.56",
     "@startsimpli/auth": "^0.4.35",
-    "@startsimpli/i18n": "^0.1.3",
-    "@startsimpli/api": "^0.5.56"
+    "@startsimpli/i18n": "^0.1.3"
   },
   "peerDependenciesMeta": {
     "@startsimpli/api": {

package/src/components/validation/__tests__/word-count-scripts.test.ts

@@ -0,0 +1,114 @@
+/**
+ * Counting words in a language that does not use spaces (bd startsim-wn2p.28).
+ *
+ * OBSERVED in the browser on the live OGMC Chinese draft, 2026-08-24. The review
+ * workspace greeted its reviewer with "4 ISSUES TO LOOK AT" and CHECKS 4/8, and
+ * three of the four were arithmetic, not editing:
+ *
+ *   Headline length      1 words    (the headline is 19 Chinese characters)
+ *   Blog word count     16 words    (the blog is 855 Chinese characters)
+ *   LinkedIn word count  7 words    (the post is 364 Chinese characters)
+ *
+ * `split(/\s+/)` counts whitespace runs. Chinese does not put spaces between
+ * words, so an entire article counted as however many Latin fragments happened
+ * to be embedded in it. The rail whose job is to say what to fix was saying
+ * nothing at all, on exactly the language the CN review stage exists for.
+ *
+ * MEASURED against the three real translation pairs in the tenant — whitespace
+ * count vs `Intl.Segmenter`, with the English source's count for scale:
+ *
+ *   zh #1  headline  EN  9   ws  1   segmented 13
+ *          blog      EN 507  ws 26   segmented 609
+ *          linkedin  EN 190  ws 11   segmented 234
+ *   zh #2  headline  EN  8   ws  1   segmented 11
+ *          blog      EN 463  ws 16   segmented 524
+ *   ar     blog      EN 497  ws 479  segmented 476   <- Arabic already worked
+ *
+ * So segmentation turns nonsense into a number an editor can act on, and leaves
+ * space-delimited scripts where they were.
+ */
+import { wordCount } from '../checks';
+
+// The opening of the live zh blog (draft f6a2d629), not invented text.
+const ZH_BLOG =
+  '来自《Arabian Business》的报道显示，海湾—亚洲技术走廊正进入新阶段，' +
+  '中国企业正从单纯投资转向在GCC范围内更深度嵌入的运营模式。';
+const ZH_HEADLINE = '中国—海湾科技扩张引发入局者对执行的疑问';
+const EN_HEADLINE = 'China-Gulf Tech Expansion Raises Execution Questions for Entrants';
+const AR_HEADLINE = 'يتطلب تأسيس الشركات بشكل أسرع في دبي تنفيذًا دقيقًا من قبل الأجانب';
+
+describe('wordCount on space-delimited scripts — unchanged', () => {
+  it('counts an English headline', () => {
+    expect(wordCount(EN_HEADLINE)).toBe(9);
+  });
+
+  it('counts an Arabic headline, which was never broken', () => {
+    // Arabic uses spaces, so this was already right and must stay right:
+    // whitespace gave 12 on this live headline and segmentation gives 12.
+    expect(wordCount(AR_HEADLINE)).toBe(12);
+  });
+
+  it('splits a hyphenated compound, which whitespace counting did not', () => {
+    // The one real behaviour change for English, and it is a correction:
+    // "China-Gulf" is two words. MEASURED across all 75 live English drafts,
+    // this moves 9 of 225 band checks — and the single headline it flips is
+    // "Qatar's Post-World-Cup Economy...", which whitespace scored 7 (below the
+    // 8-word floor) and segmentation scores 9 (in band). Largest blog shift is
+    // 19 words on a ~450-word brief.
+    expect(wordCount('China-Gulf Tech')).toBe(3);
+  });
+
+  it('is 0 for empty, null and undefined', () => {
+    expect(wordCount('')).toBe(0);
+    expect(wordCount(null)).toBe(0);
+    expect(wordCount(undefined)).toBe(0);
+    expect(wordCount('   ')).toBe(0);
+  });
+
+  it('does not count punctuation as a word', () => {
+    expect(wordCount('Hello, world!')).toBe(2);
+    expect(wordCount('— — —')).toBe(0);
+  });
+});
+
+describe('wordCount on Chinese — the bug', () => {
+  it('no longer reports a 19-character headline as one word', () => {
+    expect(wordCount(ZH_HEADLINE)).toBeGreaterThan(5);
+  });
+
+  it('lands near the English source it was translated from', () => {
+    // The live pair: a 9-word English headline became this. Anything in the
+    // same neighbourhood is a number an editor can reason about; `1` was not.
+    const n = wordCount(ZH_HEADLINE);
+    expect(n).toBeGreaterThanOrEqual(8);
+    expect(n).toBeLessThanOrEqual(20);
+  });
+
+  it('counts a Chinese paragraph as prose, not as its Latin fragments', () => {
+    // The embedded 'Arabian Business' and 'GCC' were nearly the whole old count.
+    expect(wordCount(ZH_BLOG)).toBeGreaterThan(20);
+  });
+
+  it('counts mixed Chinese and Latin without double-counting the Latin', () => {
+    const mixed = 'GCC市场';
+    expect(wordCount(mixed)).toBeGreaterThanOrEqual(2);
+    expect(wordCount(mixed)).toBeLessThanOrEqual(3);
+  });
+});
+
+describe('wordCount degrades rather than throws', () => {
+  it('still returns a count where Intl.Segmenter is unavailable', () => {
+    const saved = (globalThis as { Intl: typeof Intl }).Intl;
+    try {
+      // Older runtimes, and any environment that trims Intl to save bytes.
+      (globalThis as unknown as { Intl: unknown }).Intl = {} as unknown;
+      // The OLD whitespace answer — 8, because it cannot split "China-Gulf".
+      // Degraded but usable, which is the point: a wrong count beats a thrown
+      // error on a rail whose job is to report problems.
+      expect(wordCount(EN_HEADLINE)).toBe(8);
+      expect(wordCount(ZH_HEADLINE)).toBeGreaterThan(0);
+    } finally {
+      (globalThis as { Intl: typeof Intl }).Intl = saved;
+    }
+  });
+});

package/src/components/validation/checks.ts

@@ -139,10 +139,78 @@ const DEFAULTS = {
   metaChars: [150, 160] as Band,
 };
 
-/** Count words in a string — whitespace-delimited, empty → 0. */
-export function wordCount(text: string | null | undefined): number {
+/**
+ * The sliver of `Intl.Segmenter` this file uses, declared locally rather than by
+ * raising the package's `lib` to es2022.
+ *
+ * This package ships raw TypeScript and is compiled by each consuming app, so a
+ * `lib` bump here would not reach them anyway — every tenant app's own tsconfig
+ * would have to agree. A local structural type works whatever they target, and
+ * the runtime guard below is what actually decides whether it is used.
+ */
+interface WordSegment {
+  isWordLike?: boolean;
+}
+interface SegmenterCtor {
+  new (locale?: string, options?: { granularity: 'word' }): {
+    segment(input: string): Iterable<WordSegment>;
+  };
+}
+
+/**
+ * Words that carry meaning, in ANY script. Empty → 0.
+ *
+ * WHY NOT `split(/\s+/)` (bd startsim-wn2p.28). Because Chinese does not put
+ * spaces between words, and OGMC's Chinese review stage was greeted by this:
+ *
+ *   Headline length      1 words    (the headline is 19 Chinese characters)
+ *   Blog word count     16 words    (the blog is 855 Chinese characters)
+ *   LinkedIn word count  7 words    (the post is 364 Chinese characters)
+ *
+ * Whitespace counting was returning the number of Latin fragments that happened
+ * to be embedded in the prose. The rail whose job is to say what to fix was
+ * saying nothing at all, on exactly the language it had just been extended to.
+ *
+ * `Intl.Segmenter` applies ICU's per-locale word rules, and MEASURED against the
+ * three real translation pairs in the tenant it does the right thing in both
+ * directions — it rescues CJK and leaves space-delimited scripts alone:
+ *
+ *   zh  headline  EN   9  |  whitespace   1  |  segmented  13
+ *       blog      EN 507  |  whitespace  26  |  segmented 609
+ *       linkedin  EN 190  |  whitespace  11  |  segmented 234
+ *   ar  blog      EN 497  |  whitespace 479  |  segmented 476
+ *
+ * A NOTE ON THE BANDS, which this function deliberately does not touch. A
+ * faithful Chinese translation of a 507-word English brief segments to ~609
+ * words, so the English 400–500 band still reads it as over-long. That is an
+ * EDITORIAL question — what length OGMC wants a Chinese brief to be — not an
+ * arithmetic one, and `ContentChecksConfig` already takes per-call band
+ * overrides for when they answer it. Fixing the counting without inventing
+ * their policy is the honest half.
+ */
+export function wordCount(text: string | null | undefined, locale?: string): number {
   if (!text) return 0;
-  return text.trim().split(/\s+/).filter(Boolean).length;
+  const trimmed = text.trim();
+  if (!trimmed) return 0;
+  // Guarded rather than assumed: Intl.Segmenter is absent in older runtimes and
+  // in environments that trim Intl to save bytes. Falling back to the old
+  // behaviour is right for the Latin content that is most of this corpus, and a
+  // wrong count beats a thrown error on a validation rail.
+  const Segmenter = (Intl as unknown as { Segmenter?: SegmenterCtor }).Segmenter;
+  if (typeof Segmenter !== 'function') {
+    return trimmed.split(/\s+/).filter(Boolean).length;
+  }
+  try {
+    let n = 0;
+    for (const part of new Segmenter(locale, { granularity: 'word' }).segment(trimmed)) {
+      // `isWordLike` is what keeps punctuation and the spaces themselves out —
+      // the segmenter yields those as segments too.
+      if (part.isWordLike) n += 1;
+    }
+    return n;
+  } catch {
+    return trimmed.split(/\s+/).filter(Boolean).length;
+  }
 }
 
 /** Count comma-separated tags in a flat string, ignoring empties. */