How registered interface strings are translated

Registered strings cover site-facing labels that do not naturally belong to a post, term, menu item, or gettext software catalog. A theme or plugin registers a stable name and current source value; editors translate that value under Translations → Other translations.

Use registered strings for stable site copy

Appropriate examples include:

• a theme option used as a public heading;
• a reusable footer sentence;
• a form label stored outside post content;
• an integration-defined message with a stable public purpose;
• a default value that is rendered in several supported locations.

Do not register:

• arbitrary visitor or customer data;
• complete dynamic HTML responses;
• IDs, tokens, prices, coordinates, or serialized configuration;
• ordinary WordPress gettext strings already owned by a software text domain;
• post content that POM Translate can extract from its canonical object.

Choosing the correct surface keeps source ownership and cache invalidation predictable.

Registration establishes identity

The public helper accepts a unique string name and its current source text. The stable name identifies the setting or interface purpose even if the displayed source wording later changes.

A missing or empty name is rejected. Re-registering the same name refreshes its current source value and the request’s registered-string cache.

The optional legacy grouping and multiline arguments remain accepted for compatibility, but the current storage association is based on the unique name and source value. Do not rely on a group label to distinguish two registrations with the same name.

Source and target responsibilities remain separate

The theme, plugin, or setting that registers the string owns its source text. POM Translate owns target-locale values for that registered entry.

When the source text changes, the underlying source unit is updated using the same exact-source rules as other translated values. Existing target text must be reviewed unless an exact normalized match can be reused.

Editors should not alter the source wording from Other translations. Make the source correction where the string is registered or configured, then allow POM Translate to refresh the entry.

Rendering is explicit

Registration alone does not replace matching words across the page. The component that owns the string must request its translation for the active locale or use a supported POM Translate integration that does so.

The lookup:

1. finds the registered entry for the supplied source value;
2. normalizes the requested language to a configured locale;
3. returns the source unchanged for the base locale;
4. loads the target value for another locale;
5. returns the source when no non-empty translation exists.

POM Translate does not automatically register unknown strings during a translation lookup. This prevents a dynamic REST or AJAX response from filling the registry with customer-specific or short-lived values.

Registered strings are not gettext catalogs

Do not duplicate a gettext message as a registered string merely to avoid the software-translation workflow.

Verify one registered label

1. Choose a supported public setting or integration label that appears under Other translations.
2. Record its source wording and where it appears on the site.
3. Add a target translation and save it.
4. Open the source route and confirm the original label remains.
5. Open the target route and confirm the translated label appears.
6. Clear the target value and verify source fallback.
7. Change the source value through its owning setting or integration.
8. Reload Other translations and confirm the refreshed source requires appropriate review.

If a label appears in the table but never changes publicly, confirm that its owner requests the registered translation in that output context. Registration makes a value available; it does not perform a global text replacement.