Accessibility ​

...

Localization ​

...

The currently supported languages and locales are:

  • en - English
  • en-UK - English (UK)
  • en-US - English (US)
  • es - Spanish
  • ca - Catalan/Valencian
  • gl - Galician
  • eu - Basque
  • de - German
  • nl - Dutch
  • da - Danish
  • ar - Arabic
  • fr - French
  • pl - Polish
  • th - Thai
  • ur - Urdu
  • hi - Hindu
  • vi - Vietnamese
  • ta - Tamil
  • it - Italian
  • pt - Portuguese
  • ko - Korean
  • jp - Japanese
  • id - Indonesian
  • zh - Chinese

This list of locales is available in:

ts
import { LOCALES } from "@zurich/dev-utils/code";

The acquisition chain (from more relevant to least) on the locale value is:

  • The instance locale attribute.
  • The lang attribute of the <html> tag.
  • The navigator.language value.

We offer some WebComponent that help you with the localization:

Localized inputs ​

The are some inputs that might be affected for the localization. These are basically the ones related to date, time and numbers. This localization is done by the native <input> element by using the user's OS' or Browser's localization settings. This is done in order to accommodate the input of data to the final user's preferences. Here's the explanation of the standard about the topic and the reasoning for this to be a desirable behavior.

With that said, some of our WebComponents offer the possibility of forcing the localization with some tradeoffs (like not being capable of using the numerical manipulation and having to use the date picker).

Attention!

We recommend not to use force localization for inputs for many reasons. So even when we offer the possibility for satisfying possible use cases, we strongly encourage you to think about the real need of forcing the localization.

NumberInput ​

We won't localize the NumberInput because of the incompatibilities that this can cause. locale will only affect here the units display.

DateInput ​

We can check this in DateInput:

This approach doesn't affect the model, but only the display. In Arab, the numeric representation is different:

There are cases that the whole system might be weird:

In Thailand they use the year zero as the year in which the Buddha attained parinibbāna. That's why, in this situation, we need todo a value conversion to other localizations.

TimeInput ​

Also for TimeInput, where in this case, localization only makes sense for the 12h format:

Even with seconds:

The localization, in the vast majority of cases, makes only sense if you want to represent a 12h format. Otherwise, the re presentation doesn't change.

A11y validation ​

Visual validator for WebComponents ​

Attention!

This is still a WIP PoC. Only a few attributes are working!

Using @zurich/web-components, we can use a visual tooling during the development to check if we cover all the accessibility requirements. We just need to import the a11y.css stylesheet:

css
@import "@zurich/web-components/a11y.css";

This will display this frames in the web components indicating the issues: