[RESEARCH] Internationalize small content pieces within elements.

[Westbrook]

Code of conduct

• I agree to follow this project's code of conduct.

Description of issue

Smaller tools like https://github.com/shoelace-style/localize#readme allow for customization of small pieces of a component library.

Larger tools like https://github.com/lit/lit/tree/main/packages/localize might imply that we should take a position on internationalization for our consumers as well.

Find a solution to covering the few cases where we're shipping content within our components that needs to be translated without surfacing superfluous properties for this action.

[Westbrook]

Includes:

• OverlayTrigger, post action button a11y #1907
• Toast, IIRC
• Search, IIRC
• etc.

[jnurthen]

Any update on thoughts for this? It seems like one of the major obstacles to supporting accessibility well in languages other than English.

[Westbrook]

We still intend to work on this. It is indeed quite important, but seemingly not important enough for any of our consuming teams to push for it to be prioritized above other things. Always happy to support a contribution in this area or a discussion that might change priorities in a way that supported addressing this work more actively.

[jnurthen]

The following components would currently be broken when translated (probably not exhausative):

• Asset (default hardcoded but can be overridden)
• SplitButton (aria-label of split hardcoded to More)
• Dialog (hardcoded close button label)
• NumberField (hardcoded increase/decrease buttons)
• Picker (hardcoded visually hidden dismiss button)
• Search (hardcoded Reset button)
• Tag (hardcoded Remove button)
• Toast (hardcoded Information/Error/Success Icon & Close button)

[majornista]

Color Slider currently has the string "hue", which can be overwritten using the label prop:

spectrum-web-components/packages/color-slider/src/ColorSlider.ts

Line 57 in a447ba2

public label = 'hue';

Color Area currently uses "saturation" and "luminosity", which can be overwritten using the labelX and labelY props respectively:

spectrum-web-components/packages/color-area/src/ColorArea.ts

Lines 53 to 60 in a447ba2

	@property({ type: String })
	public label: string | undefined;
	@property({ type: String, attribute: 'label-x' })
	public labelX = 'saturation';
	@property({ type: String, attribute: 'label-y' })
	public labelY = 'luminosity';

For Color Area, it may be better to include the color channel names as part of the aria-valuetext for each of the inputs, so that the user aware of which channel their interaction changed, and we should include additional strings:

• 'Color Picker' as the default aria-label for each of the input[type="range"] elements, which should be concatenated with whatever label the user provides, so that the control announces something like "Foreground Color Picker".
• '2d slider' as the aria-roledescription for each of the input[type="range"] elements, so that he user gets some indication of the keyboard behavior for the control and understands that keyboard interaction changes values in two dimensions.

This is similar to the way a Color Picker is labelled on Windows, and is what we do in the React-Spectrum color area. See https://react-spectrum.adobe.com/react-aria/useColorArea.html#internationalization