Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Internationalisation concerns #258

Open
r12a opened this issue Feb 2, 2021 · 1 comment
Open

Internationalisation concerns #258

r12a opened this issue Feb 2, 2021 · 1 comment
Labels
i18n-tracker Group bringing to attention of Internationalization, or tracked by i18n but not needing response. openui-site This represents that it has to do with the site, not specifications stale

Comments

@r12a
Copy link
Collaborator

r12a commented Feb 2, 2021

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.)

Screenshot 2021-02-02 at 18 46 30

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 #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:

Screenshot 2021-02-02 at 19 51 15

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.

@plehegar plehegar added the i18n-tracker Group bringing to attention of Internationalization, or tracked by i18n but not needing response. label Feb 3, 2021
@github-actions
Copy link

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.

@github-actions github-actions bot added the stale label Mar 19, 2022
@mfreed7 mfreed7 added the openui-site This represents that it has to do with the site, not specifications label Mar 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
i18n-tracker Group bringing to attention of Internationalization, or tracked by i18n but not needing response. openui-site This represents that it has to do with the site, not specifications stale
Projects
None yet
Development

No branches or pull requests

3 participants