Closed clapierre closed 3 years ago
r12a
commented
4 years ago Removing i18n labels since we don't need to track this issue.
Also, note that only the i18n WG should assign (or remove) the i18n-needs-resolution label (read the label description).
clapierre
commented
4 years ago Short i18n review checklist is here
N/A.
We are using numerical tokens which can be mapped to symbols sets, so we don't think this is an issue but request you look at this closer. Also the symbol sets themselves may be localized. [URI to spec symbol add here]
Simplification allows for replacing sections of text with an alternative text, which the author will provide. [URL to this section]
N/A
N/A
N/A
N/A
We support UTF-8 but we anticipates supporting UTF-16 for symbol sets and there is nothing in our spec that would prevent this.
We do define attribute names and values as tokens that are human readable but we don't expect those to be localized. However we do have content simplification that does have alternative text descriptions. [URI to Simplification]
data-purpose attribute does pattern after autocomplete attribute of HTML5 and author is responsible for any internationalization concerns.
data-purpose attribute does pattern after autocomplete attribute of HTML5 and author is responsible for any internationalization concerns.
there are internationalized AAC symbol sets to address that concern. and we are supporting those translations
clapierre
commented
4 years ago Here is the I18N Review Request https://github.com/w3c/i18n-request/issues/110
aphillips
commented
4 years ago (Responding on behalf of the I18N WG)
Thank you for using our new process and for completing a self-review. We really appreciate it!
I'm going to review your checklist comments first, then add some general comments about your specification. My comments are based on the 2020-01-27 Editor's copy. Specific comments about the text itself will be created as separate issues after the I18N WG reviews them internally.
We are using numerical tokens which can be mapped to symbols sets, so we don't think this is an issue but request you look at this closer. Also the symbol sets themselves may be localized.
Replacing a word with a number (which is used to obtain the symbol) initially seems okay. There are two things that immediately spring to mind to think about, though. First, the use of numbers is extended in one example to spell the phrase "cup of tea" (with each word taking one symbol). This depends strongly on the grammar of the language being recoded into symbols; I would have expected the symbols to have their own (somewhat language neutral) grammar. Second, it should be noted that symbols themselves have strong cultural associations and the same symbol might represent different concepts or be unacceptable in a different context. This kind of issue is one of the frequent (and difficult!) considerations when encoding emoji characters and how it is dealt with here will be interesting to understand.
Simplification allows for replacing sections of text with an alternative text, which the author will provide.
It doesn't appear that this spec defines how "sections of text" are selected or created. Our concerns here generally have to do with how text is broken into subcomponents (such as words).
We support UTF-8 but we anticipates supporting UTF-16 for symbol sets and there is nothing in our spec that would prevent this.
This statement is unclear. UTF-8 and UTF-16 are character encoding forms of the Unicode character set. That is, they are different ways of turning characters into bytes in the memory of a computer. Can you clarify what you mean by UTF-16 for symbol sets here? Do you mean "Unicode code points" or "private use characters" perhaps?
We do define attribute names and values as tokens that are human readable but we don't expect those to be localized. However we do have content simplification that does have alternative text descriptions.
Names and values (when used in the way that you are defining here) should never be localized. We will probably make some observations about some of the attribute values, but your core assumption is fine.
When you say "alternative text descriptions", you mean that the simplification is used to replace existing natural language in the text, correct? Note that some natural language in markup documents (such as HTML) appears in attributes. Do you have a scheme for "simplifying" that text? Also, might the language and base direction of the text being simplified affect the interpretation of the symbols? There doesn't appear to be language or direction metadata associated with the symbol regime.
data-purpose attribute does pattern after autocomplete attribute of HTML5 and author is responsible for any internationalization concerns.
This section contains many potential issues for I18N, but these are mainly external to your spec (as you call out). Is there a way for you to not need to duplicate that spec's keywords, etc. and just import the fields by reference? You'll have to avoid breakage as we work with them or as their spec evolved :-).
there are internationalized AAC symbol sets to address that concern. and we are supporting those translations
Can you expand on this? I'm not sure I understand the relationship here. Are you saying this spec only covers a specific language or region AAC symbol set?
becka11y
commented
4 years ago ** DRAFT Response - NOT reviewed by the Personalization TF, yet
We are using numerical tokens which can be mapped to symbols sets, so we don't think this is an issue but request you look at this closer. Also the symbol sets themselves may be localized.
Replacing a word with a number (which is used to obtain the symbol) initially seems okay. There are two things that immediately spring to mind to think about, though. First, the use of numbers is extended in one example to spell the phrase "cup of tea" (with each word taking one symbol). This depends strongly on the grammar of the language being recoded into symbols; I would have expected the symbols to have their own (somewhat language neutral) grammar. Second, it should be noted that symbols themselves have strong cultural associations and the same symbol might represent different concepts or be unacceptable in a different context. This kind of issue is one of the frequent (and difficult!) considerations when encoding emoji characters and how it is dealt with here will be interesting to understand.
We are facilitating the translation via a fixed set of numbers to represent each symbol. While we are using the BLISS symbol numbers as our reference, makers of other symbols sets will provide the mapping to their own set. The assistive technology will use the mapping table for the current user’s culturally appropriate symbol set. Given the example of two symbols for cup of tea, another symbol set may have only one symbol to represent the same concept. If so, the mapping table would map the two numbers together into its own single symbol. If the author refers only to “tea,” and is not specific that it is a cup the mapping may be different. It is the responsibility of the creators of the mapping table to understand the nuances of the languages and how the symbols relate to one another. Thus, one symbol may map to multiple, grouped symbols. Or, vice versa, multiple, grouped symbols may map back to only one. It is the responsibility of the creators of the mapping table and the assistive technology to understand the nuances of the language and to translate to the culturally appropriate symbol.
Simplification allows for replacing sections of text with an alternative text, which the author will provide.
It doesn't appear that this spec defines how "sections of text" are selected or created. Our concerns here generally have to do with how text is broken into subcomponents (such as words).
We should have been more specific in our answer. The Simplification specification provides specific attribute values that specify the level of simplification needed. The assistive technology is responsible for providing the necessary modifications to meet the user’s needs. The original content author just identifies the sections that may need simplifying. Future specifications may require author provided alternative text and we will address this issue further.
We support UTF-8 but we anticipates supporting UTF-16 for symbol sets and there is nothing in our spec that would prevent this.
This statement is unclear. UTF-8 and UTF-16 are character encoding forms of the Unicode character set. That is, they are different ways of turning characters into bytes in the memory of a computer. Can you clarify what you mean by UTF-16 for symbol sets here? Do you mean "Unicode code points" or "private use characters" perhaps?
We are not recommending one symbol set or another, we are just providing the translation. We allow translation to other character sets that may be represented by UTF-8, UTF-16, private use characters or even actual images.
We do define attribute names and values as tokens that are human readable but we don't expect those to be localized. However we do have content simplification that does have alternative text descriptions.
Names and values (when used in the way that you are defining here) should never be localized. We will probably make some observations about some of the attribute values, but your core assumption is fine.
When you say "alternative text descriptions", you mean that the simplification is used to replace existing natural language in the text, correct? Note that some natural language in markup documents (such as HTML) appears in attributes. Do you have a scheme for "simplifying" that text? Also, might the language and base direction of the text being simplified affect the interpretation of the symbols? There doesn't appear to be language or direction metadata associated with the symbol regime.
We were hasty in referring to content simplification that has alternative text descriptions. At this time there is no author-supplied alternative text. Any simplification is performed by the assistive technology and it is responsible for translation and localization.
data-purpose attribute does pattern after autocomplete attribute of HTML5 and author is responsible for any internationalization concerns.
This section contains many potential issues for I18N, but these are mainly external to your spec (as you call out). Is there a way for you to not need to duplicate that spec's keywords, etc. and just import the fields by reference? You'll have to avoid breakage as we work with them or as their spec evolved :-).
We incorrectly stated that we pattern data-purpose after the autocomplete attribute values of HTML5. We are basing the values off of WCAG 2.1. Specifically, Section 7. Input Purposes for User Interface Components. At this point, the listing matches HTML5 but may diverge in the future. If it does, we will follow WCAG 2.1. We will investigate a way to refer to the fields by reference.
If the spec (or its implementation) makes any reference to or relies on any cultural norms
there are internationalized AAC symbol sets to address that concern. and we are supporting those translations
To be more specific, the spec itself does not make any reference to or rely upon any cultural norms. The assistive technologies are responsible for the culturally appropriate personalization/simplification.
aphillips
commented
4 years ago @becka11y Thanks for starting to review our comments. I have been tasked by the I18N WG with breaking my comments above into separate issues in your repo (the better to track individual items and develop threads of discussion). I'm putting this note here to inform you and the TF of my intention to do this and so that hopefully the TF is not surprised to see a sudden barrage of comments from us.
In the course of doing this, I may add replies to some of your proposed responses (where it appears that clarification from us would help you/the TF have a better discussion or where it appears that my comment may have been unclear).
The Internationalization (I18N) Working Group have changed our process for requesting horizontal review. We believe these changes will make it easier, more consistent, and more reliable when making requests to us.
Previously you needed to send emails to specific people/lists. Starting today, you should instead file a github issue in this repo: https://github.com/w3c/i18n-request/
This repo contains our review radar, where you can see and track progress on your specifications reviews: https://github.com/w3c/i18n-request/projects/1
It also contains a set of issue templates for requesting review: https://github.com/w3c/i18n-request/issues/new/choose
Instructions for how to “Request a review” have been updated and are found here: https://www.w3.org/International/review-request
As well as in the section "How to get horizontal review" in the wiki here: https://www.w3.org/wiki/DocumentReview#How_to_get_horizontal_review
These are also linked to from The Guide under 'wide review' https://www.w3.org/Guide/#Deliverables
Let Richard (ishida@) or me know if you have any questions or comments.
Thanks!
Addison
Addison Phillips Sr. Principal SDE – I18N (Amazon) Chair (W3C I18N WG)