Skip to content

Added an I18N section to §2 of the RS - #1613

Merged
mattgarrish merged 5 commits into
mainfrom
rs-i18n
Apr 9, 2021
Merged

Added an I18N section to §2 of the RS #1613
mattgarrish merged 5 commits into
mainfrom
rs-i18n

Conversation

@iherman

@iherman iherman commented Apr 6, 2021

Copy link
Copy Markdown
Member

Fix #1601

See:

Added an I18N section to the RS
@iherman
iherman requested review from dlazin and mattgarrish April 6, 2021 08:45
Comment thread epub33/rs/index.html Outdated
Comment thread epub33/rs/index.html Outdated
Comment thread epub33/rs/index.html Outdated
Comment thread epub33/rs/index.html Outdated
@iherman

iherman commented Apr 8, 2021

Copy link
Copy Markdown
Member Author

@mattgarrish can we merge this?

@mattgarrish

Copy link
Copy Markdown
Member

Aren't we still missing an important piece about what to do when language information isn't provided in the resource? I was expecting something like this at the end of the section:

In the absence of this information in a Publication Resource, Reading Systems MUST NOT assume either language or direction from information expressed in the Package Document (i.e., in xml:lang and dir attributes, in hreflang attributes on link elements, or from dc:language elements). The handling of documents without explicit language or direction is defined in their respective specifications.

HTML, for example, has this to say:

In the absence of any such language information, and in cases where the higher-level protocol reports multiple languages, the language of the node is unknown, and the corresponding language tag is the empty string.

SVG isn't quite as clear, but nodes don't have a language if one isn't set.

The statement about using language for display seems to suggest that's the only use, but a reading system can also use dc:language for any internal needs it may require. The usual example that comes to mind is there's a reading system that uses these languages to pre-load TTS languages so they're available as soon as the user begins to read rather than having to delay playback for each document to see what it requires. It could also be used to categorize books by language in a bookshelf. And so on.

It might help to make the intended uses a little more open-ended and non-normative:

The language(s) of the EPUB Publication specified in language elements are informational. Some uses of this information include:

  • exposing it to the user through the Reading System specific user interface
  • using it to enhance functionality in a bookshelf (e.g., sorting by language)
  • using it to optimize the reading interface (e.g., to preload text-to-speech languages)

And possibly end with a note that refers back to the internationalization section for how to determine the language of resources.

@iherman

iherman commented Apr 8, 2021

Copy link
Copy Markdown
Member Author

I do like your additions, @mattgarrish. I have committed the changes.

Comment thread epub33/rs/index.html Outdated
Co-authored-by: Dan Lazin <dlazin@users.noreply.github.com>
@mattgarrish

mattgarrish commented Apr 9, 2021

Copy link
Copy Markdown
Member

I'm going to merge this but it needs a change log entry. Do you want to push one directly to main @iherman or should I?

@mattgarrish
mattgarrish merged commit 05a4f99 into main Apr 9, 2021
@mattgarrish
mattgarrish deleted the rs-i18n branch April 9, 2021 10:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Contradiction between "must" and "advisory"?

3 participants