internetarchive / internetarchive/openlibrary

Passages of Text Must Have Their Language Explicitly Declared

Open
#5,015 0 comments 0 reactions 0 assignees View on GitHub
Lead: @jimchamp Needs: Community Discussion Priority: 4 Theme: Accessibility Theme: Internationalization (i18n)
Dominant language
Python
Stars
6.7k
Forks
2k
Avg merge
2d 19h
Merged PRs (30d)
138

Description

In addition to ensuring that we accurately declare the page language ( #5013 ), we have to ensure that the languages of individual passages of text are accurately be declared.

For some passages of text, such as those in the language links in the footer (beneath `id="footer-locale-menu"`), this will be fairly easy to set (e.g. we know that the contents of the link "Čeština (cs)" are in Czech). However, this gets more complicated when discussing works & other user-generated content on the site.

Looking through Open Library, content can be in a variety of languages used on pages. As a quick example, in the English version of the site I could pull up [Goethe's Faust](https://openlibrary.org/works/OL52456W/Le_Faust_de_Goethe).

In this edition, my page language is English, but the canonical name of the work (from `class="work-line"`) & the description (`class="book-description-content"`) of the work is in German (`lang="de"`). Within the list of editions, the titles & languages listed for the edition include content in their respective languages - for example, _Faust: a ṭrageyde in tsṿey ṭeyl_ (`lang="yi"`), _Le Faust_ (`lang="fr"`) & more.

Selecting one of these editions could provide additional content in the edition's default language. Using [this French edition of Faust](https://openlibrary.org/books/OL24327229M/Le_Faust_de_Goethe) we have a subtitle in French when the rest of the page is in English, and the work description is still in German).

### Describe the problem that you'd like solved
We need a method to ensure that when passages of text are definitively in a specific language, this language is declared within the HTML markup. For screen readers, explicit declaration of language with an html `lang` attribute will ensure that words are pronounced correctly. For instance, while a screen reader might have a German language synthesizer, without explicitly adding `lang="de"` to the German content for the Faust work, the screen reader will likely pronounce this content in the language declared at the page level (currently, English).

### Proposal & Constraints
The works page does seem to surface some of our stored language information. For instance, the Editions list has "in [language]" printed below the editions name & other metadata. I'm assuming that we are currently pulling this information from either the [MARC 008/35-37](https://www.loc.gov/marc/bibliographic/bd008.html) or [MARC 041](https://www.loc.gov/marc/bibliographic/bd041.html) fields.

Perhaps we could pull this information through & surface the language information programmatically via an html `lang` attribute?

The challenges I can foresee here are that we may not definitively know what language a work's description or title are in. As an example, if a users have added their own custom content (e.g. a list with a title in Spanish) we may not be able to accurately surface this information. Similarly, how do we deal with works or other content in undefined or multiple languages.

### Additional context

- [3.1.2 Language of Parts](https://www.w3.org/WAI/WCAG21/Understanding/language-of-parts) - the WCAG criterion surrounding this issue
- [An interesting read on multilingual support in screen readers](https://uxdesign.cc/the-troubled-state-of-screen-readers-in-multilingual-situations-f6a9da4ecdf3)
- [A WebAIM article on, among other things, the `lang` attribute](https://webaim.org/techniques/screenreader/#language) with an example of a screen reader mispronouncing content due to incorrect `lang` usage

### Stakeholders
@bpmcneilly

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.