<scribe> scribe: becka11y
<CharlesL> https://github.com/w3c/personalization-semantics/issues/133
charles: we are keeping our notes for the review in issue #133
<CharlesL> https://w3c.github.io/i18n-drafts/techniques/shortchecklist
charles: let's go through this
checklist together and answer the questions
... question asks if spec contains natural language there must
be metadata about direction etc
... all agree that we don't have natural language in module
1
<CharlesL> If the spec (or its implementation) allows content authors to produce typographically appealing text, either in its own right, or in association with graphics
charles: Don't believe we have any issues with this?
JF: what about the reverse? In use case where we use symbols to represent large chunks of content - it isn't typographically appealing but is modifying the content. Do symbol sets have localized gramma?
SL: symbol sets are generally localized themselves - specific to the locale; some symbols have to be changed to be locally accurate
JF: we use the numberic symbol
from bliss set - is that going to be a problem down the
road?
... tech that evolves from our spec will allow for modification
of the text to make it more appealing to the user
... use of symbols seems to be more of a translation
Charles: perhaps flag this and ask for I18N for guidance
SL: symbol id and language code
may be useful
... Bliss is a language in its own right so there is no
translation
<CharlesL> Other than Symbol Sets but localized themselves, and we are using numerical values so we don't think this is an issue but request you look at this closer.
<CharlesL> [URI to spec symbol add here]
<CharlesL> Other than translation to Symbol sets we are using numerical token which can be mapped to multiple symbols, so we don't think this is an issue but request you look at this closer. And the symbol sets themselves may be localized.
<CharlesL> [URI to spec symbol add here]
<CharlesL> We are using numerical token 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.
<CharlesL> [URI to spec symbol add here]
<CharlesL> 3. _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._
make allowances for the ways different scripts handle units of text
JF: we are not handling units of text, we are not changing the units of text
Charles: even with simplification?
JF: our spec doesn't provide the ability to modify or manipulate text
SL: aren't we providing the changes in the same language
<CharlesL> Simplification allows for replacing sections of text with an alternative text, which the author will provide.
SL: we are allowing the author to provide alternatives
<janina> +1
JF: we are providing metadata to facilitate modification but does not impose it
Janina: we are facilitating alternative versions so is up to the author to follow these rules
<CharlesL> 4. _If the spec (or its implementation) allows searching or matching of text, including syntax and identifiers_
<CharlesL> understand the implications of normalisation, case folding, etc
Janina: we identify the search
ability but do not perform the actual searching
... just say it doesn't apply
<CharlesL> 5. [ ] _If the spec (or its implementation) sorts text_
Janina: it does not apply
<CharlesL> 6. [ ] _If the spec (or its implementation) captures user input_
We don't capture any user input
<CharlesL> N/A
<CharlesL> 7. [ ] _If the spec (or its implementation) deals with time in any way that will be read by humans and/or crosses time zone boundaries_
Janina: localization is the responsibility of the implementor; we don't have any affect on localization
<CharlesL> 8. [ ] _If the spec (or its implementation) allows any character encoding other than UTF-8._
Janina: we are orthagonal to anything I18n is concerned about - we are "internationalizing" in a way that hasn't been considered before
JF: at some point we want to also provide UTF-16 - we may want to support an alternative symbol set
Janina: good point - we do need to consideer
JF: there is no reason why a user
agent couldn't look up and translate to the UTF-16
... we envision support for UTF-16 and nothing in our spec that
frustrates that support
Janina: agreed
<CharlesL> We support UTF-8 but we anticipates supporting UTF-16 and there is nothing in our spec that would prevent this.f
Janina: aren't we using the bliss number to translate between different symbol sets?
JF: we anticipate other symbol sets will map against the Bliss numbers
<CharlesL> We support UTF-8 but we anticipates supporting UTF-16 for symbol sets and there is nothing in our spec that would prevent this.
others agree
<CharlesL> 9. [ ] _If the spec (or its implementation) defines markup._
<CharlesL> ... ensure support for internationalisation features and avoid putting human-readable text in attribute values or plain-text elements
Janina: we don't define any
markup
... we are putting text in our attribute values?
becky: so how are our token strings define - is this considered human-readable?
<CharlesL> We do define markup as tokens that are human readable tokens that we don't expect that to be localized.
do we have text replacements in module 1?
charles: yes, simplification
<CharlesL> We do define markup as tokens that are human readable tokens that we don't expect to be localized. However we do have simplification that does have alternative text description.
<CharlesL> 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 simplification that does have alternative text description.
<CharlesL> 10. [ ] _If the spec (or its implementation) deals with names, addresses, time & date formats, etc_
<CharlesL> .. ensure that the model is flexible enough to cope with wide variations in format, levels of data, etc
Charles: we are pointing out where these things are
JF: is an authoring concern;
autocomplete attribute does support i18n and we are modeling
after that
... our data-purpose attribute has been modeled after the
autocomplete attribute of HTML5
<CharlesL> data-purpose attribute does pattern after autocomplete attribute of HTML5 and author is responsible for any internationalization concern
<CharlesL> 11. [ ] _If the spec (or its implementation) describes a format or data that is likely to need localization._
<CharlesL> ... ensure that there’s an approach in place which allows effective storage and labelling of, and access to localised alternatives for strings, text, images, etc
becky: just the same as the answer above
<CharlesL> 12. [ ] _If the spec (or its implementation) makes any reference to or relies on any cultural norms_
<CharlesL> ensure that it can be adapted to suit different cultural norms around the world (ranging from depictions of people or gestures, to expectations about gender roles, to approaches to work and life, etc).
JF: as Steve pointed out - there are internationalized symbol sets to address that concern
Janina: and we are supporting
those translations
... add AAC in front of symbols
<CharlesL> there are internationalized AACsymbol sets to address that concern. and we are supporting those translations
Charles: this is homework for the
next few weeks - probably no meeting next week do to CSUN
... there is a filter on the content module; would like to
assign a few each TF member a few issues to go through and
address
... only 14 open issues - so we should each grab a couple
<CharlesL> https://github.com/w3c/personalization-semantics/labels/content%20module
Charles: perhaps address the ones
we opened ourselves
... if you didn't submit any - please grab some that have been
submitted by others; Everyone please address a few issues in
this content module list
This is scribe.perl Revision: 1.154 of Date: 2018/09/25 16:35:56 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Present: stevelee JF janina becky CharlesL Regrets: Lisa No ScribeNick specified. Guessing ScribeNick: becky Found Scribe: becka11y Found Date: 02 Mar 2020 People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]