/**
 * The i18next bootstrap two donors wrote nearly comment-for-comment.
 *
 * Each browser surface spreads these into its own init with its own bundled resources:
 *
 * ```ts
 * i18n.use(LanguageDetector).use(initReactI18next).init({ resources, ...i18nInitOptions({…}) })
 * ```
 *
 * Keeping the options here is what stops a console, a storefront and a docs site in the same
 * product from drifting apart on the details below. Each is a bug somebody already shipped.
 */
export interface I18nInitOptions {
    /** The language everything falls back to. */
    fallbackLng: string;
    /** Every language this app ships, as the exact tags used in the catalogs. */
    supportedLngs: readonly string[];
    /**
     * Where the reader's choice is remembered.
     *
     * One key everywhere is a convention, not a mechanism: `localStorage` is scoped to an ORIGIN,
     * so a console on `app.example.com` shares nothing with a storefront on `example.com` no
     * matter what the key is called. Which is why {@link queryKey} exists.
     */
    storageKey: string;
    /**
     * The query parameter that hands a language ACROSS an origin, e.g. `"lang"`.
     *
     * When set it is detected FIRST, ahead of storage and the browser. It is the only one of the
     * three that somebody chose on purpose and just now. A reader who picked Português on the
     * storefront and followed a link into the app means it more than their laptop's locale does. It
     * is cached on arrival, so it decides once and no URL inside the app has to carry it.
     *
     * Only one donor had this. The other has the same split-origin layout and the same problem.
     */
    queryKey?: string;
    /**
     * Who WRITES {@link storageKey}. The detector, by default.
     *
     * Pass `"app"` when your own language control writes it. A "follow the browser" option needs
     * this. Going back to following the browser means clearing the key and calling
     * `changeLanguage(undefined)`, which re-runs detection; a detector that caches then writes the
     * language it just detected straight back into the key it was told to clear. The choice re-pins
     * itself and nothing can reach that state again.
     *
     * Three repos on this stack, three answers: one lets the detector write, one writes it from its
     * own control, and one does both. Doing both is harmless there only because it offers no "follow
     * the browser" state. So the rule, rather than the default: one writer per key.
     */
    storageWriter?: "detector" | "app";
}
export declare function i18nInitOptions({ fallbackLng, supportedLngs, storageKey, queryKey, storageWriter, }: I18nInitOptions): {
    fallbackLng: string;
    supportedLngs: string[];
    load: "currentOnly";
    interpolation: {
        escapeValue: boolean;
    };
    detection: {
        lookupLocalStorage: string;
        convertDetectedLanguage: (tag: string) => string;
        lookupQuerystring?: string | undefined;
        order: string[];
        caches: string[];
    };
    react: {
        useSuspense: boolean;
    };
};
/**
 * Substitute `{{brand}}`-style placeholders through a bundled resource tree, once, before
 * i18next ever sees it.
 *
 * Done here rather than through interpolation because i18next v26 has no global interpolation
 * defaults, and these strings are often resolved by dynamic key, so a wrapping `t()` would not
 * reach them. The point is that a rename or a domain move is ONE edit in the brand constants
 * instead of a sweep across every locale file.
 *
 * Returns a fresh tree; the input is untouched. The placeholder names come from `vars`, so adding
 * one needs no change here. Two donors hardcoded their own list in the regex and both had to
 * remember to update it.
 */
export declare function applyBrandVars<T>(resources: T, vars: Record<string, string>): T;
//# sourceMappingURL=i18n.d.ts.map