Locale

Five dictionaries ship with the runtime. Pick one in beem-slide.config.ts, or pass your own object satisfying the Locale type.

This translates the UI the framework draws around your pages — the home screen, the deck list, the inspector, the assets pane, the presenter console, toasts. It does not touch the pages themselves: that text is in your own React, and nothing here reaches into it.

Presets

import type { BeemSlideConfig } from '@beem-slide/core';
import { zhTW } from '@beem-slide/core/locale';

const config: BeemSlideConfig = {
  locale: zhTW,
};

export default config;

All five come off the @beem-slide/core/locale subpath:

import { ar, en, ja, zhCN, zhTW } from '@beem-slide/core/locale';

Omit locale and you get en.

Arabic is not only a dictionary swap: selecting it flips the framework's own layout to right-to-left — rails, panels, controls and reading order, not just the strings. Your pages keep whatever direction you gave them, so a deck meant for an Arabic audience should set dir on its own root element too.

Custom dictionaries

Nothing in a dictionary is a function or a JSX node — it is all strings and plural pairs, which is what lets it survive being baked into a static build. Any object matching the Locale type from @beem-slide/core will do.

import type { BeemSlideConfig, Locale } from '@beem-slide/core';
import { en } from '@beem-slide/core/locale';

const fr: Locale = {
  ...en,
  id: 'en', // the closest built-in id
  common: {
    ...en.common,
    save: 'Enregistrer',
    cancel: 'Annuler',
    // …override the rest
  },
};

const config: BeemSlideConfig = { locale: fr };
export default config;

id has to be one of the built-in ids ('en' | 'zh-TW' | 'zh-CN' | 'ja' | 'ar') — it is reserved for locale-aware formatting later, and today the dictionary keys are what actually drive the UI.

Spread a preset and override what you need. The type is large, and building one from an empty object is a way to discover keys you missed at the worst moment.

Templates and plurals

Some entries are templates carrying {name} placeholders, and some are plural pairs ({ one, other }). The type definition flags both in JSDoc:

/** template: "Loading {slideId}…" */
loadingSlide: string;

/** templates: "{count} unsaved change" / "{count} unsaved changes" */
unsavedChanges: Plural;

Expansion is the runtime's job. Yours is to keep every {placeholder} token present, and to fill both one and other even in languages where they are the same string.

Two limits

The locale is read once at module init, so changing it needs a dev-server restart or a fresh build.

There is no in-app language switcher. One locale per deployment — which is usually right, since the audience for a deck is not usually multilingual in a way a toggle would help.