Every rule answers three questions about when it applies: which projects, which language, and whether casing matters. They are the Applies to, Language, and Case sensitive fields in the rule drawer.
Getting these wrong is the most common reason a rule looks correct in the list and does nothing on the page.
Which projects
Applies to has two options.
- This project affects this project only.
- The whole workspace affects every project in the workspace, including projects you add later.
A rule that applies everywhere is badged Workspace-wide in the list, so you can tell the two apart at a glance.
Use the workspace scope for things that are true everywhere, like a brand name. Use the project scope when one site needs different wording from its siblings.
A project rule beats a workspace rule
When both exist for the same term, the project rule wins on that project and the workspace rule keeps applying everywhere else.
That is what makes exceptions possible. A workspace rule can keep Ember untranslated across twelve sites while one site translates it, without touching the other eleven.
Changing the scope of an existing rule
Two things happen automatically, and both are worth knowing before you switch.
Widening cleans up duplicates. Setting a rule to the whole workspace removes per-project rules for the same term, language, and match type, because the workspace rule now covers them. Those per-project rules are deleted, not disabled.
Narrowing asks first. Switching a workspace-wide rule back to one project prompts Remove this rule from other projects?, because the rule stops applying everywhere else. Decline and nothing changes.
Which language
Language is either Any language or one specific language. The dropdown only lists languages enabled on this project.
For a Keep as is rule, Any language is usually right: a brand name should survive into every language.
For a Translate rule, set the language. A translation is written in one language, so a rule holding Commande belongs to French. Leaving it on Any language applies that French wording to your German and Spanish pages too.
A language-specific rule beats an "any language" rule
For the same term, the more specific rule wins in its own language. This lets you set a general fallback and override it where needed:
Keep as is "Support" Any language leaves it in English everywhere
Translate "Support" German -> Hilfe except in German
Whether casing matters
Case sensitive is on by default.
ON "Order" matches Order only
OFF "Order" matches Order, order, ORDER, and oRdEr
Turn it off when a term appears in several casings on your site and all of them need the same handling. An acronym written API in headings and api in body text is the usual case.
Turning it off widens the rule, so check it does not catch an ordinary word. A case-insensitive rule for IT also matches the word “it”.
Casing works the same way for patterns. With case sensitivity off, STK{n:3} also matches stk110.
Your replacement text is never re-cased. A Translate rule inserts exactly what you typed, whichever casing the source matched.
How the three interact
The fields are independent, and they narrow rather than conflict. A rule with This project, French, and Case sensitive on applies when all three hold: this project, a French page, that exact casing. Change any one and the rule stops applying.
When two rules could both apply to the same term, the more specific one wins on each axis: project beats workspace, and a named language beats Any language.