[i18n-activity] Internal bidi considerations for screen label (#1638)

aphillips has just created a new issue for https://github.com/w3c/i18n-activity:

== Internal bidi considerations for screen label ==
## Proposed comment

2.1 Screen
https://www.w3.org/TR/window-placement/#screen-label

> A [screen](https://www.w3.org/TR/window-placement/#screen) has a label, which is a string that meaningfully describes the screen to a user to help them identify and differentiate screens.
>
> Note: The [label](https://www.w3.org/TR/window-placement/#screen-label) can be an arbitrary string selected by the user agent. It could describe the screen relative to the device, e.g. "internal" vs. "external", it could include the dimensions, e.g. "640×480", it could include hardware model information, e.g. "Acme Telletube 1000x" from [VESA E-EDID](https://en.wikipedia.org/wiki/Extended_Display_Identification_Data) data, it could include a distinguishing number, e.g. "screen 1" vs. "screen 2", or all of the preceding. The label can be an empty string if underlying display details are unknown or the user agent chooses to hide that information. Applications can’t assume that the label contains any specific information, such as the device type, model, dimensions, density, etc.

The discussion of the content of the label do not mention the potential for other languages. I18N would expect that this API, when queried on systems running with various locales, would return labels either in the operating system/user-agent's locale or in the locale of the page/query context.

One effect of this for labels that are in a right-to-left language, such as Arabic, Hebrew, and some others, is that the name may not display correctly, particularly if it is generated by the system from tokens or values. Spillover effects can happen when text that has mixed left-to-right and right-to-left text are used in a larger sentence. This is particularly true for device labels because they often feature tokens such as brand names ("Dell", "HP", etc.), part numbers ("S2721H", "A157-B", etc.), device capabilities ("75 Hz", "4ms", etc.), or resolution (1024x768) that use ASCII letters, digits, and punctuation. This often leads to mixed direction names such as:

> Brand A123B (1920 x 1080) 36" monitor 75 Hz, 4ms, built-in speakers

Or in Arabic:

> ماركة A123B (1920 x 1080) 36" شاشة الكمبيوتر, 75 Hz, 4 مللي ثانية, مكبرات صوت مدمجة

![image](https://user-images.githubusercontent.com/69082/212205735-42602e5b-d10e-40d6-b603-cab441152800.png)

(Notice how `36` and `"` are separated, the resolution is potentially backwards, `75 Hz` and `4ms` both separate the number from the measurement--there are other mix-ups in the Arabic that will only be visible to Arabic speakers).

We would suggest adding a mention of the need to emit a "bidirectionally clean" string (using bidi control characters and the like). For example, you could add a sentence just before this one in the Note:

> The label can be an empty string if underlying display details are unknown or the user agent chooses to hide that information. 

saying something like:

> If the label contains or might contain [= bidirectional text =], care should be used to ensure that the string will display correctly without the application needing to process the string. For more information see [here](https://www.w3.org/International/questions/qa-bidi-unicode-controls)

Note that the [= =] would be a link to the i18n-glossary, specifically [here](https://www.w3.org/TR/i18n-glossary/#def_bidirectional_text)


## Instructions: 

This follows the process at https://w3c.github.io/i18n-activity/guidelines/review-instructions.html

1. Create the review comment you want to propose by replacing the prompts above these instructions, but **LEAVE ALL THE INSTRUCTIONS INTACT** 

2. Set a label to identify the spec: this starts with s: followed by the spec's short name. If you are unable to do that, ask a W3C staff contact to help.

3. Ask the i18n WG to review your comment.

4. After discussion with the i18n WG, raise an issue in the repository of the WG that owns the spec. Use the text above these instructions as the starting point for that comment, but add any suggestions that arose from the i18n WG. In the other WG's repo, add an 'i18n-needs-resolution' label to the new issue. If you think any of the participants in layout requirements task force groups would be interested in following the discussion, add also the appropriate i18n-\*lreq label(s).

5. Delete the text below that says 'url_for_the_issue_raised', then add in its place the URL for the issue you raised in the other WG's repository. Do NOT remove the initial '§ '. Do NOT use \[...](...) notation – you need to delete the placeholder, then paste the URL.

6. Remove the 'pending' label, and add a 'needs-resolution' tag to this tracker issue. 

7. If you added an \*lreq label, add the label 'spec-type-issue', add the corresponding language label, and a label to indicate the relevant typographic feature(s), eg. 'i:line_breaking'. The latter represent categories related to the Language Enablement Index, and all start with i:.

8. Edit this issue to **REMOVE ALL THE INSTRUCTIONS & THE PROPOSED COMMENT**, ie. the line below that is '---' and all the text before it to the very start of the issue.

---


**This is a tracker issue.** Only discuss things here if they are i18n WG internal meta-discussions about the issue. **Contribute to the actual discussion at the following link:**


§ url_for_the_issue_raised


Please view or discuss this issue at https://github.com/w3c/i18n-activity/issues/1638 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 13 January 2023 00:16:23 UTC