[paynejd]

What changed

The update-comment button on the concept edit form (Actions → Edit concept → Update comment) named the assistant generically. Its tooltip said "Generate with AI", its accessible name said "Generate comment with AI", and the alert for a missing assistant URL said "AI assistant is not configured for this environment." These strings now name the OCL AI Assistant in all four catalogs (en, es, pt-BR, zh), using the form each catalog already uses for that name in its other strings (for example the quota strings).

Key	en before	en after
concept.ai_assistant_not_configured	AI assistant is not configured for this environment.	The OCL AI Assistant is not configured for this environment.
concept.generate_comment_aria	Generate comment with AI	Generate comment with the OCL AI Assistant
common.generate_with_ai	Generate with AI	Generate with the OCL AI Assistant

In the other catalogs the name reads:

• es: "el asistente de IA de OCL", e.g. "Generar comentario con el asistente de IA de OCL";
• pt-BR: "o Assistente de IA do OCL", e.g. "Gerar comentário com o Assistente de IA do OCL";
• zh: "OCL AI 助手", e.g. "使用 OCL AI 助手生成评论".

Only catalog values change. Keys, code, {{params}} and tags are untouched.

One string beyond the ticket's list: common.generate_with_ai. It is the visible tooltip of the same button whose aria-label the ticket names. MUI also copies it onto the button wrapper's aria-label, so screen readers announce it too, and this button is its only use. Fixing only the aria-label would have left sighted users reading "Generate with AI". If it should stay as it was, revert that one line in each catalog.

Word choices:

• es: the design-system glossary's Spanish entry for this name is still open. It lists "OCL Asistente de IA" and notes that "Asistente de IA de OCL" may read more naturally. I matched the six es strings already in this catalog ("asistente de IA de OCL"). If the entry settles on another form, all es strings should change together.
• pt-BR: the ticket's criteria name en, es and zh, but this repo's process covers every locale. pt-BR uses the glossary's pt-BR form ("Assistente de IA do OCL"), in the sentence pattern the catalog already uses.

How I tested it

1. Naming check: fails on main, passes here. A Node script walks every string in the four catalogs and flags:

   • "AI recommendations";
   • the assistant named without OCL: en "AI Assistant" not preceded by "OCL", es "asistente de IA" not followed by "de OCL", pt-BR "Assistente de IA" not followed by "do OCL", zh "AI 助手" not preceded by "OCL";
   • a generic "with AI" credit: "with AI", "con IA", "com IA", "使用 AI".

   Results:

   • On origin/main: FAIL, 12 hits (the three keys above in each of the four catalogs).
   • On this branch: PASS, 0 hits.

   A one-line equivalent for English: grep -rniE 'AI recommendations|AI assistant' src/i18n/locales/ | grep -viE 'OCL AI assistant' prints the old alert string on main and nothing on this branch.

2. PR gate. These are pr.yml's run: steps, as written, on Node 22, in a clean export of the commit:

   • the secret-shaped variable check: OK;
   • npm ci: OK;
   • ./node_modules/eslint/bin/eslint.js --ext .jsx,.js src/: exit 0.

3. Headless browser check. This used Playwright with Chromium and a fresh context for each run, against npm start pointed at the staging API.

   • Steps: open a concept in a public source, choose Actions → Edit concept, and change External ID to enable the button. Hover the button, then clear the assistant URL and click it to raise the alert.
   • Coverage: each locale (en, es, pt-BR, zh, set through ocl.language) at 1440×900 and 390×844. I recorded the button's aria-label, the tooltip and the alert, before and after the change, and looked at every screenshot.
   • Result: all 8 runs show the new strings. At 390 px the tooltips stay on one line inside the viewport, and the longest alert (pt-BR) wraps to two readable lines.

   Notes on the setup:

   • The assistant button renders only when an assistant URL is configured, so the check set a placeholder URL in the page. Nothing was sent to it.
   • The "not configured" alert can't normally be reached, because the button is hidden when there is no URL. The check reached it by clearing the URL just before the click.
   • The edit form needs a user with edit rights. The check used a stand-in user that existed only in the test browser. Every request to the API went without credentials, and only as a GET.
   • For zh, the test browser had to work around an unrelated crash; see "Noticed, not fixed".

4. PR checks on this PR: pr.yml's Eslint job passed (run), and the Snyk check reported no manifest changes.

Review

• Codex defect review (codex-cli 0.162.1): one pass, clean, with 0 findings.
• Simplification review (a fresh Claude subagent): 1 proposed cut, tagged reuse. I kept the code as it is, so nothing changed after review and no check of cuts was needed.
• Both full reports are on the tracking ticket.

Acceptance criteria (restated)

• The two strings the ticket names (concept.ai_assistant_not_configured, concept.generate_comment_aria) name the OCL AI Assistant in en, es and zh, and in pt-BR too. Evidence: the diff, and the browser check's recorded aria-label and alert text in all four locales.
• The locale catalogs contain no "AI recommendations" and no "AI Assistant" without OCL. Evidence: the naming check passes on this branch (0 hits) and fails on main (12 hits).
• Ships with the next TBv3 release, with no release of its own. This PR changes no version, workflow or deploy file, so it ships when the next release after the merge is approved. That can't be ticked from here.

Docs

None needed. No README, doc or code comment quotes these strings, and src/i18n/README.md still points to the localization guide this change follows.

Not done, on purpose

• I didn't add the naming check to CI. It would catch regressions, but a new CI step is beyond this ticket.
• I didn't touch the localization guide's open Spanish entry.

Noticed, not fixed

• A stored zh language blanks the app. LANGUAGES in src/common/constants.js lists en, es and pt-BR but not zh, while src/i18n/config.js accepts zh as a stored language. With ocl.language set to zh, UserMenu reads selectedLanguage.name of undefined and the whole app renders blank. The language menu doesn't offer zh, so today only a hand-set value triggers it. For the zh browser check, the test browser added a zh entry to the served dev bundle. Nothing in this PR changes that code.
• At 390 px the concept edit form's split layout squeezes the left column. It looks the same before and after this change.

closes OpenConceptLab/ocl_online#438

🤖 Generated with Claude Code

https://claude.ai/code/session_01KWwyGAxP3a8Cp7gQEnkVQT

Written by an Octoad session worker (worker-v0.11, recipe lean-loop, flow private>public, run openconceptlab-ocl-online-438-20261012-144244).

[paynejd]

Codex defect review: summary (codex-cli 0.162.1, commit b004bb7)

One pass was needed. It came back clean: 0 findings (P0: 0, P1: 0, P2: 0, P3: 0). Nothing changed as a result. The full report is on the tracking ticket.

[paynejd]

Simplification review: summary (fresh Claude subagent, commit b004bb7)

It proposed 1 cut (tagged reuse) and no defects. I kept the code as it is, so nothing changed and no check of cuts was needed. The PR gate (pr.yml's steps, Node 22) was run again on b004bb7 and passed. The full report is on the tracking ticket.