EPUB 3 Working Group Telco — Minutes

Date: 2021-02-04

See also the Agenda and the IRC Log

Attendees

Present: Shinya Takami (高見真也), Toshiaki Koike, Masakazu Kitahara, Dave Cramer, Matthew Chan, Teenya Franklin, Marisa DeMeglio, Brady Duga, Wendy Reid, Garth Conboy

Regrets:

Guests:

Chair: Dave Cramer

Scribe(s): Wendy Reid

Content:

Dave Cramer: 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
… first one is #1499

1. What should be the default value for the dir attribute

See github issue #1499, #1491.

See github pull request #1498.

Dave Cramer: Also going to talk about 1491 because they’re related
… there is also a PR addressing this (#1498)
… 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 attribute
… 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

Brady 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

Dave Cramer: I don’t want to worry about the HTML situation
… there are 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

Brady Duga: The scarier thing is the inherent directionality of the text winning over the dir attribute

Dave Cramer: I wonder that too
… went down a rabbit hole
… stared into the abyss…

Brady Duga: If there’s an inherent directionality, it wins over dir, dir might mean nothing

Dave Cramer: 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 resolution: Add the default value of auto to the dir attribute, resolved 1491 and 1499 (Wendy Reid)

Resolution #1: Add the default value of auto to the dir element, resolved 1491 and 1499

Dave Cramer: We got it! Moving on to 1494

2. Relationship between dir and the content

See github issue #1494.

Dave Cramer: i18n self test says what is in the ticket
… spec specifies that directionality in unicode takes precedence
… over the dir attribute
… Matt says if there’s strong directionality in the text, that takes precedence
… dir doesn’t control everything
… see r12a’s comments
… 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?

Ben Schroeter: The change being that dir wins?

Dave Cramer: Removing the line that says strings can override dir

Brady 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”

Dave Cramer: This is a lesson, if you get that deep into it, it’s confusing

Proposed resolution: Fix 1494 by removing the untrue statement about the relationship between dir and the underlying text (Wendy Reid)

Resolution #2: Fix 1494 by removing the untrue statement about the relationship between dir and the underlying text

3. Additional ‘refines’ values?

See github issue #1493.

Dave Cramer: 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

Brady Duga: I agree with Matt

Dave Cramer: Me too
… anyone else?
… I would propose we close the issue, there’s nothing for us to do here

Proposed resolution: Close 1493 as we cannot fix this issue (Wendy Reid)

Resolution #3: Close 1493 as we cannot fix this issue

4. Assuming direction from language

See github issue #1490.

Dave Cramer: 1490, do not assume that direction can be assumed from language information
… but then we have PR 1498

See github pull request #1498.

Brady Duga: If we accept 1498, we don’t care about this, according to the comments

Dave Cramer: Not to mention the i18n folks who have commented
… this one is kind of moot

Brady Duga: Will not fix, obsolete

Proposed resolution: close 1490 because mooted by PR 1498 (Dave Cramer)

Resolution #4: close 1490 because mooted by PR 1498

5. Extra explanations on the effects of the dir attribute

See github issue #1489.

Dave Cramer: 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

Brady 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

Dave Cramer: is it safe to have non-normative text?

Brady Duga: The comment was a brief overview of a complicated issue
… we could put a generic pointer

Dave Cramer: 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

Brady Duga: Is there a lot of usage for this?

Dave Cramer: 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 resolution: Close 1489, we have met the i18n requirements (Wendy Reid)

Resolution #5: Close 1489, we have met the i18n requirements

Dave Cramer: Moving on…

6. Missing hreflang attribute

See github issue #1488.

Dave Cramer: 1488
… missing hreflang attribute
… see issue
… there is a PR from Matt

See github pull request #1497.

Dave Cramer: 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?

Ben Schroeter: Trying to understand the usage of this?

Dave Cramer: 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

Ben Schroeter: Ok

Dave Cramer: I’m not aware of a RS that does this

Brady Duga: You can link to external metadata records? /sarcasm

Dave Cramer: We can write a test for it, but no RS will test it

Ben Schroeter: And where will you find a Norwegian-Canadian dictionary…

Brady Duga: This PR does add another untestable conformance requirement

Dave Cramer: 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 resolution: Close 1488, accept PR 1497 (Wendy Reid)

Resolution #6: Close 1488, accept PR 1497

Dave Cramer: Progress!
… on i18n issues at least
… thanks everyone

Teenya Franklin: goodnight

Dave Cramer: see you all in the comment section

Dave Cramer: RRSAgent: draft minutes

Dave Cramer: RRSAgent: bye

7. Resolutions