Internationalisation concerns

https://open-ui.org/ calls out the need to check for accessibility requirements, but doesn't mention internationalisation requirements.

To do that, we'll need to fully specify the component parts, states, and behaviors of the built-in controls, as well as necessary accessibility requirements, and provide test suites to ensure compatibility.

Forms may need to look and behave differently for international users, and i hope that the group will make efforts to consider what aspects of their work are affected by those. I'm not proposing anything specific other than that the group charter and descriptions should make it clear that the group will investigate whether international requirements affect the use of these component parts, states, and behaviors of the built-in controls.

Here, fwiw, are just a few examples of how requirements for form design can differ around the world. It's only a handful of cases, but maybe it will help create some thoughts around the topic.

TEXT MAY BE VERTICAL
In languages such as Japanese and Chinese, and especially Traditional Mongolian (which has no horizontal tradition), the arrangement of panels and the direction of text needs to be very different. Here are some examples for CJK, where text is vertical and lines flow from right to left. (For Mongolian, the lines flow LTR.)

The necessary positioning and orientation of the parts of these forms is only supported by Gecko at the moment. If it were possible to indicate the intended direction for the primitives used to build these form controls, might that improve?

TEXT MAY BE RIGHT-TO-LEFT OR BIDIRECTIONAL
I saw the discussion at https://github.com/WICG/open-ui/issues/174, but the implications here go much further than relative positioning of labels to controls. At least, i would hope that the group ensures that their output recommendations don't block any of the things that international users would want to be able to achieve via the styling and markup that is available to them. For example, it worries me to see words like 'left' and 'right' in the control descriptions – they should probably be replaced by 'start' and 'end', etc. to avoid unconscious bias.

RTL (and actually, bidirectional) text also affects the relative placement of the structures that make up a form control, esp. for controls that are composed of multiple parts, side by side, such as 'or' buttons, or 'group' buttons. Also sliders probably need to be flexible, direction-wise.

Some of the button icons at https://open-ui.org/components/button have a directional bias, eg. the meaning of the following:

There are also requirements for users to be able to switch between base directions while entering text, and to capture the direction of a form so that it can be sent with the data (dirname).

Tabulated data, such as date pickers, cards, clearable select components, tabs, and tables, badge positions, etc may need to be reversible.

LOCAL DATA FORMATS MAY BE DIFFERENT
People use different conventions, components, ordering and symbols to express dates & times, addresses, even names. They may use different digits and number formats, different currency types, etc. None of this should be unintentionally blocked by the solutions proposed.

Date pickers may need to start with different days of the week, and allow for different default calendars, and switching between calendars.

Colours may need to be adaptable to match local cultural preferences.

ALPHABETS & TYPOGRAPHIC FEATURES MAY DIFFER
The use of a B icon at https://open-ui.org/components/button is only really appropriate if it represents a word that contains a Latin B, and in fact there are cultures where bolded text is rarely used, either because they have different traditions or because it's difficult to apply bold (or italic) styles to the letters.

Traditionally, in certain Japanese contexts a check mark means incorrect, and a circle is used where we would apply a check mark. The icons used for check marks and crosses should be easily adaptable.

Other i18n requirements relate to search strategies, overflow directions, case (which doesn't exist for the majority of writing systems, but has a number of wrinkles for those that do have it), icon design, etc.

Start by reviewing the group charter and the component descriptions referenced in the issue, then assess the listed internationalisation concerns across built-in controls. Done means the group's scope and recommendations clearly address whether international requirements affect component parts, states, behaviors, styling, and markup without blocking international users.