I was thinking about this some more and here are some ideas:

1. Make the group selector x axis scrollable incase there are long message group names:

The drawback with this approach is that seeing the full name for a long message group would require scrolling which would then hide the other normal sized message groups

2. Add scroll for the long items in the group select. See:

This makes scrolling through message groups with long names, but otherwise does not impact the usability.

3. Make long menu items pop out from the dropdown when the user hovers over them.

Something like this:

This solution would not be the most straight forward to implement.

@Pginer-WMF Thoughts? Or any other ideas?

In T322780#8462599, @abi_ wrote:

@Pginer-WMF Thoughts? Or any other ideas?

From what is proposed above, I think the best approach is 1, make the whole panel scrollable when there are results that are out of the viewport.
Adding individual scroll (2) or showing the whole message on demand (3) require to act on individual items (users would have to perform an action on several items in the "wikilearn" scenario illustrated above) and break the dialog metaphor.

In addition to (1), there are some other small adjustments that can be considered:

• Make the selector wider for the "All" level. One option could be making the current 600px to become the min-width and set the width to 70% of the available space (70%, 70vw or similar). Note that we may want to apply this to the first level ("All") since nested levels add indentation that would result in the selector to move out of the viewport more easily.
• For items with a longer title, use a smaller font (14p instead of 16px)

These would make the horizontal scroll of the panel to appear on more rare cases.

What about simply not preventing the browser from breaking the line?

This may require switching to native flexbox or grid layout from the current float-based hack, but I think it’s acceptable in 2022. (I just overwrote a bunch of random CSS rules for the sake of this screenshot, which is why the search field is broken. I don’t propose to break it in production, of course.)

In T322780#8466935, @Tacsipacsi wrote:

What about simply not preventing the browser from breaking the line?

I was considering that, but titles based on the scenario above (searching for "wikilearn") were getting really long, so the wrapping would result in items with 3-4 lines of text that may become also harder to distinguish from each other.

In this example there are over a hundred items like these:

• WikiLearn/Courses/course-v1:Wikimedia-Foundation+wmf commdev partnerships cg+2022/en/block-v1:Wikimedia-Foundation+wmf commdev partnerships cg+2022+type@chapter+block@373bfa97abd94289867b293b7c7cad2d
• WikiLearn/Courses/course-v1:Wikimedia-Foundation+wmf commdev partnerships cg+2022/en/block-v1:Wikimedia-Foundation+wmf commdev partnerships cg+2022+type@chapter+block@5b35b150b9f74f2aa754ef7b1ee6b43b
• WikiLearn/Courses/course-v1:Wikimedia-Foundation+wmf commdev partnerships cg+2022/en/block-v1:Wikimedia-Foundation+wmf commdev partnerships cg+2022+type@chapter+block@67906aca6779481699e611a6a8889908

When items follow a path-like name schema the identifiers to distinguish each item are at the end. Once you identify the block of elements with the relevant common part, you can scroll to the right and find the specific identifier (e.g., "block@5b35b150b9f74f2aa754ef7b1ee6b43b"). With wrapping you'd have to skip some items as you look for the right element.

Other more sophisticated approaches such as limiting the wrapping to 2 lines and use ellipses in the middle could be considered, but they tend to be harder to implement for covering extreme cases like these.

The scenario described in the task description is such an edge case that while it should be possible to distinguish these entries, I don’t think we should optimize for them. Moderately long titles (like the “A letter of thanks…” in my screenshot) look much better IMO when broken in multiple lines than when horizontally scrollable. Also, if people regularly need to distinguish these 32-digit hexadecimal IDs, then something’s fundamentally wrong with WikiLearn or the translatable bundle system – these IDs are for computers, not for people.

See also T332682: Allow message group title to be specified in message bundle metadata which should solve this as well as making the message group names more usable.

I wouldn’t say T332682 solves this. It makes it much less visible, but since both titles specified in message bundle metadata and titles of translatable pages can be made long and hardly distinguishable, the issue remains.