Translation bot generates incorrect output for plural translation keys

[melvin-bot]

Problem

The translation bot produces incorrect output when handling plural translation keys (i.e. keys whose value is a function returning an object with one/other plural forms).

Expected output

For a plural key like:

codingRules: ({sourcePolicyName}: {sourcePolicyName: string}) => ({
    one: `copió 1 regla de comercio de ${sourcePolicyName}`,
    other: (count: number) => `copió ${count} reglas de comercio de ${sourcePolicyName}`,
}),

The bot should produce the same structure — a function accepting the input params and returning an object with plural forms.

Actual output

The bot flattens the object and strips the outer function wrapper and input parameters, producing something like:

codingRules: {one: `copiou 1 regra de comerciante de ${sourcePolicyName}`, other: (count: number) => `copiou ${count} regras de comerciante de ${sourcePolicyName}`},

This breaks TypeScript types and will cause runtime errors or fall back to an unavailable translation.

Additional issue

When generating translations for languages with a different number of plural forms than English (e.g. languages with zero, two, few, many forms), the bot should generate the correct plural forms for that language — not just mirror the English one/other structure.

References

• Discovered in: Add policy copy change log messages #94189 (comment)

[MelvinBot]

Proposal

What is the root cause of that problem?

The translation bot has two code paths, and only the incremental path (used in CI via --pr-number, and locally via --compare-ref) is broken. The full-file path is correct.

For a plural key shaped as key: (params) => ({one: ..., other: ...}), the incremental path identifies what to translate by building a dot-notation path up the AST — but buildDotNotationPath only collects PropertyAssignment nodes and walks straight through the outer arrow function. So a changed string inside other registers as the path codingRules.other, not codingRules. The arrow-function wrapper and its destructured params ({sourcePolicyName}) are invisible to path-building.

That mis-scoped path then propagates:

• extractTranslatedNodes captures only the leaf initializers of codingRules.one and codingRules.other.
• injectDeepObjectValue reassembles them from the dot-path segments as a plain object literal — codingRules: {one, other}.

There is no mechanism to rebuild the (params) => (...) wrapper, so it is dropped and ${sourcePolicyName} becomes an undefined reference, breaking TranslationDeepObject<typeof en> typing.

The second concern (CLDR plural categories) is a separate gap: nothing in the bot is aware of Intl.PluralRules. one/other are treated as ordinary object keys and English's structure is mirrored verbatim, so locales requiring zero/two/few/many never get the correct forms.

Evidence & verification

• The full-file transform is correct because createTranslationTransformer only Replaces leaf string/template nodes (shouldTranslateNode matches only string/template literals) and lets ts.visitEachChild copy the arrow function + params verbatim.
• This is confirmed by already-committed plural keys that survived full retranslation intact, e.g. suggestionsAvailable: ({count}: {count: number}, query = '') => ({one: ..., other: (resultCount) => ...}) in es.ts.
• So the bug is path-dependent: incremental add/modify of a function-wrapped plural key flattens it; a full re-translation does not. This matches the symptom — the keys in PR #94189's diff were newly added and went through the incremental path.
• createPathAwareVisitor likewise only updates the path on PropertyAssignment, never short-circuiting on a function initializer.

What changes do you think we should make in order to solve the problem?

Primary bug (flattening): When building translation paths in the incremental path, stop descending at a property whose initializer is an ArrowFunction/FunctionExpression. Treat the whole function-valued property (e.g. codingRules) as a single translatable unit so its full (params) => ({...}) initializer is captured and re-injected intact.

• The cleanest place is in path construction: in buildDotNotationPath (and the diff-driven path build around generateTranslations.ts:1092-1104), collapse the path to the nearest enclosing property whose initializer is a function. Then extractTranslatedNodes records codingRules (the whole function) and injectDeepObjectValue carries the wrapper through unchanged.
• Translate the leaf strings inside that captured initializer without rebuilding its structure, so params and the arrow wrapper are preserved.

Secondary concern (CLDR plural forms): This is a larger feature — there is currently zero scaffolding. It needs per-locale plural categories (via Intl.PluralRules) plus prompt/structure changes so the bot can emit the correct set of keys (zero/two/few/many) for the target locale rather than mirroring English. Recommend splitting this into its own follow-up issue.

What alternative solutions did you explore? (Optional)

Alternatively, make createPathAwareVisitor not recurse into the body of a function-valued property when building translation paths — same net effect, applied at traversal time rather than in buildDotNotationPath.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/94343) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[roryabraham]

mulling this plan over locally. It's a complex script and I want to iterate on it in my local dev environment, not with Melvin

[melvin-bot]

@roryabraham this issue was created 2 weeks ago. Are we close to a solution? Let's make sure we're treating this as a top priority. Don't hesitate to create a thread in #expensify-open-source to align faster in real time. Thanks!