Additional Proposed Responses to I18N review

Here proposals for 5 additional responses from our I18N review.  To make it easier to find each question, I have added 5 dashes (-----) before each question. 
thanks for any further input.
-becky

-----
Question:
If the spec (or its implementation) allows the user to point into text, creates text fragments, concatenates text, allows the user to select or step through text (using a cursor or other methods), etc.
Our answer: Simplification allows for replacing sections of text with an alternative text, which the author will provide.

I18N response:
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).

Proposed response: 
Correct, 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. This may include the replacement of text but the author of the alternative text is responsible for any internationalization of that text. The author of the alternative text is the assisstive technology. The original content author just identifies the sections that may need simplifying.

Becky’s comment. I think the reviewers were a bit confused about why we referred to alternative text. Perhaps because we referred to it as the “author’s” responsibility. I think we meant that to be assistive technology or author of the alternative text??
End Question

-----
Question:
 If the spec (or its implementation) allows any character encoding other than UTF-8.
Our Answer: We support UTF-8 but we anticipates supporting UTF-16 for symbol sets and there is nothing in our spec that would prevent this.

I18N response: 
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?

Proposed Response:
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 could support a symbol set developed using unicode character values from a UTF-16 character set. Or a double byte set that was developed using private use characters.

Becky’s comment:  I’m not sure if I got this one quite right or expressed it well.

-----
Question:
If the spec (or its implementation) defines markup.
Our Answer: 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.

I18N Response:
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.

Proposed Response: 
We do not currently propose any attribute values that contain natural language. All current proposed attribute values are static text. In the case of simplification, the assistive technology uses the attribute value to determine the level of simplification needed. The assistive technology is then responsible for performing any alternative text needed for simplification of the content and for adhering to the current localization requirements.  For symbol sets, we are relying on a mapping table of numbers to identify characters. The mapping table for a specific symbol set will account for any localization differences. 

Becky’s comment: If we need to update the checklist we should remove the last sentence of our answers to eliminate the information about alt text. I believe that has confused the issue.  The response to this question would be:
We do define attribute names and values as tokens that are human readable but they do not require localization.

-----
Question: If the spec (or its implementation) deals with names, addresses, time & date formats, etc

Our response: The data-purpose attribute does pattern after autocomplete attribute of HTML5 and author is responsible for any internationalization concerns.

I18N response: 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 :-).

Proposed response:
We have opened a new issue, https://github.com/w3c/personalization-semantics/issues/138 <https://github.com/w3c/personalization-semantics/issues/138>, to discuss the possibility of importing the fields by reference.  Thank you for making us aware of the potential issues and evolution of the HTML spec in this area. 

-----
Question:
 If the spec (or its implementation) makes any reference to or relies on any cultural norms
Our answer: There are internationalized AAC symbol sets to address that concern. and we are supporting those translations

I18N response: 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?

Becky’s comment:  I think we may have confused the issue but referencing symbol sets.  I think our response should just have been N/A.  The spec itself does not reference or rely on any cultural norms. However, I believe our answer to the I18N question about localization of symbol sets may be sufficient for this question as well. See the mailing list item for a discussion of our response to the localization of symbol sets:  https://lists.w3.org/Archives/Public/public-personalization-tf/2020Mar/0015.html <https://lists.w3.org/Archives/Public/public-personalization-tf/2020Mar/0015.html>