import { type SitesApiClient } from "../api/sites-client.js";
import type { Operation } from "../ir/operations.js";
import type { PlannedAction, PlanSummary } from "./plan.js";
import type { ExecutionEvent } from "./execute-types.js";
/**
 * True when an apply-time error means the op's target language has no
 * registered version stack on the environment — i.e. that language isn't
 * provisioned. The Authoring API rejects a version write (AddItemVersion /
 * versioned SetField) against an unregistered language with one of these
 * shapes. Dictionary translations and component `__Standard Values`
 * locale-map defaults both emit per-language version writes, so an
 * operator whose environment lacks (say) `fr` would otherwise see the
 * whole push abort. See `nonPrimaryLanguageOfOp` for the guard that keeps
 * this scoped to non-primary-language ops only.
 */
export declare const errorMessage: (error: unknown) => string;
/**
 * Apply-error handler for the unregistered-language case. When `op` writes a
 * non-primary-language version and `message` says that language isn't
 * registered on the environment, rewrite the action from its planned status
 * to `skip`, reconcile the summary, emit `apply-skip`, and return true so the
 * apply loop `continue`s instead of aborting + rolling back. Returns false for
 * any other failure, which the caller then treats as a fatal apply error.
 * Factored out of `executeIr` to keep that function under the complexity gate.
 */
export declare const trySkipUnavailableLanguage: (op: Operation, action: PlannedAction, message: string, summary: PlanSummary, emit?: (event: ExecutionEvent) => void) => boolean;
/**
 * Ensure each required language exists on the environment before
 * `createSite` (which fails on an unknown `language`). Idempotent: skip
 * codes already present (single `listLanguages` pre-check), and treat the
 * Sites API's "already added" (409) as success. Adding a language here also
 * makes it available environment-wide — e.g. to the brand-kit Glossary's
 * org locales — so a recipe's `additionalLanguages` provisions brand locales
 * as a side effect.
 *
 * Returns the environment's language-code set (lowercased regional + iso
 * codes) after the ensure, so callers can gate site-level language writes
 * to codes the environment actually registered.
 */
export declare const ensureEnvironmentLanguages: (sitesClient: SitesApiClient, languages: string[]) => Promise<Set<string>>;
/**
 * Append missing declared languages to the SITE's own configured language
 * list (`supportedLanguages` — the property Pages offers locales from).
 * Environment registration alone doesn't put a locale on a site, so the
 * existing-site branch of CreateSiteFromTemplate PATCHes the list with
 * the union. Additive only — the list is never shrunk.
 *
 * `siteWritable` is the environment's SITE-WRITABLE code set returned by
 * {@link ensureEnvironmentLanguages} — regional identities only (`de-DE`,
 * `en`), NOT bare bases. A base like `de` is a valid localize FALLBACK
 * target but the Sites API rejects it on a `supportedLanguages` PATCH
 * ("The provided language 'de' with region code '' is not supported"), so
 * gating additions on this set keeps bases off the site list. (The set is
 * also already narrowed to codes the environment actually registered —
 * catalog-skipped admission codes never reach here.)
 *
 * The merge base is a FRESH `retrieveSite` detail read, not the plan-time
 * `listSites` row: the detail view is authoritative for
 * `supportedLanguages`, and re-checking there also makes the PATCH a
 * no-op when the plan-time diff was stale.
 */
export declare const appendSiteLanguages: (sitesClient: SitesApiClient, site: {
    siteId: string;
    missing: string[];
} | undefined, siteWritable: Set<string>) => Promise<void>;