Meeting minutes
<dauwhe> Date: 2021-02-04
<shiestyle> sorry, but read only today.
dauwhe: Welcome everyone, today we'll be talking about internationalization
… Ivan went through the i18n questionnaire
… filed a number of issues he encountered while performing the review
… some of the members of the WG replied
… we should go through the issues and make some decisions
<dauwhe> https://
dauwhe: first one is #1499
<dauwhe> https://
issue, 1499
<dauwhe> https://
dauwhe: Also going to talk about 1491 because they're related
… there is also a PR addressing this
… most of the i18n issues we face are in HTML, SVG, CSS, where we rely on those specs
… our area of influence is the package doc
… the dir element
… it doesn't have a default value
… some guidance from i18n says we should have a default of "auto"
… lets the system decide what to do, which depends on them, and can be overwritten by rtl or ltr
… we have a PR open to address this
… Matt has added this
… is this a good idea and will it break anything
… ltr = left to right
… rtl = right to left
duga: I think there is some history we want to keep with HTMLs LTR by default
… for our case it makes sense to use auto because that's how things work now
… the default is auto
… HTML doesn't have a default, but the root is LTR, but it also has more complex inheritance
dauwhe: I don't want to worry about thr HTML situation
… there's complexities
… it seems to me that adding auto is risk free as a default
… I can't imagine writing a test where something would happen
duga: The scarier thing is the inherent directionality of the text winning over the dir element
dauwhe: I wonder that too
… went down a rabbit hole
… stared into the abyss...
duga: If there's an inherent directionality, it wins over dir, dir might mean nothing
dauwhe: base paragraph direction over the bits of text within
… atomic elements of the package file that have no instructions
… instinct to have auto as a nice to have
… doesn't change existing behaviour
… the only person who needs to worry is the tester
… I would propose we resolve to add the auto value
… does anyone object
Proposed: Add the default value of "auto" to the dir element, resolved 1491 and 1499
Resolution: Add the default value of "auto" to the dir element, resolved 1491 and 1499
<dauwhe> https://
dauwhe: We got it! Moving on to 1494
… i18n self test says *what is in the ticket*
… spec specifies that directionality in unicode takes precedence
… over the dir element
… Matt says if there's strong directionality in the text, that takes precendence
… dir doesn't control everything
<dauwhe> https://
dauwhe: r12a comments (see link)
… what Richard says there makes sense
… we need to remove that line in the spec stating that unicode directionality takes precedence
… it would conflict with the guidance from Richard
… address the issue by having Matt removing that bit and clarifying the text
… the relationship between the string and the dir attribute
… any opposition?
BenSchroeter: The change being that dir wins?
dauwhe: Removing the line that says strings can override dir
duga: I don't think anyone knows what it means
… dir sets the base direction
… but it has nothing to do with unicode for instance
… the unicode API does that
… we're reaching
… we should just say "this is what dir does"
dauwhe: This is a lesson, if you get that deep into it, it's confusing
Proposed: Fix 1494 by removing the untrue statement about the relationship between dir and the underlying text
<dauwhe> https://
dauwhe: We'll resolve by PR
… 1493, <span> should provide data for the interpretation of text
… we are stuck with the DC terms language
… which we can't control
… we've used "refines" before
… there's a lot of examples from Japan regarding sorting and pronunciation of names
… we can't make this change to EPUB
… we have these mechanism
… if there's an important use case comes up that doesn't fit with what we already have
… we'll address it, but we shouldn't try to create something without that information
duga: I agree with Matt
dauwhe: Me too
… anyone else?
… I would propose we close the issue, there's nothing for us to do here
Proposed: Close 1493 as we cannot fix this issue
Resolution: Close 1493 as we cannot fix this issue
<dauwhe> https://
dauwhe: 1490, do not assume that direction can be assumed from language information
… but then we have PR 1498
duga: If we accept 1498, we don't care about this, according to the comments
dauwhe: Not to mention the i18n folks who have commented
… this one is kind of moot
duga: Will not fix, obsolete
<dauwhe> Proposed: close 1490 because mooted by PR 1498
<dauwhe> https://
dauwhe: 1489, it must be possible to indicate changes in bidirectional text for the user
… we're talking mostly about DC terms here
… there's no inline markup
… there's unicode marker characters for this
… should we add some explanation that you need to use the unicode characters to do it
… I'm generally in favour of putting useful info into the spec
… provides clues to us when we go back to this
duga: I think that's the reason we added the comment about inherent directionality
… if we start talking about unicode conformance it can get confusing
… we could look at HTML and see what they say
dauwhe: is it safe to have non-normative text?
duga: The comment was a brief overview of a complicated issue
… we could put a generic pointer
dauwhe: We should probably avoid this as we don't understand it well
… something obvious to us might be wrong, unlikely to be helpful
… this is not our lane
duga: Is there a lot of usage for this?
dauwhe: I've so far been unable to change behaviour of a RS by changing the dir attribute
… I would propose we close this, as we do meet the requirements
Proposed: Close 1489, we have met the i18n requirements
Resolution: Close 1489, we have met the i18n requirements
dauwhe: Moving on...
<dauwhe> https://
dauwhe: 1488
… missing href-lang attributre
… *see issue*
… there is a PR from Matt
<dauwhe> https://
dauwhe: PR 1497
… this is designed for the links in the package file
… if we're linking to external metadata, we can determine the language of the file
… consistent with other vocabularies
… this would be new, and wouldn't break anything
… any comments?
BenSchroeter: Trying to understand the usage of this?
dauwhe: Say you have a multi-lingual epub, multiple metadata records
… norwegian canadian dictionary that has one record in norwegian and one in canadian english
… if the UI is set in one language, it can know to present the correct metadata to the user
… the RS doesn't have to determine the vocab from the resource, it can determine before download
… a hint
BenSchroeter: Ok
dauwhe: I'm not aware of a RS that does this
duga: You can link to external metadata records? /sarcasm
dauwhe: We can write a test for it, but no RS will test it
BenSchroeter: And where will you find a norwegian-canadian dictionary
duga: This PR does add another untestable conformance requirement
dauwhe: I feel we're a little bit stuck here
… it's an i18n best practice
… if we say we're going to have linked metadata, we should have this
… we put this in, we get tests, the concept gets marked as at-risk at CR
… I think we should accept the PR, then see what testing shows us
Proposed: Close 1488, accept PR 1497
Resolution: Close 1488, accept PR 1497
dauwhe: Progress!
… on i18n issues at least
… thanks everyone
<Teenya> goodnight
dauwhe: see you all in the comment section
<dauwhe> RRSAgent: draft minutes