fix: project nav width in different language

[MonsPropre]

Description

Fix width for project dropdown menu

Related Issue(s)

N/A

Type of Change

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Refactoring (no functional changes)
• Performance improvement
• Test addition or update
• Other (please describe):

How Has This Been Tested?

• Unit tests
• Integration tests
• Manual testing
• Other (please describe):

Screenshots (if applicable)

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I understand and take responsibility for every change, and I wrote this pull request description in my own words
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published

Additional Notes

N/A

Summary by CodeRabbit

• Style
  • Updated the project dropdown menu to use an automatic width, allowing it to better fit its content.

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

PR Summary by Qodo

Fix project dropdown width for localized project names

🐞 Bug fix 🕐 Less than 5 minutes

AI Description

• Make project dropdown menu auto-size to fit longer translated labels
• Prevent text truncation/overflow in the project switcher navigation

Diagram

graph TD
  A["NavProjects"] --> B["DropdownMenuContent"] --> C["Tailwind width"]
  subgraph Legend
    direction LR
    _ui["UI component"] ~~~ _style["Styling"]
  end

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Use min/max width constraints

• ➕ Prevents extremely wide menus for unusually long project names
• ➕ More consistent UI across projects
• ➖ Requires picking reasonable bounds and may still truncate some locales
• ➖ Slightly more CSS/iteration to tune

2. Use width based on trigger (w-[--radix-dropdown-menu-trigger-width])

• ➕ Aligns menu width with the trigger for a consistent look
• ➕ Avoids runaway widths while still being dynamic
• ➖ May still be too narrow for longer translations
• ➖ Depends on component/variable support and may need extra setup

Recommendation: Using w-auto is a pragmatic fix for localization-driven overflow because it directly sizes the dropdown to its content with minimal risk. If the menu can become excessively wide in real usage, consider adding a max-w-* (and wrapping/ellipsis) as a follow-up UI constraint.

Files changed (1) +1 / -1

Bug fix (1) +1 / -1

nav-projects.tsxAuto-size project dropdown menu width +1/-1

Auto-size project dropdown menu width

• Changes the dropdown menu content width from a fixed 'w-44' to 'w-auto' so the menu can expand to fit longer localized labels. This prevents truncation/overflow in languages with longer strings.

apps/web/src/components/nav-projects.tsx

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 7c6600c7-c816-47b9-98db-2a5ed4150df0

📥 Commits

Reviewing files that changed from the base of the PR and between 012778e and 2974f6c.

📒 Files selected for processing (1)

• apps/web/src/components/nav-projects.tsx

Included review availability: Your plan provides up to 8 included reviews per hour; 7 remain after this review.

---

📝 Walkthrough

Walkthrough

The project dropdown content changes from fixed width w-44 to automatic width w-auto.

Changes

Project navigation dropdown

Layer / File(s)	Summary
Automatic dropdown width apps/web/src/components/nav-projects.tsx	The project dropdown content uses w-auto instead of w-44.

Estimated code review effort: 1 (Trivial) | ~2 minutes

Merge Risk: ⚪ Minimal · up to 2974f

This localized change adjusts the project dropdown width for different languages and introduces no actionable merge-blocking risk beyond normal checks and review.

Suggested reviewers: andrejsshell, rojensonlugo

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 1 functions across 1 files.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly identifies the fix to project navigation width for different languages.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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]

Code Review by Qodo

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

1. Min-width unintentionally removed 🐞 Bug ≡ Correctness

Description

NavProjects sets DropdownMenuContent to "w-auto", which matches MenuPopup’s "[class*='w-']" check
and disables the component’s built-in "min-w-32" fallback. This can make the menu shrink narrower
than before and increases the chance of wrapped labels being visually clipped given the fixed "h-7"
menu item heights in this dropdown.

Code

apps/web/src/components/nav-projects.tsx[R281-283]

+                              className="w-auto rounded-lg"
                              side={isMobile ? "bottom" : "right"}
                              align={isMobile ? "end" : "start"}

Evidence

The PR introduces w-auto on DropdownMenuContent. In the shared MenuPopup implementation, the
default minimum width (min-w-32) is only applied when the provided className does not contain
w-; therefore w-auto disables that safeguard and can lead to narrower popups than intended.

apps/web/src/components/nav-projects.tsx[261-284]
apps/web/src/components/ui/menu.tsx[55-74]

Agent prompt

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

### Issue description
`NavProjects` changed the project context dropdown width from a fixed `w-44` to `w-auto`. In `MenuPopup` (aliased as `DropdownMenuContent`), a default `min-w-32` is applied **only** when the consumer does *not* provide any class containing `w-`. Because `w-auto` contains `w-`, the default minimum width is now disabled, which can cause overly narrow popups and wrapping/clipping regressions.

### Issue Context
- `MenuPopup` has a conditional Tailwind rule: `not-[class*='w-']:min-w-32`.
- Adding `w-auto` is effectively redundant (divs are `width: auto` by default), but it changes behavior by suppressing the default min width.

### Fix Focus Areas
- apps/web/src/components/nav-projects.tsx[280-284]
- apps/web/src/components/ui/menu.tsx[55-74]

### Suggested fix
Use one of these approaches:
1) Remove the explicit width class entirely and rely on the shared default min width:
  - change `className="w-auto rounded-lg"` -> `className="rounded-lg"`

2) If you want to preserve the old minimum while allowing growth for longer translations, set a min-width explicitly:
  - e.g. `className="min-w-44 rounded-lg"` (and do **not** use a fixed `w-*`).

Option (2) most closely keeps the previous baseline width while still fixing long-language truncation/wrapping.

ⓘ 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 tweak Display preferences with a live preview to see your comment before it ships

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

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

1. Min-width unintentionally removed 🐞 Bug ≡ Correctness

NavProjects sets DropdownMenuContent to "w-auto", which matches MenuPopup’s "[class*='w-']" check
and disables the component’s built-in "min-w-32" fallback. This can make the menu shrink narrower
than before and increases the chance of wrapped labels being visually clipped given the fixed "h-7"
menu item heights in this dropdown.

Agent Prompt

### Issue description
`NavProjects` changed the project context dropdown width from a fixed `w-44` to `w-auto`. In `MenuPopup` (aliased as `DropdownMenuContent`), a default `min-w-32` is applied **only** when the consumer does *not* provide any class containing `w-`. Because `w-auto` contains `w-`, the default minimum width is now disabled, which can cause overly narrow popups and wrapping/clipping regressions.

### Issue Context
- `MenuPopup` has a conditional Tailwind rule: `not-[class*='w-']:min-w-32`.
- Adding `w-auto` is effectively redundant (divs are `width: auto` by default), but it changes behavior by suppressing the default min width.

### Fix Focus Areas
- apps/web/src/components/nav-projects.tsx[280-284]
- apps/web/src/components/ui/menu.tsx[55-74]

### Suggested fix
Use one of these approaches:
1) Remove the explicit width class entirely and rely on the shared default min width:
   - change `className="w-auto rounded-lg"` -> `className="rounded-lg"`

2) If you want to preserve the old minimum while allowing growth for longer translations, set a min-width explicitly:
   - e.g. `className="min-w-44 rounded-lg"` (and do **not** use a fixed `w-*`).

Option (2) most closely keeps the previous baseline width while still fixing long-language truncation/wrapping.

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

[randoneering]

@MonsPropre thank you for the contribution. Can you take a look at this comment and decide if you want to implement it? If you do not, please provide your reasoning. Thanks!