I'm concerned that when looking at a single component we might set ourselves up for missing trans-component issues and requirements. Simple example: Tabbing handling in several components from different software projects in a view/on a page.

Noting some i18n issue that come to mind:

Font-size & line height across different language fonts
The typeahead suggestion box usually has an associated max-height, which is designed to fix a certain amount of text without cutting it off . That height varies across languages, so we have to pick a font-size & line-height that accommodate the broadest range of languages.

RTL support, in combination with an eventual language picker
CSSJanus takes care of most RTL concerns, but if we want to include a language picker beside the search box, what happens when someone switches the search from English to Arabic? Will the search input, along with the search-suggestion items switch to RTL? (p.s. I just noticed this does not happen on www.wikipedia.org)

(I think a storybook instance would be excellent for visualizing the search box across languages).

In regards to a11y, my instinct says that the search-suggestions should be invisible to screen-readers, as they could be very interruptive, but it would be nice if they were keyboard accessible (maybe using arrow keys?)

@Jdrewniak I've been considering your wikipedia.org implementation as the definitive reference with feed in from the other implementations you identified. /cc @holger.knust

The typeahead suggestion box usually has an associated max-height,

Maybe I am misunderstanding your point but is this true? Consistent line height sounds good but I don't see any kind of truncation done on the suggestion container. E.g., check out the height of "Digital object identifier" as compared to "D":

(p.s. I just noticed this does not happen on www.wikipedia.org)

What is the ideal behavior? Flipping the results but not the rest of the form?

(I think a storybook instance would be excellent for visualizing the search box across languages).

+1!

maybe using arrow keys

That sounds nice to me. I saw similar advice here.

The typeahead suggestion box usually has an associated max-height,

Maybe I am misunderstanding your point but is this true? Consistent line height sounds good but I don't see any kind of truncation done on the suggestion container. E.g., check out the height of "Digital object identifier" as compared to "D":

haha your right there is no line clamping! 😅 I guess as far as I got with that was writing this comment (but I think that decision is probably more design oriented than i18n or a11y).

@Jdrewniak @Volker_E it seems some of this is done? Can acceptance criteria be marked as done where it's done and could work done be summarized?
I would like to understand what's left and if it's a blocker for closing out T249298

I think the a11y concerns have been thoroughly considered in the search typeahead implementation (I think it may be a good idea to get an a11y audit of this feature after it's been deployed, but I think that's a separate task?). The i18n considerations have also been addressed by using the https://www.npmjs.com/package/vue-banana-i18n plugin, and RTL flipping will be handled by ResourceLoader when the feature will be integrated into Vector.

So we can resolve and create a task to do an a11y audit?
I assume that should be a subtask of T240489 ?