[roxana-mocanu]

Why

lingui extract fails on main for the chat catalog:

Error: Encountered different default translations for message autopilot-chat.error.multiple-files

Lingui requires every use of an id to carry the same default message. Four chat ids
did not: the same id was written with different English in different files, and in
one case a component used another feature's ids. Each mismatch alone stops extraction,
and Lingui reports only the first one, so this PR fixes all four at once.

Nothing is broken for users today. The chat always renders inside its I18nProvider,
so every locale (English included) reads the catalog value and never the code
default. The defaults only drifted apart over successive refactors, and with no
extraction run to compare them, nothing flagged it.

What changed

Code defaults now match the catalog. No catalog file changes.

Id	Was in code	Now (= en.json)
autopilot-chat.error.multiple-files	"Only one file is allowed" / "Only one file can be attached at a time"	Only one file can be attached per message
autopilot-chat.error.too-many-files	"Maximum {0} files allowed" / "Maximum {maxCount} files allowed"	Too many files. {maxCount} files are allowed per message
autopilot-chat.common.attachments.remove-file	"Remove file" / "Remove"	Remove
autopilot-chat.common.attachments.remove-file-name	"Remove {0}" / "Remove {label}" / "Remove {name}"	Remove {name}

• One id per error is intended. multiple-files and too-many-files are raised by
  two layers of the same check (the composer's intake hook, then the attachments
  provider) and shown in the same error banner, so they keep one id each.
• The resource chip now uses its own ids. The editor's resource chip borrowed the
  attachment ids, although autopilot-chat.input.resource-chip.remove and
  ...remove-name were added to en.json alongside it and are already translated in
  every locale. It now uses them, so the attachment ids only serve file chips. Its
  tooltip and screen-reader label keep the same text in every locale except one
  (see Localization impact).
• Placeholder names match the catalog. Lingui names a placeholder after the
  variable in the template literal (${allowedAttachments.maxCount} becomes {0}),
  so a local const keeps it as {maxCount} / {name}, as composer-strings.ts
  already does.

Localization impact

The TMS only receives en.json, so each id was translated once, from the catalog
text. The other English variants in code never reached localization, and nothing
signalled that they existed:

• The code wording never shipped. Variants such as "Remove file" or "Only one file
  can be attached at a time" were not shown in any language, English included. Anyone
  reading the code saw one text while users saw another.
• Translated strings went unused. The resource chip's own ids were translated in
  every locale but never displayed. The chip showed the file chip's translations
  instead. Those match in 11 locales. In Romanian they differ, so with this PR the
  resource chip tooltip changes from "Înlăturare" (the file wording) to "Eliminare",
  its intended translation.

No user saw wrong text, but English had two sources of truth, translation effort
went to strings that never shipped, and the extraction run that would have caught
the mismatch had been failing.

Wording choices

Where code and catalog disagreed, the catalog text was kept, since it is what users
already see and what is translated. It is also the clearest of the variants:
"per message" states the actual limit and points to the fix (remove the attached file
or send first). "At a time" suggested another file could be added afterwards, which
the intake check rejects when the draft already holds one.

Checks

• pnpm run i18n:extract completes. Its catalog rewrite (key reordering, and empty
  placeholders for keys not yet translated) is left out of this PR, since locale
  files are owned by the l10n sync.
• vitest --run src/chat src/material/components/ap-chat: 435 of 436 tests passed.
  One scroll test in message-list-scroll.test.tsx failed once during the full run and
  passes on its own, with and without this change. Two test files that import the
  built package (@uipath/apollo-react/ap-chat) need a local build to run.
• Biome: clean.

Follow-ups

• autopilot-chat.tool-call.json.item-count and ...key-count are ICU plurals, which
  the TMS cannot parse. Same fix as fix(apollo-react): replace ICU plurals in canvas counts with count-neutral labels #1451, in a separate PR.

🤖 Generated with Claude Code

[Copilot]

🟢 Approval recommended

The narrowly scoped translation changes match the existing catalog, with no unresolved blocking issues identified.

No open issues 🎉

What changed in this PR

Fixes chat message-default conflicts that block Lingui extraction in apollo-react, aligning code with existing translations without changing catalog files.

Changes:

• Align attachment-limit error defaults across the intake hook and provider.
• Match attachment placeholders to the catalog’s named placeholders.
• Switch resource chips to their existing, dedicated translation IDs.

File	Description
packages/​apollo-react/​src/​material/​components/​ap-chat/​components/​input/​tiptap/​resource-chip-node-view.tsx	Uses resource-chip translation IDs for removal labels.
packages/​apollo-react/​src/​material/​components/​ap-chat/​components/​common/​attachments.tsx	Aligns removal text and the name placeholder with the catalog.
packages/​apollo-react/​src/​chat/​headless/​providers/​attachments-provider.tsx	Aligns attachment-limit messages and the maxCount placeholder.
packages/​apollo-react/​src/​chat/​headless/​hooks/​use-attachment-intake.ts	Matches intake error defaults to catalog wording.

_{Review effort: Balanced}

[github-actions]

Dependency License Review

• ✅ 1957 package(s) scanned
• ✅ No license issues found
• ⚠️ 2 package(s) excluded (see details below)

License distribution

License	Packages
MIT	1721
ISC	91
Apache-2.0	57
BSD-3-Clause	28
BSD-2-Clause	23
BlueOak-1.0.0	8
MPL-2.0	4
CC0-1.0	4
MIT-0	3
MIT OR Apache-2.0	2
(MIT OR Apache-2.0)	2
Unlicense	2
LGPL-3.0-or-later	1
Python-2.0	1
CC-BY-4.0	1
(MPL-2.0 OR Apache-2.0)	1
Unknown	1
Artistic-2.0	1
(WTFPL OR MIT)	1
(BSD-2-Clause OR MIT OR Apache-2.0)	1
CC-BY-3.0	1
0BSD	1
(MIT OR CC0-1.0)	1
MIT AND ISC	1

Excluded packages

Package	Version	License	Reason
@img/sharp-libvips-linux-x64	1.3.4	LGPL-3.0-or-later	LGPL pre-built binary, not linked
khroma	2.1.0	Unknown	MIT per GitHub repo, missing license field in package.json

[github-actions]

📊 Coverage + size by package

Per-package coverage and bundle size on this PR. New-line coverage = of the source lines this PR adds or changes, the % hit by tests.

Package	Coverage	New-line coverage	Packed (gzip)	Unpacked	vs main
@uipath/apollo-core	—	—	42.02 MB	50.17 MB	±0
@uipath/apollo-react	58.1%	50.0% (1/2)	8.14 MB	32.17 MB	+7 B
@uipath/apollo-ui-icons	—	—	2.86 MB	6.97 MB	±0
@uipath/apollo-vertex	—	—	—	—	—
@uipath/apollo-wind	—	—	810.7 KB	4.68 MB	−5 B
@uipath/ap-chat	85.8%	—	40.42 MB	45.71 MB	−12 B

_{"Coverage" is each package's own coverage.include scope (e.g. apollo-core instruments only scripts/). "Packed"/"Unpacked" come from npm pack --dry-run and only cover built packages — "—" means not measured this run (package not affected / not built). "vs main" is the packed (gzipped) delta against the last successful main build (the package-sizes artifact from the Release workflow); "—" there means no main baseline was available this run. The baseline is main's latest build, not this PR's exact merge-base, so it includes any drift since the branch diverged. Packages with no vitest config are omitted.}

[github-actions]

Storybook visual diff

⚠️ Visual changes detected: 5 changed (of 268 compared, 263 unchanged). View report

Baseline is the deployed main Storybook, so changes merged to main after this branch was last updated can also appear here. Logs

Updated (PT): Oct 23, 2026, 12:58:08 AM

[Copilot]

🟢 Approval recommended

The changes are narrowly scoped, match existing catalog entries, and have no identified blocking issues.

No open issues 🎉

_{Review effort: Balanced}

[Copilot]

🟢 Approval recommended

The changes are limited to catalog-aligned defaults, placeholders, and message IDs, with no identified logic or public API regressions.

No open issues 🎉

_{Review effort: Balanced}