[upstream] CKEditor 5 language selector cannot be scrolled if "All NNN languages" option selected

Thanks for reporting this!

But … this is a duplicate of an issue that is 95% done, can you help get it to 100%? 😊

Transferring issue credit! 👍

Looking at ✨ Third option for the CKEditor 5 "Language" button: `site_configured` (in addition to `un` and `all`) RTBC I think there's a really good suggestion here, but it's not what #3273986 implements. I hadn't seen this issue, but I wondered about the same option when working on the other.

In #3273986 we let the user select "configured" to show the list of Languages configured at /admin/config/regional/language. ("configured" was shorthand for "Site's configured languages" but I'm suddenly thinking it's not a clear name.)

In #3375157 ID @jonathan_hunt is suggesting a configurable list of languages for use managed I think from the CKEditor plugin configuration - for some sites I do think this might make sense.

I will factor that into naming the setting over in ✨ Third option for the CKEditor 5 "Language" button: `site_configured` (in addition to `un` and `all`) RTBC in case this issue gets implemented as well. The other issue will have some tests and such to build on at least :)

I'd say this issue is still valid as the dropdown menu is still very user unfriendly, when scrolling the languages.

Agreed, re-titling to focus on the specific scrolling issue & moving back to NW.

I suppose there could also be a search filter at the top of the list, which is friendlier than scrolling. An editor could start typing the desired language name into that field and only the matches would show, likely to be a short list. That said, it depends on how the languages are displayed. If they are displayed in their native name rather than the website administration language, typing the name could be an issue, for example, if the editor is trying to retrieve traditional Chinese but can only type in Latin characters.

@Charles Belov that's an alternative approach to the one proposed in the issue description (which is fine to do, but the ID remains unchanged). It looks to me like that interface is provided by CKEditor so might be worth thinking about whether CK offers such a filterable dropdown element to use.

From within Drupal, we can do things such as limit available options (as proposed in ID).

Fixing scrolling or providing a different UX may require proposing changes upstream in CK.

Thanks for re-scoping & re-titling! 👍

However, in this case … there's indeed nothing to fix on the Drupal side — it can only be fixed upstream. Can you please create an upstream bug report? 🙏

I found a fix that makes us less dependent from the cke community providing a fix: CSS, hooray :-)

.ck-dropdown__panel.ck-dropdown__panel-visible {
  overflow: scroll;
  max-height: var(--ck-min-height);
}

This is the result of a browser mockup based on Claro. Might need a higher specificity.

I opened an upstream issue: https://github.com/ckeditor/ckeditor5/issues/15715

The suggested fix inspired by #11 could be added to our admin theme CSS as a workaround.

.ck-text-fragment-language-dropdown .ck-dropdown__panel {
  overflow-x: auto;
  max-height: var(--ck-dialog-max-height);
}

FYI upstream issue was closed as duplicate of https://github.com/ckeditor/ckeditor5/issues/952