Arkian logo
Start free
Menu
← All articles

Feature Flag Translations: French UI, English Keys, Safer Flag Logic

Feature Flag Translations: French UI, English Keys, Safer Flag Logic

Engineer testing a French-language feature toggle

Use « commutateur de fonctionnalité »: singular « un commutateur de fonctionnalité », plural « des commutateurs de fonctionnalité ». This is the term the Office québécois de la langue française recommends for feature flag, feature toggle, and feature switch. Keep the English term in code, config keys, and SDK options; translate only what end users read.

TL;DR:

  • The OQLF recommends one French equivalent; when pluralized, only the main noun changes, while its modifying noun stays singular in this compound term.
  • Keep flag keys, variation identifiers, configuration names, and SDK parameters in English; translate only interface text intended for customers or other nontechnical readers.
  • Map stable variation identifiers to localization keys rather than source text, and store each locale’s label separately to prevent copy edits from breaking flag behavior.
  • Validate plural forms, placeholders, and missing keys, then test the active flag state with the target locale and confirm the localized fallback when disabled.
  • Keep the same French term across regions and channels, while adapting surrounding wording for formality or cultural context when audience expectations differ.
Arkian
Keep Localized Flag Copy Organized
Arkian automates multilingual scripts and structured language packages, helping small teams manage localized interface text without complex translation systems.
Explore Arkian’s localization platform

Table of Contents

Grammar rules for French UI strings and documentation

French compound nouns pluralize in a specific way, and feature flag is no exception. The OQLF record confirms that only the first element changes when the noun becomes plural: « commutateur » takes the plural marker, while « de fonctionnalité » stays fixed because it functions as a modifier, not a countable noun.

  • Singular: « un commutateur de fonctionnalité »
  • Plural: « des commutateurs de fonctionnalité »
  • Never pluralize both halves: « des commutateurs de fonctionnalités » is incorrect for this sense.

A few string examples for resource files:

  • “Enable feature flag” becomes “Activer le commutateur de fonctionnalité”
  • “Manage feature flags” becomes “Gérer les commutateurs de fonctionnalité”
  • “This feature flag is disabled” becomes “Ce commutateur de fonctionnalité est désactivé”

Pro Tip: Store the plural form as a separate string resource rather than appending an “s” programmatically; French plural rules for compound nouns do not follow simple concatenation logic.

What to translate and what to leave in English

Translating the label a user sees and translating the system that controls the flag are two different jobs, and mixing them causes bugs. A practical rule set:

  1. Never translate flag keys, identifiers, or config names: a flag named new_checkout_flow stays exactly that in every locale, because translating it breaks lookups, analytics, and rollout logic.
  2. Keep SDK option names and internal function parameters in English: when a library exposes something like evaluateFlag(key, context), translating the parameter names serves no one and risks silent failures.
  3. Translate the presentation layer only: button labels, settings screens, help center articles, and release notes aimed at end users are the right place for « commutateur de fonctionnalité ».
  4. Favor English in developer documentation and internal wikis, since most engineers search and think in the ecosystem’s dominant English terms, and consistency with upstream SDK docs reduces confusion.

Community discussion threads about translating “Feature Flags” confirm this split is common practice: francophone teams frequently keep the English term in code and developer tooling while choosing a French label for anything a customer or non-technical stakeholder reads.

A checklist for safely shipping translated flag labels

The safest pattern separates three layers: the flag’s identity, the variation it resolves to, and the string shown for that variation in a given locale. Mixing these layers is the most common source of mismatched labels.

  1. Keep the flag key and its possible variation values (for example control, variant_b) language-neutral and stable across every release.
  2. Map each variation identifier to a localization key, never to the source text itself, so a later copy edit in English does not silently break the French string’s lookup.
  3. Store the French label under its own key in your language file, separate from the English source string.
  4. Run a plural check and placeholder check on the French string before merging, since compound nouns like this one follow the pluralization rule described above rather than a generic plural suffix.
  5. Preview the combined flag-state-plus-locale case in a staging build, not just the isolated string, to catch rendering issues where a fallback locale shows the wrong label.

A JSON entry might look like this:

{ "flag_new_checkout.control.label": "Commutateur désactivé",
  "flag_new_checkout.variant_b.label": "Commutateur activé" }

PostHog’s local-evaluation documentation makes the underlying principle explicit: flag evaluation depends on flag definitions and supplied properties, not on any translated label, which is exactly why the label belongs in the presentation layer and never in the evaluation logic itself.

File format Where the French string goes What stays untouched
JSON Value under a dedicated locale key The flag key and variation identifiers
iOS .strings "flag_label" = "Commutateur de fonctionnalité"; The flag’s Swift/Obj-C identifier
Android XML <string name="flag_label">Commutateur de fonctionnalité</string> The android:name resource identifier

Our guides on localizing iOS .strings files and Android XML string files walk through this placement in more detail, as does our JSON language file guide.

Small-team rules that keep translations and flags in sync

Small teams rarely have a dedicated localization engineer, so the rules need to be simple enough to follow without a review cycle. We recommend one glossary entry per flag-related term, written once and reused across every project: “feature flag → commutateur de fonctionnalité (sing.) / commutateurs de fonctionnalité (plur.).” Our glossary-building guide walks through setting this up in five steps.

Automating the packaging and validation step, rather than hand-editing language files, removes a common failure mode where a translator updates a string but a developer’s build still points at stale text.

  • Keep one internal name for the concept across every repository and document, so no team member improvises a second French variant.
  • Validate every language file against its source before it ships, catching missing keys or orphaned plural forms automatically.
  • Run a lightweight 3-step QA pass: check the string renders in context, check the plural form matches the rule above, and check that no flag key or identifier leaked into the translated text.

Pro Tip: Treat the glossary entry as a single source of truth; copy it into every new project instead of re-deriving the French term each time.

Adapting feature flag copy to locale and culture

A direct translation of the English label is usually enough, but a few contexts call for adjustment beyond the word itself. Formality matters: a consumer-facing settings screen in French often reads better with a slightly more conversational phrasing than a strict terminological rendering, while documentation aimed at IT administrators should stick closely to the OQLF form for consistency with other technical material.

Regional variants of French also diverge in tone and convention, and a string that reads naturally in one francophone market can feel stiff or overly formal in another. When a product serves multiple French-speaking regions, it is worth checking whether a single translation works everywhere or whether a regional variant is needed for tone alone, since the underlying term itself does not change.

Cultural context also affects how much explanation a label needs. A flag described as “experimental” or “beta” benefits from a short explanatory string in some markets and none in others, depending on how comfortable the audience is with pre-release features. Agile and practitioner glossaries note that feature flags serve different functional roles: release flags, experiment flags, ops toggles, and permission toggles. That functional role, more than the locale itself, often determines whether a label needs extra context or can stand alone.

Keep the base term identical across every locale variant of French. Vary only the surrounding copy, the level of formality, and the amount of explanatory text, not the core rendering of the flag concept.

How to test translated feature flags before release

Testing a translated flag label is not the same as testing the flag’s logic, and treating them as one step is how mismatches slip through, which is why a disciplined approach to the software development lifecycle is essential, as explained in The Agentic SDLC Explained. A useful approach separates the checks into layers.

First, validate the string in isolation: does the French text fit the UI space, does the plural form follow the compound-noun rule, and are placeholders filled correctly. Second, validate the combination: load the build with a specific flag variation active and the locale set to French, and confirm the right label appears for that specific state, not just that French text appears somewhere on the screen.

A practitioner article on localizing feature flags, remote configuration, and A/B tests recommends treating locale resolution and flag evaluation as independent selectors that combine only at render time, then testing the combinations explicitly rather than assuming each works correctly on its own. This catches the specific failure where a fallback locale accidentally displays an English label inside an otherwise fully French screen, or where a stale cache shows the wrong variation’s text.

Independent locale and flag checks combine at render time

Finally, run a rollback check: disable the flag and confirm the fallback string, whatever surfaces when the flag is off, is also properly localized. Teams often translate the “on” state carefully and forget the “off” state entirely.

Why the translation choice affects usability, not just correctness

A mistranslated or inconsistent feature flag label does more than look sloppy. When a French-speaking user sees a technical term rendered inconsistently across screens, support articles, and settings menus, it signals that the product was translated mechanically rather than thought through, and that impression carries over to trust in the rest of the interface.

Consistency also reduces support burden. A help center article that uses « commutateur de fonctionnalité » while the settings screen uses « drapeau de fonctionnalité » forces a reader to guess whether the two terms refer to the same thing. Picking the OQLF-recommended form once and reusing it everywhere removes that friction entirely.

There is also a readability cost to over-translating. A user who searches for help with a “feature flag” problem, even in a French-language product, may type the English term into a search bar out of habit, especially if they also use English-language developer tools. Keeping a short parenthetical reference to the English term in a help article’s first mention, then using the French term consistently afterward, serves both audiences without duplicating content.

The practical upshot: pick one French form, apply the correct plural rule every time, and keep it identical across UI, documentation, and support content. That consistency, more than the specific word choice, is what readers actually notice.

Why the translation choice affects usability, not just correctness — overview diagram

What the research actually supports, and what gets overstated

Most advice on this topic focuses heavily on picking the “right” French word, as if the translation itself were the hard part. It isn’t. The OQLF record settles the word choice in one sentence. The harder, under-discussed problem is keeping that word correctly mapped to the right flag state across every file format, every release, and every locale fallback, which is where most real-world mismatches happen.

Teams that treat localization as a one-time translation task tend to drift: a string gets updated in English, the French equivalent lags behind, and nobody notices until a support ticket arrives. The fix isn’t better translation, it’s better mapping discipline: stable variation keys, a single glossary entry, and a validation step that runs every time a file changes rather than only when someone remembers to check.

If you take one thing from this, prioritize the plumbing over the wordsmithing. Get the term right once, write it into a glossary, and spend your remaining effort on the process that keeps it attached to the correct flag state release after release.

— Arkian

Arkian: get validated, packaged language files for feature-flagged copy

Translating a single label correctly is the easy part. Keeping that label correctly packaged across JSON, iOS .strings, and Android XML, release after release, is where small teams lose time. We automate that packaging step: we produce localization strings already validated against your source file, then package them into delivery-ready formats through structured packaging, without asking for repository access or a full translation management system setup.

Arkian

  • Automated validation catches missing keys and malformed plurals before they reach a build, faster than a manual review pass.
  • Structured output means a developer imports a finished file instead of hand-editing strings, cutting the back-and-forth that causes flag-to-locale mismatches.

Check current plans to see what fits a small team’s release schedule.

FAQ

What is the correct French translation for “feature flag”?

The OQLF-recommended term is « commutateur de fonctionnalité », covering feature flag, feature toggle, and feature switch. Use the singular « un commutateur de fonctionnalité » or plural « des commutateurs de fonctionnalité » depending on context.

How do you pluralize “commutateur de fonctionnalité” correctly?

Only the first element changes in the plural: « des commutateurs de fonctionnalité », never pluralizing the second half. This follows the OQLF’s grammatical guidance for this compound noun.

Should flag keys and SDK options be translated into French?

No. Flag identifiers, config keys, and SDK option names should stay in their original form regardless of interface language, since translating them breaks lookups and evaluation logic. PostHog’s local-evaluation documentation confirms that evaluation depends on stable definitions and properties, not on any display label.

Is it acceptable to keep “feature flag” in English in French documentation?

Yes, particularly in developer-facing documentation, where the English term matches the dominant ecosystem and supports easier searching. Reserve the French term for end-user interfaces, settings screens, and customer-facing help content.

Why does feature flag translation matter for product usability?

Inconsistent terms across screens and support content make a product feel mechanically translated and increase support questions. Using one correctly pluralized French term everywhere removes that friction and keeps technical copy trustworthy.

Sources

The OQLF terminology record maps « commutateur de fonctionnalité » to three English equivalents: feature flag, feature toggle, and feature switch. The choice of « commutateur » over other candidate nouns is deliberate: a commutateur is something you operate, a control with an on and off state, which matches what a feature flag actually does. A term built on « indicateur » would suggest a read-only signal instead, which misrepresents the mechanism.

A few alternatives circulate in French technical writing, each with tradeoffs:

OQLF’s recommendation applies to formal French terminology in Quebec and Canada, and it is the reference most style guides defer to when producing fully localized interfaces or official documentation.

For developer-facing material, keeping “feature flag” in English often makes more sense. It preserves searchability against the dominant English documentation ecosystem (blog posts, SDK references, Stack Overflow threads) and matches what most engineers already type into search bars, regardless of their interface language.