# `MishkaCmsCore.Runtime.Resources.Changes.RegisterTranslationKeys`
[🔗](https://github.com/mishka-group/mishka_cms_core/blob/v0.0.1/lib/mishka_cms_core/runtime/resources/__changes/register_translation_keys.ex#L5)

Registers the keys a saved component, page or layout asks `t/1` for — in its template and in the
code of its helpers, events and infos (`MishkaCmsCore.Runtime.Translations.source_keys/1`) — so
they appear in the admin ready to translate.

The runtime counterpart of `mix gettext.extract`: a component, page or layout is a database row,
so its keys are read when it is SAVED rather than when a build runs. Each key gets a row in every
language `MishkaCmsCore.Runtime.Translations.languages/1` names for the template's site — a
global template's in every language any site publishes in, since it renders on all of them. See
`MishkaCmsCore.Runtime.Translations.register/2`, which leaves an existing row, and the
translation on it, exactly as it was.

    changes do
      change MishkaCmsCore.Runtime.Resources.Changes.RegisterTranslationKeys, on: [:create, :update]
    end

## After the write, and only when what asks for keys changed

An `after_action`, so a record that fails to save registers nothing. An update that leaves the
template and the code alone — a rename, a toggle — registers nothing either: the keys are the
ones it already had.

## Not when the template has its own `t`

A template whose helpers define a function named `t` is not importing ours, so its `t("…")` calls
are its own business and nothing is registered for them.

## It never refuses a save

Registration errors are collected and dropped. A template is the thing being saved; a key it could
not register costs a row in the admin, which the next save or `Translations.sync/1` puts back.

---

*Consult [api-reference.md](api-reference.md) for complete listing*