Understand custom language support

POM Translate does not currently provide a form for inventing an arbitrary additional locale. The Language selector uses the product’s supported language catalog, and the programmatic enable/disable helper also normalizes input against that catalog.

A custom display label is not a custom locale.

What a language definition contains

Each supported definition supplies information used across the product, including:

• a locale code such as en_GB;
• a language slug;
• a country code and flag definition where applicable;
• local and English language names;
• local and English country names.

POM Translate uses the locale as the stable identity. The other properties support selectors, regional display, prefixes, machine-translation direction, and language metadata.

Adding only a name and two-letter code would leave those relationships incomplete.

Use an existing regional variant when possible

Before concluding that a custom language is required:

1. open Settings → POM Translate → Languages setup → Base setup;
2. add an Additional language row;
3. search the Language selector for the local name, English name, and region;
4. compare the full locale codes shown in brackets;
5. select the exact supported variant;
6. use Custom language label if only the public wording needs to change.

For example, changing “English (United Kingdom)” to “English” is a label decision. It does not require another locale definition.

The main WordPress locale is a special case

The read-only Main language follows Settings → General → Site Language. If WordPress supplies a site locale that is not present in POM Translate’s catalog, the Base setup screen still includes that current locale as the source language.

POM Translate can fall back to the raw locale code when catalog labels are unavailable. However, catalog-dependent presentation such as regional names or flag metadata may be incomplete.

This does not make the unsupported locale selectable as an additional language.

Programmatic enabling has the same boundary

The public language-toggle helper accepts:

• an exact supported locale such as en_GB;
• a hyphenated equivalent such as en-GB;
• a two-letter language code, which resolves to the first matching definition in the catalog.

Unsupported input is rejected. Passing en is also less precise than passing en_GB because it chooses the first catalog match, not a region inferred from the site audience.

Integrations should store and pass the complete supported locale.

Do not edit the catalog in place

Avoid modifying the plugin’s language data file to add a local definition:

• an update can overwrite the edit;
• other environments will not share it;
• missing flags, names, prefix behavior, catalogs, and translation-provider support can remain;
• the locale has not passed the product’s normal compatibility review.

Request an intentional product addition when a genuinely new locale must become supported. That addition should define its identity and verify routing, selectors, browser matching, SEO, software catalogs, POM AI, WooCommerce, and multisite behavior together.

Custom labels solve presentation only

Use:

• Custom label for the main language for the source locale;
• Custom language label inside an additional-language row for a target locale.

These values are sanitized as plain text and made available to language selectors and locale labels. They do not change:

• the locale code;
• the generated URL prefix;
• lang or hreflang;
• the source or target association;
• the regional flag definition;
• browser Accept-Language matching.

Switcher markup must use the {%custom_label%} merge tag when that exact custom text should be visible. The default markup can instead show catalog-supplied local and English labels.

Verify the chosen solution

After selecting a supported variant or adding a custom label:

1. reload Base setup and confirm the full locale;
2. inspect the language selector markup;
3. verify the target URL prefix;
4. inspect the document lang value;
5. check canonical and alternate-language metadata;
6. test an exact and a general browser-language header;
7. confirm machine translation and software catalogs recognize the intended locale.

If the requirement is limited to visitor-facing wording, continue with Configure public language labels. If the locale identity itself is missing, do not simulate it with a label.