Language-aware components crash on a `language` value that has no translations (e.g. `nb`)

[Kiarokh]

Current behavior

Translations.get (src/global/translations.ts) resolves a translation with an unguarded double index:

const translation: string = allTranslations[language][key];

The public Languages type (src/components/date-picker/date.types.ts) lists nine languages — da | de | en | fi | fr | nb | no | nl | sv — but allTranslations maps only eight (da, de, en, fi, fr, nl, no, sv). There is no entry for nb (Norwegian Bokmål) and no src/translations/nb.ts.

So passing language="nb" — a value the TypeScript type explicitly accepts — makes allTranslations['nb'] undefined, and the [key] access throws TypeError: Cannot read properties of undefined. Roughly 23 components expose a language prop and call translate.get during render, so this crashes the component on render rather than falling back. Any language string outside the map (reachable from loosely-typed / plain-JS consumers) fails the same way.

Steps to reproduce:

1. Render any language-aware component with language="nb", e.g. <limel-date-picker language="nb"> or <limel-slider language="nb">.
2. The component throws TypeError on render.

Expected behavior

An unsupported or unmapped language should degrade gracefully — fall back to en (and then to the raw key, as get already does for a missing key) — instead of throwing. The nb/no mismatch should also be reconciled: either map nb (alias it to the existing no translations, or ship an nb.ts), or drop nb from the Languages type so it stops advertising unsupported support.

Suggested defensive fix (covers every unmapped value, not just nb):

const translations = allTranslations[language] ?? allTranslations.en;
const translation: string = translations[key];

Environment

• lime-elements version: 39.x (current)
• Framework used: any — framework-agnostic; reproduces in plain Stencil/HTML
• Logs: TypeError: Cannot read properties of undefined (reading '<key>')

---

Side note: default language

All ~23 language-aware components default language to 'en'. It's worth discussing whether the default should instead follow the browser's language (navigator.language). Trade-offs:

• For: a better out-of-the-box experience for non-English users, without every consumer wiring up i18n.
• Against: server-side rendering / hydration mismatches (the server can't know the browser locale, so pre-rendered markup diverges from the client), non-deterministic output, and navigator.language frequently returns a locale outside the supported set (e.g. es, pt-BR) — which makes the graceful-fallback fix above a prerequisite either way.

Recommendation: fix the crash / fallback regardless (it's a clear bug). Treat browser-language defaulting as a separate, opt-in enhancement (e.g. a documented 'auto' value) rather than changing the default, to avoid SSR and backward-compatibility surprises.

---

Surfaced while adding a language prop to limel-slider (unset-value work); the slider is just the newest component to reach this pre-existing gap.