René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"[Feature]: Promote `i18n` to Stable + message-extraction tooling and documented ICU coverage","articleBody":"**Pre-flight checklist**\n- [x] I searched existing issues and did not find a duplicate request.\n- [x] I explained the problem or use case, not just the desired API.\n\n**Problem or use case**\n`i18n` is **Beta** and grew in 1.14.0 (`negotiateLocale`, `detectLocale`, `isRTL`, `formatRelativeTime`, `formatList`, `formatDisplayName`, `segment`). First-party i18n is a real differentiator (React/Vue/Svelte mostly lean on third-party libs), but two gaps block both stability and adoption: there is **no message-extraction tooling** to pull translatable strings out of source, and the extent of **ICU / complex-plural coverage** is not documented. Teams can't commit to a localization workflow they can't extract for or whose plural support is unspecified.\n\n**Proposed solution**\nFreeze the formatting/locale API for one cycle, add an optional message-extraction tool that scans source for translation calls and emits/merges catalogs, and publish a precise statement of ICU MessageFormat coverage (plurals, selects, nested arguments) with examples — implementing any documented-but-missing cases. Keep extraction build-tool-agnostic and optional to preserve the zero-build path. Exit criteria: frozen API, extraction tool shipped, ICU coverage documented and tested, lazy-loading of catalogs documented.\n\n**Possible API or UX shape**\n```ts\nimport { defineMessages, t } from \"@bquery/bquery/i18n\";\n\nconst messages = defineMessages({\n  cart: { items: \"{count, plural, one {# item} other {# items}}\" }\n});\n\n// Optional extraction (any bundler / CLI):\n// bquery-i18n extract \"src/**/*.ts\" --out locales/en.json\n```\n\n**Alternatives considered**\nDocumenting that users should manage catalogs by hand — viable for tiny apps but a non-starter at scale and weaker than the mature i18n ecosystems around React/Vue. Shipping extraction as a mandatory build step — violates zero-build; it must be optional.\n\n**Relevant area**\n`i18n`\n\n**Additional context**\nThis is both a stabilization and a competitive-strength ticket: getting extraction + documented ICU coverage turns first-party i18n from \"nice to have\" into a real reason to choose bQuery.\n","author":{"url":"https://github.com/JosunLP","@type":"Person","name":"JosunLP"},"datePublished":"2026-06-26T21:25:36.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":0},"url":"https://github.com/141/bQuery/issues/141"}