Use a real i18n key for the comment collapse toggle

[feruzm]

Fixes #1502

The collapse toggle on a muted / low-reputation comment called i18next.t("chat.hide-message"). That key exists in no locale, so i18next echoed it and the raw chat.hide-message string rendered next to "Author of this content has low reputation." The expand side was fine (discussion.reveal / discussion.reveal-muted).

Adds discussion.hide to en-US.json and points the toggle at it.

Tests: discussion-item.spec.tsx now renders a low-reputation comment and asserts both toggle labels resolve to a string in en-US.json. It fails against chat.hide-message and passes with the fix.

[coderabbitai]

Warning

Review limit reached

@feruzm, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 59 minutes

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: fe6808bd-c3cf-4c5b-98c2-67a2c8371bc8

📥 Commits

Reviewing files that changed from the base of the PR and between 9d1d9cf and bb0de9c.

📒 Files selected for processing (3)

• apps/web/src/features/i18n/locales/en-US.json
• apps/web/src/features/shared/discussion/discussion-item.tsx
• apps/web/src/specs/features/shared/discussion-item.spec.tsx

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Fix comment collapse toggle to use valid i18n key

🐞 Bug fix 🧪 Tests 🕐 20-40 Minutes

AI Description

• Add missing discussion.hide string to the English locale.
• Fix DiscussionItem to use discussion.hide instead of an undefined chat.hide-message key.
• Add a regression test ensuring both toggle labels resolve to defined locale strings.

Diagram

graph TD
  A["DiscussionItem (UI)"] --> B["Collapse toggle label"] --> C["i18next.t(key)"] --> D["en-US.json locale"]
  E["discussion-item.spec.tsx"] --> A --> C

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Enable missing-key detection in i18next (CI/runtime)

• ➕ Catches undefined keys across the entire app, not just this component
• ➕ Prevents shipping raw keys even when tests don’t cover a view
• ➖ Requires wiring i18next missingKeyHandler / logging and deciding failure policy
• ➖ May be noisy until existing missing keys are cleaned up

2. Introduce type-safe i18n keys (generated key union)

• ➕ Compile-time prevention of invalid keys like chat.hide-message
• ➕ Improves refactor safety when renaming/relocating keys
• ➖ Additional tooling/codegen complexity
• ➖ Requires ongoing maintenance as locales evolve

Recommendation: The PR’s approach is the correct immediate fix: add the missing discussion.hide key and reference it consistently from the toggle. Consider a follow-up to add automated missing-key detection (CI/runtime or a broader test) to prevent undefined translation keys from shipping elsewhere.

Files changed (3) +37 / -1

Bug fix (2) +2 / -1

en-US.jsonAdd 'discussion.hide' translation string +1/-0

Add 'discussion.hide' translation string

• Adds the 'discussion.hide' key to the discussion namespace in the English locale. This provides a real translation target for the collapse toggle label.

apps/web/src/features/i18n/locales/en-US.json

discussion-item.tsxUse 'discussion.hide' for the collapse toggle label +1/-1

Use 'discussion.hide' for the collapse toggle label

• Replaces the invalid 'chat.hide-message' translation key with 'discussion.hide' when rendering the collapse state of the toggle. Keeps the reveal-side logic unchanged and aligned with existing 'discussion.reveal*' keys.

apps/web/src/features/shared/discussion/discussion-item.tsx

Tests (1) +35 / -0

discussion-item.spec.tsxAdd regression test to ensure toggle keys exist in en-US locale +35/-0

Add regression test to ensure toggle keys exist in en-US locale

• Imports the shipped 'en-US.json' locale and adds a helper to resolve dotted keys. Adds a test that renders a low-reputation comment, captures the reveal and hide keys emitted by the mocked i18next, and asserts both resolve to defined strings in the locale.

apps/web/src/specs/features/shared/discussion-item.spec.tsx

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. getLocaleValue uses explicit any ✓ Resolved 📘 Rule violation ⚙ Maintainability

Description

The new locale traversal helper introduces reduce, adding an explicit any type to the modified
TypeScript test file. This violates the requirement to use explicit, non-any types in new or
modified TypeScript code.

Code

apps/web/src/specs/features/shared/discussion-item.spec.tsx[R90-93]

+function getLocaleValue(key: string) {
+  return key
+    .split(".")
+    .reduce<any>((acc, part) => (acc == null ? acc : acc[part]), enUS as Record<string, unknown>);

Relevance

●●● Strong

Team often removes newly introduced any in specs; similar requests were accepted in prior test/TS
changes.

PR-#865
PR-#1484

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The changed test helper explicitly declares reduce. The checklist prohibits new explicit any
usage in modified TypeScript files and permits unknown or properly typed generics instead.

Rule 2668119: Disallow implicit and any types in new TypeScript code
apps/web/src/specs/features/shared/discussion-item.spec.tsx[90-93]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new `getLocaleValue` helper uses `reduce<any>`, introducing an explicit `any` type in modified TypeScript code.
## Issue Context
The helper traverses imported JSON by dotted key and should preserve type safety while returning an unknown locale value.
## Fix Focus Areas
- apps/web/src/specs/features/shared/discussion-item.spec.tsx[90-93]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. getLocaleValue uses explicit any ✓ Resolved 📘 Rule violation ⚙ Maintainability

Description

The new locale traversal helper introduces reduce, adding an explicit any type to the modified
TypeScript test file. This violates the requirement to use explicit, non-any types in new or
modified TypeScript code.

Code

apps/web/src/specs/features/shared/discussion-item.spec.tsx[R90-93]

+function getLocaleValue(key: string) {
+  return key
+    .split(".")
+    .reduce<any>((acc, part) => (acc == null ? acc : acc[part]), enUS as Record<string, unknown>);

Relevance

●●● Strong

Team often removes newly introduced any in specs; similar requests were accepted in prior test/TS
changes.

PR-#865
PR-#1484

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The changed test helper explicitly declares reduce. The checklist prohibits new explicit any
usage in modified TypeScript files and permits unknown or properly typed generics instead.

Rule 2668119: Disallow implicit and any types in new TypeScript code
apps/web/src/specs/features/shared/discussion-item.spec.tsx[90-93]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new `getLocaleValue` helper uses `reduce<any>`, introducing an explicit `any` type in modified TypeScript code.
## Issue Context
The helper traverses imported JSON by dotted key and should preserve type safety while returning an unknown locale value.
## Fix Focus Areas
- apps/web/src/specs/features/shared/discussion-item.spec.tsx[90-93]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Tip of the day

💡 Did you know, you can turn on the rule miner and Qodo learns your standards from review history

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📜 Skill insights (0)

1. getLocaleValue uses explicit any ✓ Resolved 📘 Rule violation ⚙ Maintainability

Description

The new locale traversal helper introduces reduce<any>, adding an explicit any type to the
modified TypeScript test file. This violates the requirement to use explicit, non-any types in new
or modified TypeScript code.

Code

apps/web/src/specs/features/shared/discussion-item.spec.tsx[R90-93]

+function getLocaleValue(key: string) {
+  return key
+    .split(".")
+    .reduce<any>((acc, part) => (acc == null ? acc : acc[part]), enUS as Record<string, unknown>);

Relevance

●●● Strong

Team often removes newly introduced any in specs; similar requests were accepted in prior test/TS
changes.

PR-#865
PR-#1484

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The changed test helper explicitly declares reduce<any>. The checklist prohibits new explicit
any usage in modified TypeScript files and permits unknown or properly typed generics instead.

Rule 2668119: Disallow implicit and any types in new TypeScript code
apps/web/src/specs/features/shared/discussion-item.spec.tsx[90-93]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new `getLocaleValue` helper uses `reduce<any>`, introducing an explicit `any` type in modified TypeScript code.

## Issue Context
The helper traverses imported JSON by dotted key and should preserve type safety while returning an unknown locale value.

## Fix Focus Areas
- apps/web/src/specs/features/shared/discussion-item.spec.tsx[90-93]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Context

✅ Compliance rules (platform): 82 rules

✅ Skills: 6 invoked

  add-feature

  add-query

  add-sdk-mutation

  add-test

  code-review

  debug

Review mode: 🚀 Fast: This is a localized, low-risk i18n key correction with a focused regression test and no security, API, schema, or broad behavioral impact.

Tip of the day

💡 Did you know, you can turn on the rule miner and Qodo learns your standards from review history

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[feruzm]

Thanks, applied in bb0de9c: getLocaleValue no longer uses reduce<any>. It reduces over unknown, narrows with a typeof acc !== "object" guard before indexing, and returns unknown, so the assertions still do the work without an explicit any in the spec.

Test still fails against chat.hide-message and passes with discussion.hide. Typecheck clean.