Tags are scoped per language. A tag created in one language variant does not exist in the others — each is a separate entity that has to be created and applied independently.

In a single-language project this is invisible. In a multilingual project it multiplies three things at once:

the same identifier has to be created once per language

it has to be applied separately to every language variant of every article

the project tag ceiling has to absorb all the duplicates

For a project publishing in six languages with around 13,000 unique product identifiers, this is the difference between roughly 27,000 tags and roughly 79,000. Where articles carry 50 or more tags each, a single article’s full language set can need several thousand individual tag applications.

Material numbers, SKUs and product codes are identical in every language. They should not need a copy per language.

The recent enterprise tag limits — 100,000 per project and 5,000 per article — mean this is no longer a blocker. But the headroom is largely being consumed by duplication rather than by distinct content, and the authoring effort of applying the same tag once per language remains.

Proposed behaviour

Allow a tag to be defined once and apply across all language variants of a project, with an optional per-language display label where the tag is visible to readers.

Existing per-language tags should keep working unchanged, so this would be additive rather than a migration.

Related requests

Different from “Translation options”, which covers displaying a tag in the reader’s language. This is about a tag being a single entity rather than one per language. The two are likely related in the underlying translation engine.

Also related to “Tags : Different Tags for workspace”, which raises tag scoping on a different axis.