WAI Translations

From W3C Wiki


This page is left for reference. Most of it is complete and in-active. (tracking)


Misc important notes

Status

This page is left for reference. Most of it is complete and in-active.

Ready for review

Not yet ready:

  • Process
  • Updates to English version

[done] User Interface

User Interface proposals accepted (review period closed) for this info throughout this analysis page:

  • List of languages for this resource
  • Image/Icon options
  • List of all resources in xyz language
  • Translation info / Disclaimer
  • What's translated or English

Contribute perspectives, comments, input

Comments welcome!

This wiki page includes analysis of options, pros, cons, considerations for most points. Before commenting on a specific point, please at least skim the relevant section of this page so that your comment can take into account the known info.

To provide more input, please:

Background

From W3C Internationalization:

Summary

{note: mock-ups below are static hacks; please ignore slightly off font face, size, color, spacing}

@@ swap icons @@

Collapsed (default for mobile):


Expanded (default for desktop):

  • Note: On a page with no translations, "Hide Options [-]" is not needed (because there will only be "Skip to Content | Change Text Size or Colors | All Translations". We might have it there for MVP until a later iteration.

Overview:

  • List at top is the translations of the current page. Clicking on a language changes the current page to that language.
    • List is preceded by "This page in:" in black, bold text.
    • "English" is always first (only bold when current language). Current page language is in black, bold text.
    • Language list will wrap to multiple lines as needed.
  • After list is "All Translations translation-icon.png" that provides a list of all languages and all pages in a specific language.
  • Far right is "Hide Options [-]"
    • Show/Hide toggle hides everything except "Skip to Contents".
    • Shown/expanded by default in "desktop" view. When users hide, cookie makes it persistent.
    • Hidden by default in mobile/small viewport.
    • Hidden label: " Show Customization, Languages, Translations [+]"

Getting to a translation from a specific page/resource:

  • Language list on individual pages - in two places:
    1. Top, right aligned
    2. Under the secondary navigation (in the left column)
    • English is listed first; under the secondary nav: "English (original)"
  • About this Translation on translated pages; Heading "About this Translation" is not visible (available to screen readers).
    • Wording is below
    • Located under the h1.
    • Text (including heading) will be translated.

Getting a list of translations in a language & info for translators: There are two types of pages:

  1. List of all resources in a specific language.
  2. Instructions for translators "Translating WAI Resources"

They are linked in multiple places:

  • On all pages, at the top right is "All Translations translation-icon.png"
  • On page that's translated, under the list of languages (under the secondary navigation on the left), there is:
    • "Other Resources in XYZlanguage"
    • "All Translations"
    • "Translating WAI Resources"

What gets translated:

  • All text within the main content, including other page titles in links.
    • When the page is available in the language of the translation, use the translated title and don't indicate language.
    • When the page is not available in the language of the translation, use the translated title and include in the link "(in English)" in that language.
      e.g., Quelques utilisateurs du Web (en anglais)
  • Navigation text is in the language of the linked page (that is, if the page is translated, the navigation item is in that language; if the page is not translated, the navigation item is in English). We will encourage translations of the following so that the header and top navigation is translated:
    • 6 top-level navigation items and their pages ("Accessibility Fundamentals" and Introduction to Web Accessibility, Planning and Policies Overview, ... "Standards/Guidelines" and W3C Accessibility Standards Overview)
    • "Get Involved", Participating in WAI - Summary paragraph to be translated and the rest can stay in English
    • About W3C WAI
  • Short, site-wide information is translated:
    • Text in "About this Translation" box.
    • Text in "Help Improve this Page" box.
    • Tagline, "Skip to content", "Search", and other things listed here yml file

Examples in the wild

Please feel free to add other examples here!

Most of the examples below translate the entire site, not just a specific page as will be for WAI. Most have only 3-6 languages; whereas a WAI page could have 20+.

Top right - visible list of all languages:

  • no separator: W3C i18n pages has the languages listed in a paragraph with no punctuation between them. on the top right visually; after nav and before h1 in code. With world map image. Lists include up to 20+ languages.
  • no separator: UN w/o language has just the languages (no other content). UN home page has 6 languages in top banner, right aligned
    • UN IPPD page - clicking a language on top right goes to a different page
  • no separator: ICANN has list of 6 languages in a banner across the top on the home page. Right aligned but before search box and sign-in, so ends up being about centered. It doesn't translate the main navigation. Didn't find it on other pages.
  • no separator: WHO lists 6 languages in banner at top, right aligned – with search icon furthest right.
  • no separator: International Monetary Fund (IMF) has 6 languages in banner top right. (has English in alphabetical order) ... sub-pages I checked don't have lanuage listed as all that I can see...
  • no separator: International Maritime Organization (IMO) – 3 languages right aligned
  • pipe separator: ICAO lists 6 languages in banner at top, right aligned.

Top right - select to get list:

  • label is the current language:
    • simplified language icon: MediaWiki Hoome page first item in top right aligned list in site-wide header and visible list at end of content. (MediaWiki Help page has after the h1 visible list, bullet separator)
    • drop-down arrow: ISO has at the top right the current language and a drop-down arrow, which displays list of 3 languages (so there is plenty of room just to list them!)
    • drop-down arrow: WIPO has at the top right the current language and a drop-down arrow, which displays a short list
    • drop-down arrow: World Bank – (has English listed first).
    • drop-down arrow: International Committee of the Red Cross - (has English listed first, or second after current language).
    • drop-down arrow: UN World Tourism Organization (UNWTO) – 3 languages (has English listed first)
    • dialog bubble: European Commission has at the top right the current language and the language code in a dialog bubble, which displays a long list fill screen; policies page has it to the left of the search box; 2020 doesn't seem to have it at all
    • language code (e.g., "EN"), no label: Amnesty International – 3 langauges
  • label is a flag:

Top left or centered - visible list of all languages:

  • left - no separator: ITU has 5 languages listed prominently at the top left (under " Committed to connecting the world")
  • left - no separator: WTO has 3 languages in top banner left aligned
  • left - no separator: UNESCO has 6 languages in top banner left aligned - (has English listed first)
  • centered - no separator: International Court of Justice – has 6 languages centered in a banner under the header
  • after h1 - bullet separator: MediaWiki Help page - (also in site-wide header, first item in top right aligned list with simplified language icon)

Elsewhere - visible list of all languages:

List of languages for this resource

We're using content negotiation to serve language of the page when available. One perspective: "Only very few users switch language as they are served the correct language by default already." — Bjorn Boonen However, we still want people to be able to easily discover other languages, for people who are multi-lingual and want to read different languages and also so everyone knows about the other languages to inform other potential readers, especially those who don't read English.

Goal: When on a resources, it is very clear to users that there are translations available, and not hard to get a translation.

Consider: If the list of translations is very visible and easy to use, the languages will be more prominent in the visual design and content order. On the one hand, that is more cluttering for users who don't want to change language. On the other hand, it shows WAI's support for translations (and it might encourage more translations), so it might be worth it.

Always visible vs. select

  1. List always visible: <-- proposed
    • pro: can see all languages without needing to select anything – your language written out is more recognizable and maybe more attention-catching; (see also "Consider: If the list of translations is very visible and easy to use..." above)
    • pros: shows support for translations; reinforces that WAI is an international organization; might encourage more translations
    • con: takes up a fair bit of space when there are several languages, depending to the design – example of 25 languages
      • We're thinking most WAI pages will have 0-10 translations, and the max will be about 25. In the current design in common "desktop" configurations, about 10 languages fits on one line and 25 languages fits on two lines.
  2. [ruled out] Select to get list (expand/collapse, drop-down, etc.):
    • i18n's cons to using a select list
    • con: some users won't know "language", it's much easier to recognize your language written out
    • con: users can't see all languages until interact with control, so even if recognize "language", users have to click to see whether or not it's in their language
    • pro: takes up less space

Additional perspectives: GitHub 6: how to show translations on a page (list always visible, select expand/collapse, drop-down, etc.)

Location

Info on location moved:

Languages/Translations under secondary navigation

Status: We are going forward with languages/translations under the secondary navigation, in addition to top right. We are open to re-visiting decision if warranted.

List of all languages for a page are at the top right. Do we also want the list of languages for a page in the left column after secondary navigation, as in mockup? Or, is it potentially more confusing than helpful to have the list of languages in two places?

  • pro: good place to include links to:
    • Other Resources in [language]
    • All Translations
    • Translating WAI Resources

Additional perspectives: GitHub 26 Languages/Translations under secondary navigation ?

Wrapping to multiple lines

Current UI has the list of languages wrapping to multiple lines when there are several languages. Users can hide the list of languages with [-] button. Cookie makes that persistent across the WAI site.

Some EOWG participants prefer for it not to wrap. An idea was to show some languages and then ". . . more [+]". There was some concern that that would not be adequate to address the importance of having all languages visible. EOWG participants are OK with showing all languages wrapping for now since the list can be hidden persistently. EOWG Dec 2018 minutes

Current UI has a [-] button to hide the list, without a label such as "Hide Languages".

We may revisiting these decisions in the future — ideally after some usability testing.

Language list separation

Whereas many of the options throughout this page have significantly different usability; this one is more of a personal preference. I've tried to leave the more objective notes as pros and cons here. Feel free to put your preferences and rationales in the GitHub issue.

Proposed: W3C-blue square bullet

Options for separating horizontal list items:

W3C blue squares:

Red squares:

Yellow squares (note contrast is lower than 3:1 yet user doesn't need to see them):

Yellow lines (note contrast is lower than 3:1 yet user doesn't need to see them):

Red lines:

  1. bullet-like square or round
    • pro: like a list bullet; provides visual separation that looks less like a language character than slash (/) or pipe (|) or tall vertical line; groups the languages separately from other items in the line
    • con: takes it a few more pixels than a vertical line
  2. visual vertical line that extends above and below character height, like after "Skip to Content" in current WAI site (in 1 Nov mock-up)
    • pro: similar to vertical lines separating other items in the header and nav; doesn't have cons of a pipe character
  3. no punctuation and some extra space between them
    • note:
      • most examples found have no separating punctuation
      • given the list items are in different languages and sometimes totally different characters, it is easier to distinguish them as separate items
    • pro: simplest visually
    • con: would take more space for good separation than using a vertical line, bullet, or other
    • con: {EE: "is technically inaccessible". SLH: "technically accessible if semantically a list, right?"}
  4. slash (/) character
    • pro/con: used in breadcrumb -- although with different meaning there
    • con: looks more like a language character than a bullet does or extended vertical line; read by screen reader (unnecessary since already a list)
  5. pipe (|) character
    • pro: similar to vertical lines separating other items in the header and nav
    • con: visually similar to letters I and l; long in screen readers (unnecessary since already a list)
  6. comma
  7. icon such as or translation-icon.png
    • con/pro: very visually attention-grabbing; probably too visually cluttering
    • con: takes up more space than other options

Additional perspectives: GitHub 15: Separator for horizontal list of languages

English in the list

Goals:

  • It's clear that the English version is the definitive and original version.
  • Users can easily get to the the English version -- especially people who accidentally ended up on a translated page.

Note:

  • Examples section indicates where some put English in the list - some first and some in other order.
  • Current design has the current language bold. "English" should not be bold when it is not the current language.

Options:

  1. English is first only.
    In list under the secondary navigation, it has: "English (original)" <-- proposed
    • pro: with definitive/original English version listed first, easy for most people to find. several Examples have English first, especially for websites where it is the primary language.
    • con: users might look for it in alphabetical order and miss it at the beginning.
  2. English is both at the beginning and in alphabetical order. First item has "English (original)" or similar
    (*if* we go back to vertical bullet list, then it's not bullet-ted.)
    • pro: makes clear English is the original version; easily find-able for users who look for it in either place
    • con: might look like a mistake or be confusing to have the link twice (although if the first listing includes "original", that might mitigate any confusion), might be harder to implement technical and look OK visually?
  3. English is in alphabetical order only
    • con: not as clear that English is original (adding "original version" to the end would help); a bit harder to find the definitive/original English version when there is a long list of languages
    • pro: simplest implementation?

Additional perspectives: GitHub 13: English in list - at top, ABC order, or both?

Image/Icon options

  1. translation-icon.png character icons <-- proposed after "All Translations" at top right
    • pro: similar to quasi-standard language icon (although not found in many examples in the wild yet) - yet puts A on the left making it seem more like the original; uses more horizontal width and takes up less vertical height
    • con: not as visually attention-getting as the others below
  2. language icon <-- proposed before "Select Language, Translations" in mobile toggle.
    • pro: quasi-standard (although not found in many examples in the wild yet)
    • con: A on the right might make it look like that's not the original (we could swap the letters or the arrow direction around)
  3. other translations icons
  4. world.gif world map (i18n uses)
    • pro: recognizable
    • con: big – would be hard to make small and still look OK, Mercator projection does not properly represent countries
  5. translations-med-1.gif series of characters (old WAI site used)
    • pro: short height so doesn't add space
    • con: maybe not understandable and just confusing
  6. [ruled out] flags.png flag cluster (css uses)
    • pro: eye-catching
    • con: flags not = languages, maybe too eye-catching, too tall – could make a short-height one that looked OK but it would be even wider

Additional perspectives: GitHub 4: Translations image

List of all resources in xyz language

Goal: Users can get a list of WAI resources available in a specific language — and it's fairly easy to discover/find that list.

OPEN:

Links to list of resources in language

  • "All Translations translation-icon.png" link at top right of all pages <-- proposed (behind toggle in mobile default view)
  • [open] On any page that has translations, under the list of languages (under the secondary navigation on the left), have:
    Other Resources in XYZlanguage and All Translations

List only translations or list all resources

Considerations:

  • For quite a while there will be very few translations in most languages.
  • Some people who prefer another language can also read English.
  1. List only the resources that are translated.<-- proposed
    • Pro: Short list, thus easy to see what is in that language.
    • Con: Doesn't show all the other resources and people not know they all exist. (To mitigate, can include pointer to Resource List or Site Map.)
  2. [ruled out] List all resources
    example: I18N provides a full list of resources in a language, with resources that haven't been translated yet in English – e.g., list with Getting Started pages translated, others not.
    • Con: Long list with only a few of them translated. Hard to find translations among all the English.
    • Pro: Reveals all the resources.

User experience for the list of resources in language

"All Translations" link gives users the following (which can be on multiple pages or one page depending on implementation considerations):

  1. A list of all languages in which WAI has translations. The full list is visible by default (as opposed to the user needing to select to see the list). It can be collapsible. Selecting a language provides 2:
  2. A list of all WAI pages available in XYZ language.
    Note:
    • Ideally it is easy to provide a link to the specific language list of WAI resources to others.
    • Ideally organized as the site map is – though low priority for now.
    • We might want to include the summary with the page titles – low priority for now.
    • We might want to list the Translators names – low priority for now.

Translation info / Disclaimer

Goals:

  • Caution that the translation might miss some points. We often carefully nuance the way things are worded. Translations – especially by people not involved in the WG discussions – might miss those nuances. The translation could even unintentionally say the opposite of what we intend. Thus, the motivation for a "disclaimer".
  • Show if the translation is up-to-date with the English version.
  • Given clear credit to the translators and contributors.
  • Link to definitive English version.
  • [lower priority] Encourage other translations.

Wording:

When translation is up-to-date with English:

About this Translation
This volunteer translation might not accurately reflect the intentions of the English original.
[icon] Translation up-to-date with the English version.
Translation updated: DD MMM YYYY. English updated: DD MMM YYYY. Translator: [names]. Contributor: [names]. WAI thanks these translators, and welcomes other translations.

When translation is not up-to-date with English:

About this Translation
This volunteer translation might not accurately reflect the intentions of the English original.
[icon] English version updated since this translation: Change log.
English updated: DD MMM YYYY. Translation updated: DD MMM YYYY. Translator: [names]. Contributor: [names]. WAI thanks these translators, and welcomes other translations.

Potential acknowledgements:

  • could have "Translator" singular or "Translators" plural
  • could have "Contributor" singular or "Contributors" plural
  • could have "Review" singular or "Reviewers" plural
  • could have "Funder" or similar credit

Location:

  • under h1 before summary <-- proposed
  • [ruled out] in the footer. Con: not visible enough. Want both the fact that it not definitive *and* translator credit at the top, and whether it's up-to-date with English or not.

Section heading:

Proposed:

  • "About this Translation" – to be translated
  • in code for screen readers etc., not visible

Text in box translated?:

  • Translated: <-- proposed
    • pro: understandable to people who know the translated language and not English
    • con: if change text later, have to get all translations updated
  • [ruled out] English:
    • con: not understandable to people who don't know English
    • pro: can easily tweak text later if want

GitHub issues:

Wording examples (not sayin' good or bad):

  • "This is a translation. It is possible that it contains errors or is outdated compared to the English version." (W3C CSS)
  • "This document is a volunteer translation. In case of deviations or errors, the current English original should be accepted as authoritative. The W3C owns the copyright on the original as described below." (W3C i18n)
  • "Dear reader of this document - please note that this page is the translation of a W3C text. The original text is protected by copyright, please note the notes in the original document. The rights to the translation itself lie solely with the translator. … No guarantee can be given for any errors in the translation, the only relevant and legitimate document is the English W3C original. (may be an old version) (W3C CSS)
  • "This is an Authorized Translation of a W3C document. The publication of this translation followed the steps described in the Policy for W3C Authorized Translations. In case of disputes, the authoritative version of the specification is the original, English document." W3C Authorized Translations

What's translated or English

Language of site nav - or not include in translations

Note: This section is to address the issue of navigation links in English or translated. This section applies to navigation, site header, and site footer. A different section covers Language of links/resource titles within the content.

Considerations:

  • Some other websites have all of their content and navigation translated into a few languages. WAI site will have only a few pages translated into potentially many languages. On the WAI site, in some languages there will be several resources translated; in some languages there will be very few resources translated.
  • We can decide to encourage translation of the top-level navigation pages. (One is "Introduction to Web Accessibility" that is a high-priority anyway and the others are short overviews.) Thus, more of the top-level navigation would be in the translated language for all options below.
  • Some users prefer another language, yet can read English. When on a translated page, these users want easy visibility and access to both translated and English pages. Other users don't read English well or at all; these users might not benefit much from knowing about resources that aren't translated into their language.

Additional perspectives: GitHub 14 - Language of site navigation

Approach options:

  1. Translated pages include the header, site nav, and footer. <-- proposed
    • pro: users easily see and have access to all the WAI pages, including those not translated
    • con: not a smooth way to address the issue of what language the navigation is in that will work well for most users
    • Navigation language options:
      1. Navigation text is in the language of the resulting page (that is, if the page is translated, it's in that language, and if not, it's in English) <-- proposal
        • pros: don't need to add cluttering indication that the linked-to page is in English; don't need to get all navigation translated and risk poor translations
        • con: some users really don’t like the navigation in different languages
        • Note: Even when top-level navigation is translated, most of the secondary navigation won't be translated in some languages.
      2. All navigation is translated
        • cons: harder to have a good translation of resource titles without understanding the content of the resource well, thus translated titles likely to be not good representation of what EOWG intended with the title; requires more from translators; clutter of indicating links are to English pages
        • pro: smoother and easier for some users not to have navigation in different languages
        • Would need way to indicate if the linked to page is in English. There's not room to write out "(in English)". Options:
          1. icon to indicate "in English" - probably [EN]
          2. text to indicate "in English" - probably "(EN)"
          3. Italicized (in addition to "EN" or other easily-visually-discernable and programmatically-determined indication)
          4. … other ideas? …
  2. [ruled out] Translations include only the main content, not the header navigation or secondary navigation to non-translated pages. Minimal site header and site footer, without most of the links.
    • cons: users can't immediately see and get to the breadth of resources available in English; showing just a small sub-set of resources might have a feeling of "ghetto-izing" the translations, and not looking like we encourage all pages to be translated; probably much more complex back-end and overall management
    • pros: avoids the issue of what language navigation is in, less clutter and thus easier to see other resources available in that language
    • Each translated page includes:
      1. List of all WAI pages in that language (probably in secondary nav area (left column))
        Note: It is expected that the list will be short for most languages — 1-10 pages. After some time (maybe 2+ years), the list for a few languages could get long (20+ pages).
      2. Link to English version (maybe in breadcrumb area)
      3. Link to list of other translations (on the English page) (maybe in breadcrumb area)
      • Consideration: User tasks — When on a translated page, the most common thing users will want is to see is other resources in that language. Occasionally users will want to look at the English version of that page. Rarely will they want to go to that page in a different language (other than the English original). (Thus, we can prioritize the user interface options accordingly.)
    • Option for when all top-level pages are translated in a language (which will happen rarely and not for a while):
      If all pages in the top level navigation are translated, we could include the top-level nav.
      • pro: easier to see and get to those resources than in the long list of all translated pages
      • con: would have inconsistent behavior between English site UI and translated UI (English would have left nav only for that section; translated would have left nav of all pages in that language (if we go with options above))

Examples of navigation language options:

Language of links/resource titles within the content

Note: This section applies to inline links and links within the main content that go to other pages (e.g., "For more about..., see Essential Components of Web Accessibility".) Links in navigation is covered in a different section: Language of site nav - or not include in translations.

Additional perspectives: GitHub 8 - Language of links to other pages

Example user experience: When reading sentences in my language, it's smoother if the link is in that language. If it's in English, it's jarring and takes more effort to process.

For WAI pages:

Back-end will determine if page is available in that language. (thanks, Eric!)

  • Pro – will enable better user experience!
  • Con – more complicated code/markup needed around each link in the translation, and thus also more QAing needed

Rendering:

For non-WAI pages:

(Remember this section is for links within content, not navigation.)

Considerations: Almost all the off-WAI-site pages that we link to will go to an English version, and a few will be available in the translated language. Almost always, the translator will know if the resulting page is available in their language or not. That is:

  • most pages we link to will only be in English
  • a few will be available in some other languages, such as UN CRPD
  • it will be extremely rare that that we link to a page in English that later becomes available in the translated language (may not be rare in general, but is rare for the types of external pages that we link to from WAI resources)

Therefore:

  • proposed: same as with links to known WAI pages, which is covered in the section right above this one.
  • [ruled out] not include the language, e.g., not (in English)

Home Page

Translate:

  • per above:
    • header and footer text (tagline, skip to content, etc.)
    • navigation when the resulting page is in that language
    • pages under "Get Resources for…" that are in that language
  • Making the Web Accessible section
  • Sponsors and Funders section
  • Heading "See what we have for you: Get Resources for…"

Do not translate:

  • News section — add "(in English)" to end of heading (with "in English" translated :-)

OPEN: (need to decide feasibility & priority)

  • Featured resource sections

Marking words/phrases not to translate

From Bert: One thing I missed is the markup that indicates words to leave untranslated. In HTML, I tag such text with

   span class=notranslate lang=en>......</span

I don't know if there is something similar for MarkDown. The advantage of HTML with class=notranslate or translate=no is that several tools for translators (including online services such as Google Translate) understand it.

Content negotiation for language and cookies

STATUS: This section is ready for review and comment.

Setting preferences

Proposed:

  • Use content negotiation for language.
  • If user selects another language, offer cookie setting like i18n does.

Serving pages

Proposed:

Proposed workflow for serving pages according to language

Long description for “Proposed workflow for serving pages according to language” schema:

Motivation, Recognition

STATUS: This section is ready for review and comment.

Goal: Give visible recognition to translators. Motivate people to provide translations!

Proposed:

  • Include translator's name at top of translation – in the translations info box.
  • Also include significant contributors.
  • About this translations box includes "WAI thanks these translators..."

Consider: Also in list of resources in a language, include the translators name.

(Some input in Restarting W3C Volunteer Translation Tracking e-mail thread & "<notabene> Personally as a translator I feel credited enough by being cited as translator in the Translation block on the page (+ credited inside company and local community for doing it)" -- Stéphane Deschamps in EOWG meeting.)

Additional perspectives: GitHub 2: Translations thanks and link wording - in Translations Info box

Translators names, links, etc.

Links section of Translating WAI Resources

Policy based on i18n Link Rules, which provides some background.

Can include:

  • Translators formal name, common name used online, &/or Twitter handle
    • Link to translator's individual page, such as personal blog, personal home page, bio page, or acceptable social media page
  • Organization name - translator's employer &/or other sponsor/funder of the translation

Cannot include:

  • Links to organizations other than translation organizations and qualifying accessibility/disability organizations

Using GitHub, Markdown, HTML

STATUS: This section is ready for review and comment.

Some potentially good translators may not be comfortable with GitHub, Markdown, &/or HTML. We don't want that to be a limiting factor.

Ideas:

  • For those who want to try/learn -- Provide instructions. Hopefully there are existing ones to point to and we don't need to make our own.
  • For those who don't want to mess with it – Will we offer that they can submit the translation in another format (e.g., word processing) and we put it in format on GitHub? Do we have sufficient resources to do it short-term and long-term? It is likely people from EOWG, IG, and other would step up to help with this.
  • If we give translators a markdown file and they edit it in their tool of choice and send it back, perhaps it won't take much effort for us to upload and QA that? We'll give that a try with a few files in January 2019.

Additional perspectives: GitHub 11: Using GitHub, Markdown, HTML: translators who can't code

Updates to English version

STATUS: This section is drafty. Feel free to comment now or wait until it is more filled out.

Additional perspectives: GitHub 9: Edits to English version - process implications

Considerations:

  • Most of the info on the page works well for most EOWG and WAI resources that are integrated through GitHub pages. What about things that aren't like Understanding WCAG docs?!?
  • Many updates to WAI Resources will not be critical. Some might be more important, such as updates to Tutorials and Understanding WCAG docs.

OPEN How to handle these?

Example approach for i18n articles:

  • if the changes are small editorial tweaks, but involve natural language text, we typically add the new English text to the translations while waiting for translators to provide an update. If no update if forthcoming, the English text may remain there.
  • if there are substantive changes we normally add a strong warning at the top of the page and give translators a month to provide an updated translation. If that is not forthcoming, we remove the links to the out of date translation.

Need: Translators need easy way to get notification that there are changes, and see the specific changes, so they can update their translation. Ideally, they would get some advanced notice of changes coming, e.g., when the resources goes to EOWG for final approval.

  • Proposal: Translator get e-mail when the resource is updated.
    • OPEN How?
      • @@
      • [ruled out] Just have them add GitHub watch list for the English page. Con: Will get all the traffic for all issues. (While some might like that and chose it, for others it will be unnecessary clutter and they will ignore it, and thus miss legitimate notification that English updates are ready for translation updates.)
  • Proposal: Changes to English version are in changelog &/or diff.
    Note: GitHub diff insufficient (from Shawn's experience).
    • OPEN: Discuss details and options.

Need: Users (and translations managers) should be able to see if the translation is up-to-date with the English version.

  • Proposal: Translation has date of translation and automated last updated date of English version in the Translation info box under the h1. When out-of-date, also linked to change log &/or diff.

Note: In the footer, leave the date as is in the original footer so people can see the dated-ness of the content. (The date of the translation is in the translations info box under the h1.)

Changelogs

Purpose:

  1. Inform translators of what needs to be updated.
  2. Inform anyone interested of substantive changes.

Comments on translation vs. content

STATUS: This section is ready for review and comment.

(We previously considered trying to have comments on the translation itself separate from comments on the content. Decided against that.)

Note: Comments that come in on a translation might be:

  • on the translation itself
  • related to the English original

When a comment comes in:

  • If the comment is not in English, then assign it to the translator and/or others who know that language. Ask them to translate the comment. (If it's a long comment and it's about the translation, they can just do a short summary in English.)
    • If the comment is on the translation itself:
      • add the language code in brackets to the beginning of the issue title; e.g., [fr]
      • label it with "language code-translation"; e.g., fr-translation
      • assign it to the translator
    • If the comment is on the English version, after it is translated:
      • unassign the translator
      • assign to bakkenb, sharronrush, and the editor(s)

Note: When in a translation, in "Help improve the page" box, links add [language-code] to the beginning of the GitHub issue or e-mail, e.g,: [fr]

Process

STATUS: This section is ready for review and comment.

We are planning to use the new W3C Translations Management system.

Goal

W3C Team & translators can tell the status of translations:

  • Translators can tell if a resource translation in their language is complete or in-progress (so they don't duplicate effort).
  • When a translation is ready for review, the following are notified:
    • People who have identified that they will review that language.
    • Translations coordinator to help assign reviews, and get it through the review process for publication.
  • When a resource is updated, translators are notified so they can update the translation.
  • Know date of intent to translate — If a translation has been in progress for a long time and another translator is interested in doing it, we might ask the initial translator to either finish it by a certain date or release it so someone else can do it.

Current process

Note: This will be more automated in the future.

  1. A translator signals their desire to translate a WAI resource by sending e-mail to public-wai-translations and w3c-translators lists.
  2. WAI staff:
    • Checks that someone else is not already working on a translation of that resource in that language.
    • Prepares resource for translation and notifies translator & CC public-wai-translations.
  3. When done, translator either submits pull request or sends file via e-mail.
    • If e-mail, someone adds the translation to the repo — staff by default, although anyone could.
    • Staff updates status in W3C Translations Management.
  4. Review:
    • QA: links, markup/markdown, … . Reviewer skills: markup/down.
    • No additional information, e.g., added links (other than allowed translator info with rel="nofollow"). Reviewer knowledge: Cursory check can be made by someone familiar with the resource and an automated translation. More thorough check requires knowing the translated language.
    • Reviewers who knows the language does at least a high-level review to ensure a minimum level of quality (e.g., not automated translation). Review by at least one "third party" is required in most cases. Review skills: Language knowledge.
    • Ideally they indicate their review on the GitHub pull request, alternatively can send e-mail to public-wai-translations.
  5. After the translation "passes" review, staff

Misc Notes

Prep Page for Translation

moved to https://www.w3.org/wiki/WAI_Translations/tracking#Prep_Page_for_Translation

Instructions to Translators

STATUS: This section is ready for review and comment.
Translating WAI Documents

misc notes:

Words and phrases needed with the first translation

e-mail template

Thank you for translating this WAI resource!

The file to translate is attached. It is in [@@HTML|Markdown].

Before starting your translation, please read:

When you are done with the translation, we encourage you to use GitHub to fork, edit, and submit a pull request. If you are not comfortable with GitHub, you can e-mail the translated file to public-wai-translations@w3.org with the subject: Completed Translation – [language] – [resource title]

Translations will be reviewed before they are published. Please include the names of people who already reviewed the translation, and contact information for other people who might be interested in reviewing it.

After we receive the translation, we will contact you if anything else is needed. Otherwise, when we publish the translation, we will send e-mail to the WAI and W3C translations lists.

frontmatter

update: gonna try simpler approach from anatomy. not change those that have below yet. (28 May slh:ee)

suggested adding spacing and re-ordering to make easier for translators:

 ---
 # Translation instructions are after the "#" character in this first section. They are comments that do not show up in the web page. You do not need to translate the instructions after #.

 title: @@Introduction to Web Accessibility   # Do not translate "title:". Do translate the text after "title:".
 nav_title: "@@Video Introduction" # A short title that is used in the navigation

 lang: en   # Change "en" to the translated language shortcode from https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry

 last_updated: 2020-11-11   # Put the date of this translation YYYY-MM-DD (with month in the middle)
 translators: 
 - name: "@@"   # Replace @@ with translator name
#  link: "@@"
# - name: "@@"   # Replace @@ with name, or delete this line if not multiple translators
# contributors:
# - name: "@@"   # Replace @@ with contributor name, or delete this line if none
# - name: "@@"   # Replace @@ with name, or delete this line if not multiple contributors

 ref: @@/fundamentals/accessibility-intro/   # Do not change this
 layout: default
 github:
   repository: @@w3c/wai-intro-accessibility
   branch: gh-pages
   path: index.md   # Add the language shortcode to the middle of the filename, for example index.fr.md
 permalink: @@/fundamentals/accessibility-intro/   # Add the language shortcode to the end; for example @@/fundamentals/accessibility-intro/fr

 footer: >   # Translate all the words below, including "Date:" and "Editor:". Do not change these dates.
   @@...
   ... 
   ...

 # Read Important Translations Guidance at https://www.w3.org/wiki/WAI/Translation_Instructions
 # Read Translations Notes for this resource at https://github.com/w3c/wai-@@@@@@@@@@@@@@@@@@/blob/gh-pages/README.md
 # end of translation instructions
 ---

old version:

---
# Translation instructions are after the "#" character in this first section. They are comments that do not show up in the web page. You do not need to translate the instructions after #.
title: @@Introduction to Web Accessibility   # Do not translate "title:". Do translate the text after "title:".
nav_title: "@@Video Introduction" # A short title that is used in the navigation
lang: en   # Change "en" to the translated language shortcode from https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry
last_updated: 2020-11-11   # Put the date of this translation YYYY-MM-DD (with month in the middle)
translator: " "   # Within quote marks, put name or names separated with a comma
contributors: " "   # Within quote marks, put name(s) or delete this line
permalink: @@/fundamentals/accessibility-intro/   # Add the language shortcode to the end; for example /fundamentals/accessibility-intro/fr
ref: @@/fundamentals/accessibility-intro/   # Do not change this
layout: default
github:
  repository: @@w3c/wai-intro-accessibility
  branch: gh-pages
  path: index.md   # Add the language shortcode to the middle of the filename, for example index.fr.md
footer: >   # Translate all the words below, including "Date:" and "Editor:". Do not change these dates.
  @@...
  ...
  ... 
  ...
# Read Important Translations Guidance at https://www.w3.org/WAI/about/translating/#important
# Read Translations Notes for this resource at https://github.com/w3c/wai-@@@@@@@/blob/gh-pages/README.md
# end of translation instructions
---

Project Plan

Schedule below is in-progress and will probably change a bit.

User Interface (UI)

  • [done] Analysis and initial straw proposals to W3C Team — Fri 12 Oct
  • [done] Analysis and straw proposals to EOWG and W3C Team — Wed 17 Oct
  • [done] EOWG discussion — Tue 23 Oct
  • [done] Draft proposals — Wed 31 Oct
  • [done] EOWG discussion — Fri 2 Nov
  • [done] Proposals and mock-up (not fully working prototype) — Thur 8 Nov
  • [iterative] Informal usability testing (mostly with people who do not know English well)
  • [passed] Deadline for comments on UI proposals and mock-up — Mon 19 Nov
  • [done] Iterate and evaluate proposals as needed
  • [done] Final proposal — Wed 5 Dec
  • [passed] Deadline for comments on UI proposal — Mon 17 Dec
  • Code UI

Beta Test & Showcase

  • [done] Prepare 1+ pages for translation — Thur 20 Dec
  • [done] Ask for translations from a few people — Thur 20 Dec
  • [in-progress] Demo with real translations — 1 Feb
  • Make adjustments based on lessons learned from the beta
  • Soft launch UI with translations (need to decide how much of process needs to be in place before launching) — by 15 February

Process & Translators Instructions

  • [done] Initial drafts
  • [done] W3C coordination meeting — 15 January
  • Updated drafts (pending W3C system update)
  • EOWG discussion
  • Final draft proposal
  • Deadline for comments on first version of Process & Translators Instructions

Complete & Announce!

  • Set up GitHub notifications, language-specific mailing lists, etc. (exactly what is still to be determined)
  • Get contributors in place for preparing and reviewing translation submissions
  • Do "soft launch" to get a trickle of new translations and further test the process with additional people — by 15 February
  • Announce via W3C Translators list, WAI Announce/IG list, WAI home page & RSS, tweets, ? W3C News, other... — by 7 March

Misc considerations:

  • Timing with new W3C TR translations system
  • Timing with revised Authorized Translations Policy

Related info





Archived Analysis and Past Proposals

Status: Proposals below were replaced by decisions above.

EOWG questions:

Archive note: This was for 23 October 2018 meeting.

  1. Comments on straw proposals above? (Goals, options, pro, cons, and considerations are listed throughout this page.)
  2. Comments on Image/icon options?
  3. Who would be interested in helping format or check translation submissions? Need to be comfortable with markdown and GitHub.
  4. Any other ideas for motivating people to provide translations?

Process Notes - Archived info

A first, incomplete pass at instructions for translators is here: Translating WAI Documents

  1. A translator signals their intent to translate a WAI resource.
    OPEN: How? Considerations:
    • Currently: by sending e-mail to w3c-translators@w3.org
    • Any reason to instead create new wai-translators email list?
    • i18n: "You need to write to public-i18n-translation@w3.org before starting and copy w3c-translators@w3.org. We'll check that the file isn't currently being translated by someone else, and that it isn't about to be updated."
    • New W3C Rec process: by raising an issue in a well-defined github repository
    • (ee proposal) Similar to i18n per email.
  2. Notify other translators of that language. Considerations: {not sure this is important}
    • New W3C Rec process: as an opt-in, other translators of that language get notified of that intent (and possibly, signal their intent to help with the effort)
    • (ee proposal) Translators subscribe to a mailing list specific for their language which is fed through https://github.com/dontcallmedom/github-notify-ml/ by opening an issue with a specific GitHub label. See configuration for i18n for an example.
  3. WAI prepares resource for translation and notifies translator (CC list) when the file is ready.
    Note: Current plan is for in-link links to other WAI pages to automatically indicate if they are in English. To do this, we'll need to update the markdown. We won't do that for all resources right away; instead will on demand, that is, when someone wants to translate the resource.
  4. When done, translator indicates it's done and ready for review.
    OPEN: How? Considerations:
    • What will we want for tracking, e.g., GitHub label?
    • Make sure the right people get good notification.
    • ? send e-mail ? tag reviewers ? GitHub label ?
    • (ee proposal) If translators use GitHub, a labeled GitHub pull request would be the most straightforward way. Otherwise, they’ll send a translation to their language-specific ml and someone from the team or the mailing list needs to add the translation to the repository.
  5. Reviewers check:
    • QA: links, markup/markdown, … . Reviewer skills: markup/down.
    • Reviewers who knows the language does at least a high-level review to ensure a minimum level of quality (e.g. avoid spam, low-quality automated translation). Review by at least one "third party" is required. Review skills: Language knowledge.
    • No additional information. (Cursory check can be made by someone familiar with the resource and an automated translation. More thorough check requires knowing the translated language.)
    • (ee proposal) Reviews can optimally happen inside of a GitHub pull request.
    • Considerations:
      • What can be automated?
        • New W3C Rec process: via a github automated check, a number of automatic validation are run on the translation (presence of a disclaimer, HTML validity, ...)
      • New W3C Rec process: a team of identified reviewers for that language get notified and are expected to make a high-level review of the document to ensure a minimum level of quality (e.g. avoid spam, low-quality automated translation); optionally, these reviewers can provide more detailed feedback as non-blocking requests for enhancements
    • (ee note) Unsure what can be automated or how one would implement such an automation.
  6. After "passes" automated checks and review, WAI publishes. Links to it (e.g., on the list of translations in a specific language) will be automatically generated.

Misc Notes

  • OPEN: Notifications: e-mail lists & GitHub — Have separate WAI-translators list or use w3c-translators? Have separate language-specific lists for W3C Rec i18n & wai – or the same list?
    • (ee note) I would make a difference between TR and non-TR resources and have two different mailing lists for those. Otherwise, non-TR translations might be under similar scrutiny as TR translations, and that does not help anyone.
  • How to handle differences of opinion on translated wording?
  • What if a translator says they are going to work on a translation, and another person also wants to? First come, gets to lead it? What if they don't get it done in a reasonable period?
    • (ee) They work together. :-) The person who wants to lead it should lead it. (slh: could have case where two+ people want to lead it and not work together...)
  • GitHub to e-mail: script to send mail to a set of email addresses when specific GitHub events happen
  • tracking translations – related: i18n translations tracking GitHub project, W3C Rec database tracker plans, new W3C tracking
    • (ee) It makes sense to have a tracking project in GitHub, I think.

Translation Priorities - Archived info

Priorities latest version

Additional perspectives:

Note: Header and main navigation pages — When a main navigation item is available in a language, then it will be shown in that language on all translations. For example, if the page "Planning and Policies Overview" is available in German, then on every German translation, that navigation item will be "Planung & Richtlinien". Therefore, we may want to encourage translations of the following page so that in the header and main navigation, they are in translated languages on translates pages:

  • 6 top-level navigation items and their pages ("Accessibility Fundamentals" and Introduction to Web Accessibility, Planning and Policies Overview, ... "Standards/Guidelines" and W3C Accessibility Standards Overview)
  • "Get Involved", Participating in WAI (summary paragraph to be translated and the rest can stay in English)
  • About W3C WAI [except we really should update this first]

Candidates for initial focus (one or a couple):

  1. Page with Video Introduction to Web Accessibility and W3C Standards
    • pro: already have transcript / subtitles in many languages
    • pro: short, straight forward content
    • pro: broadly applicable and great overview of accessibility & WAI work at W3C
    • con: page content itself is not "meaty/tofuy", it's the video that is the meat/tofu
    • note: probably best to wait to publish these until after we have the other-than-You-Tube issue figured out and implemented (hope to have at least interim solution by mid-Jan)
  2. Introduction to Web Accessibility
    • pro: important overview of WAI work and accessibility
    • pro: engaging resource that can encourage both accessibility in general and other translations
    • pro: has lots of important terms and concepts; would be good to have done well and documented (e.g., how to translate xyz-phrasing in xyz-language)
    • pro: good one to check that translator has the skills and understanding to do well
    • con: long and some aspects a bit hard to translate well
  3. W3C Accessibility Standards Overview
    • pro: overview of standards, with is backbone of W3C's accessibility work
    • pro: fairly short and straightforward
    • con: not as interesting/engaging as others
    • note: need to add personalization and maybe others
  4. WCAG 2.1 at a Glance
    • pro: very short
    • con: important to do translations well as directly related to WCAG
    • con: lots of links that would go to English QuickRef
  5. Web Content Accessibility Guidelines (WCAG) Overview
    • pro: of broad interest around the world
    • pro: fairly straightforward; medium length
  6. Mobile Accessibility at W3C
    • pro: fairly short and straightforward
    • pro: lots of questions about this internationally; particularly relevant for project
    • con: specific topic rather than broader overview
    • note: need to check with Shadi and mobile folks about updates

Priorities input from WAI Coordination Call Sept 2018:

  • Easy Checks
  • WCAG Quick Reference
  • Tutorials
  • ARIA Authoring more useful than ARIA spec [both are TR docs]
  • ARIA in HTML (Web Platform) [TR doc]

WAI translations pages - Archived info

Archive note: Just a reminder that this is old information and some of it has changed.

Content that we have is:

  1. Lists of translations -- AUDIENCE: users
    • List of translations in specific languages (reminder: should include WCAG, too – directly or indirectly) – one page per language?
    • WCAG Translations (separate page that lives under /wcag/)
  2. Instructions to translators -- AUDIENCE: translators
  3. Translations priorities -- AUDIENCE: translators

Proposed:

  • "Languages" new page under https://www.w3.org/WAI/roles/ <-- proposed
    • Options:
      1. Each language on a separate page. Languages main page is primarily a list of languages that link to pages with list of resources in that language <-- proposed
        • pro: nice to be able for others to point to separate page – better than deep-linking into a page with all languages
        • con: one more click to get to list of resources in your language
      2. [ruled out] Languages page includes all translated pages. Contents list at top jumps down to the language.
        • con: when link from elsewhere to the list, users would end up deep-linking into the guts of a page, which is not a great user experience
    • includes link to Translating WAI Documents
    • possibly also link to WCAG Translations
  • Translating WAI Documents includes: <-- proposed
    • Instructions to translators
    • Translation priorities
    • clear links to Languages list pages and WCAG Translations
    • minor links – maybe just within the content text – to W3C translations info

How these are discoverable is covered in List of resources in language section above

Note:

  • In language lists, will want to add WCAG translations. Might be hard to automate that for a while, until the new W3C system is in place.
  • Translations of WCAG and other WAI Recs will fall under the new W3C Rec translations management. Sometime we'll need to figure out if we can automate some of the listing on WCAG Translations.

Including Change Text, Colors

Current translations UI does not include "Change Text Size or Colors". Here are some options for including it. We might do this with first release or later iteration.

Considerations:

  • Many users will not want the link to instructions to change text nor the list of languages. For these users, it would be nice to hide all that once and not have to see it again. (We'd set cookie so it persists.)
  • Impact on coding and schedule? (Maybe option 1 is better overall because then mobile & desktop have same functionality? Or maybe option 2 has a pro of requiring less change from current translations UI?)

Additional perspectives: GitHub 122: "How to Change Text Size or Colors"

{note: the icon is a quick draft; it would be made better. the mock-ups below are static hacks; please ignore slightly off font face, size, color, spacing}

Option 1: Adds text link. Has expand/collapse on all. <-- proposed

  • pro: same functionality & UI for mobile & desktop (collapsed by default on mobile and open by default on desktop)
  • pro: users can collapse more to have cleaner UI (compared with #2c collapsed below)
  • note: mock ups have "Change Text Size or Colors" and no icon; it could be done with icon and other wording
  • note: mock ups have "Hide Options"; it could just have "Hide" or no label or other label

1. collapsed (default for mobile)


1.a. expanded (default for desktop) - with collapse at end <-- proposed

  • pro?con: easier to see the collapse option
  • con?pro: moves translations link from far right
  • ? con: different from current mobile UI so more re-coding?
  • Note: On a page with no translations, "Hide Options [-]" is not needed; however, it's fine to have it there for MVP.


1.b. expanded (default for desktop) - with collapse after Skip to Content

  • con: the hide is harder to find and what it does isn't as clear, seems awkward there
  • ? pro: similar to current mobile UI so less re-coding?


Option 2: Adds text &/or icon. Leaves collapse on only language list.

  • con: users can't hide as much

2.a. [icon] without label


2.b. "Change Text & Colors" and [icon]


2.c. "Change Text Size or Colors" and no icon


2.c. collapsed

4 Dec proposal

main UI – Archived info

Proposal:

  • List at top is the translations of the current page. Clicking on a language changes the current page to that language.
    • List is preceded by "This page in:" in black, bold text.
    • "English" is always first (only bold when current language). Current page language is in black, bold text.
    • Language list will wrap to multiple lines as needed.
      • In "desktop" view, list will default to visible. Users can hide the list. Cookie makes that persistent. Collapsed text is "... Show Languages".
        (Language hide not needed for mobile since there's already an overall toggle to hide.)
  • After list is "All Translations translation-icon.png" that provides a list of all languages and then all pages in a specific language.
  • Mobile/small viewport:
    • When there are translations for that page, has at top right: " Select Language, Translations" toggle that displays:
      " Hide Languages — This page in: [language list] | All Translations translation-icon.png"
  • When no translations, mobile & desktop has at top right: "All Translations translation-icon.png" that provides a list of all languages and then all pages in a specific language.

{note: the mock-ups below are static hacks; please ignore slightly off font face, size, and color}

Mobile - When the page has other languages available:
default: expanded:


Desktop default - When the page has other languages available:



Desktop - When the user collapses/hides the list of languages:



Mobile & Desktop - When no other languages are available for the page:

Additional perspectives: GitHub UI proposal 4

wording & formatting options - Archived info

In desktop view, "Hide Languages" label with [-] button?

  • given that it is not required that the user know that functionality is available, decided not to add a label
  • con: takes up significant space

Options for this page label:

  • wording:
    • This page in: <-- proposed
    • This Page:
    • This content:
    • Translations of this page:
  • weight:
    • bold
    • normal

Options for hidden/collapsed wording:

  • ... Show Languages <-- proposed
  • Select Languages
  • List Languages

Options for language list label:

  • wording when translations of that page available:
    • All Translations <-- proposed
    • All Pages & Languages
    • Other Pages & Languages
    • Other Pages in Other Languages
  • wording when no translations of that page listed:
    • All Translations <-- proposed
    • Translations
    • Languages
    • Other Languages
  • weight:
    • normal <-- proposed
    • bold
  • icon:
    • right of words <-- proposed (icon important especially when there are no other languages listed)
    • none (icon less important when there are other languages listed)

Link to list of all translations - Archived info

Proposal:

  • List at top is the translations of the current page, and clicking one changes the current page to that language.
  • In the site header, near search, is a link that goes to the list of languages available for any page.

Options for header link:

  • location:
    • above Search box
    • above Get Involved | About W3C WAI
    • below Get Involved | About W3C WAI
    • other...
  • wording:
    • Other Languages
    • Languages List
    • Site Languages (con: "site" could be W3C-site, and also we don't do fully-site-wide translations)
    • Languages
    • Other Accessibility Translations
  • icon:
    • light gray (background of language list at top) 6.4:1
    • white
    • gold
    • none






Proposed 6 November – Archived info

Archive note: Much of the 6 Nov proposal remains intact above. Some of the changed info is left here for reference

Mock-up notes:

  • The English version of pages will not have the About this Translation box ("This volunteer translation...") — it's just there for review. Also under the secondary list of translations, won't have "Other Resources in English".

Getting a list of translations in a language & info for translators:

There are two types of pages:

  1. List of all resources in a given language.
  2. Instructions for translators "Translating WAI Resources"

They are linked in multiple places:

  • On page that's translated, under the list of languages (under the secondary navigation on the left), there is:
    • "Other Resources in XYZlanguage"
    • " Translating WAI Resources"
  • On home page, in "Get Resources for…" section, last link is "translation-icon.png Languages" that goes to list of languages, and clicking on a language gives user list of translated pages in that language. (also has link to "Translating WAI Resources")
  • Site-wide footer has link " Translations" that goes to "Translating WAI Resources" page that primarily includes instructions to translators. (also links to list of translations in specific languages)

21 November Issues - Archived info

Summary 21 Nov

Straw proposal for discussion:

  1. top right list is site-wide — The full list of languages is always at the very top right. Clicking on a language there leads to a list of all pages available in that language.
  2. page list is near h1 — Above the h1 and below the breadcrumb, is a "Select Language" toggle that displays languages of that page only. Clicking on a language there changes the language of that page.

Base

Background:

  • There is a mental model mismatch because:
    • Most multi-lingual sites have all of the content translated. WAI site will not.
    • We are translating the "chrome" - header, footer, and all navigation when the resulting page is in that language - and some of the home page.
      So it's a bit more than a page-only translation, yet not the full website.
  • We plan to have a page for each language that lists the WAI pages available in that language.
  • Examples section lists how some other sites list languages (which is almost all top right).
  • old 6 Nov proposal, old GitHub 5

Major Problem with 6 Nov proposal with list of languages at the top that link to the page in another language:
Users are likely to think that only the languages listed are available throughout the site. When on a page with only a few languages listed, and users could assume that those are the only languages available for all the pages — thus missing that there are other pages in their language.

Brainstorm ruled out: List all languages, inactive links, icon — List located top right as in 6 Nov mock-up/proposals would list all languages that have any page translated. When on a given page, if that page is not available in a language, then that language is not linked and grayed out. At end of list is a link to the list of languages, so users could get a list of pages available in their language. Con: users likely to be frustrated that can't select their language when not available, and not likely to easily figure out to click the icon to find out what's available in their language.

New Proposal: Top list is site-wide, page list is elsewhere — Links in the top list go to a list of all the WAI pages available in that language.

  • pro: all languages are always listed on all pages. list at top provides site-wide info.
  • con: most users will probably expect the list at the top to go to a translated version of the current page (or main site page). hopefully those users will find the page-list. given the "mental model mismatch" this might still be the best option.

Additional perspectives (add your comments to these):

Page list options

Notes for all options below:

  • Latest proposal has all languages throughout the site at the top, and the list of languages for the specific page under the secondary nav. Therefore, propose choosing the least cluttering and obtrusive option for this list of languages. And if toggle, default to hidden. (Can set last user choice with cookie so it stays on all pages.)
  • We're estimating that 90% of readers will get the language that they want from language/content negotiation. And that most people looking for languages will look top right. So a primary use case for people using this page-translation-list is multi-lingual users who want to go back and forth between a translation and the English original, or other translations.

Example of show/hide toggle in breadcrumb area:

  • To help clarify it's this page only, could do something like: "Select language of this page" (toggle to: "Hide Languages")
  • Other ideas for labels


0. right aligned, above h1, under breadcrumb - float-right box - toggle default list not shown <-- straw proposal

  • pro: has some proximity to h1 without causing extra h1 wrapping when the list is not shown
  • con: may be difficult to implement
  • label proposal: "Select Language" (other label options)


1. in breadcrumb area, right aligned – toggle on line with bread crumb, list of languages on next line

  • pro: less cluttering than before or after h1
  • con: may be very difficult to implement


2. in breadcrumb area, right aligned – float-right box

  • pro: less cluttering than before or after h1
  • con: looks bad expanded


3. above h1 - horizontal list

  • con: too cluttering for all users – including screen reader users


4. below h1 - horizontal list

  • con: too cluttering for all users – including screen reader users - detracts from flow of h1 to content
  • pro: clearest that the list of languages applies to this doc


5. [ruled out] in box float right top - aligned with h1

  • con: would cause the h1 to wrap (even when collapsed) — sometime to 3+ lines; often would overflow into the summary box looking a bit odd and causing more wrapping of summary text


X. [ruled out] within the secondary nav (box on left) under the page itself
  • con: would significantly complicate the navigation for all users and would conceptually split up that secondary navigation


X. proposed secondary location

left column after secondary navigation, as in 6 Nov mockup

  • con: well below the fold so low discover-ability
  • pro: plenty of space for list in single column without changing visual design above the fold, and also include link to "Other Resources in [language]" and "Translating WAI Resources"

Question: Is it potentially more confusing than helpful to have the list of languages in two places?

Mobile (small viewport) - archived analysis

Notes:

  • The pros and cons for UI options throughout this page mostly apply to mobile. They're not repeated in this section.
  • Current WAI site on mobile has "{hamburger icon} MENU" to toggle the navigation.
  • If there are no translations available for that page, there won't be anything shown about languages (none of the options below).

Options on pages with translations available:

  1. When only a few languages, they're always visible. When several languages, toggle to display them. That is:
    If the list of languages is less/shorter than X, then all languages are listed.
    If the list of languages is more/longer than X, then character icon translation-icon.png is a toggle that displays and hides the languages.
    • pro: when there is a short list of languages then it matches the desktop UI with the languages always visible (see pros in sections above), and no need for extra visual clutter or interaction to get the list
    • con: when some pages have long lists of languages then inconsistent mobile UI (that is, some pages list a few languages and some pages have toggle)
    • Options for what is displayed when there are several languages:
      Question: For our target audience who does not read English well, which word would most people know more/better "English" or "Languages"?
      1. The toggle "label" after the icon is "Languages"

        translation-icon.png Languages ]

      2. The toggle "label" before or after the icon is the current language (usually "English" or the reader's language from language negotiation):

        [ English translation-icon.png ]     or     [ français translation-icon.png ]     or     [ Deutsch translation-icon.png ]     or     ...

        • pro: almost all examples found do it this way, that is, the label for the list of languages is the language of the currently-displayed page
      3. [ruled out] When on a non-English page, English is first and linked, then the language, then the icon:

        English(original)   français  [  translation-icon.png ]

        • con: users might think there are only those 2 languages and not click the toggle to see more
        • pro: makes it easiest to get to the English version when on an other langauge
  2. Always a toggle that displays and hides the languages.
    • con: less desirable UI when only a few languages (e.g., instead of recognizing own language in visible list, users have to recognize toggle and select it to see if available in their language)
    • pro: consistent mobile UI across pages no matter how many languages available
  3. [ruled out] Full list always visible
    • con: would take up significant chuck of screen real estate on pages with several languages – example of 25 languages

Additional perspectives: GitHub 16: Mobile UI

List of resources in language - archived analysis

Goal: Users can get a list of WAI resources available in a specific language — and it's fairly easy to discover/find that list.

Proposed:

  • Add " Translations" in site-wide footer that goes to Translations overview page, which includes links to translations and information for translators.
  • On home page, in "Get Resources for…" section, add at bottom.
    Wording options:
    1. translation-icon.png Languages
      • pro: matches heading of section in left column with list of languages
      • con: doesn't flow after "Get Resources for…" (but it will be at the end of list so probably not a big deal)
    2. [image] Different languages
      • pro: follows better after "Get Resources for…"
    3. [image] Translations
      • con: confusion with "Translations" in footer that goes to translations overview page.
      • pro: simpler wording, common terminology
  • On page that's translated, under the list of languages (under the secondary navigation on the left), have

Related info: WAI translations pages

Location in 6 Nov proposal - archived analysis

Examples section lists how some other sites do it (which is almost all top right).

Options for the location of the list of languages: (currently proposed to be in two places)
Question: Is it potentially more confusing than helpful to have the list of languages in two places? (note the current proposal has additional info under the secondary nav: the list of resources in that language and the link to "Translating WAI Resources")

  1. top, right (in panel that starts with "Skip to Content", right aligned) <-- proposed as primary location
    • pros: most common location, in almost all examples, thus most users will look there for it; lots of space available – should take up 1 or 2 lines in most "desktop" configurations
    • con: translation is of the individual page whereas that location makes it seem site-wide — although that might not be a problem at all for the user experience
    • (note: we'll probably delete "Change Text Size or Colors" partly because we've not made it a priority to update it)
  2. left column after section navigation <-- proposed as a secondary location (in case people miss it at the top)
    • con: well below the fold, and thus low discover-ability (link above the fold options below); rare location in examples
    • pro: plenty of space for list in single column without changing visual design above the fold
  3. in breadcrumb area, right aligned
    • pro: proximity to page content/navigation good since the translation is of that page, not side-wide
    • con: users more likely to look for it at the very top since that's the most common location in examples; will often wrap to 3 or more lines when long breadcrumb &/or long language list (e.g., long breadcrumb)
  4. [ruled out] horizontal list under h1
    • con: too cluttering for all readers, most of whom don't want a different language than they get. (we're estimating that 90% of readers will get the language that they want from language negotiation - some multi-lingual users will want to see the English original &/or other translations)
    • pro: proximity to h1 since the translation is of that page, not side-wide
  5. [ruled out] float right top-aligned with h1
    • con: list of languages would often cause the h1 to wrap more &/or bump the summary box down quite a bit leaving lots of empty space under the h1
  6. [ruled out] within the secondary nav (box on left) under the page itself
    • con: would significantly complicate the navigation for all users and would conceptually split up that secondary navigation

Additional perspectives: GitHub 5: location for list of translations on a page

Comments on translation vs. content - archived early draft

Goal: Comments on the translation itself are separate from comments on the content.

Comment instructions options:

Suggestions for translation wording

Use these links for comments on the translation wording itself. If you have comments on the content, please use the links under "Help improve this page".

  • [ruled out] Commenting info near the top with the Translation info / Disclaimer
    • Con: too cluttering at the top. Too distracting. Hopefully won't be needed much!

OPEN: Create new list public-wai-translations@w3.org — comments go to translator email with CC to that list… or maybe a separate public-wai-translations-archive@w3.org list?

Comments are seen by the right people:

[probably not valid with repo set up]

Make sure translator(s) is "Watching" the translations GitHub repo. Translations "manager"(s) (probably Shawn for a while – would be good to have others, too) should watch all translations repos, too.

If comments come to translations repo that are on the content rather than on the translation:

  • Create new GitHub issue in the main repo. Assign it to the current editor (if exists), chairs, team contact.
  • Then can close issue in translations repo with a pointer to where it was moved.

Link to list above the fold options

Archive note: This was when we had the list in the left column below navigation.

Provide a link above the fold that jumps to the list lower in the left column.

Considerations:

  • err on the side of it being highly discoverable, even if more "cluttering" and less visually smooth
  • it is contextual to the page content, rather than site-wide — thus conceptually better in close proximity with the page title (in h1 or navigation)

Location options:

  1. breadcrumb, at end of links (not right-aligned) <-- currently in the mock-up
  2. breadcrumb area, right-aligned
  3. breadcrumb area, first thing on the left
  4. h1, at end
  5. h1 area, float top right
  6. secondary nav area (blue box on left), at end of page title
  7. very top right, at end of "Skip to Content" line

Image and text options:

  1. image only
  2. image and text:
    • Languages
    • Language List
    • Translations

Language list heading options

Archive note: This was when we had the list in the left column below navigation.

  1. Language
    • pro: simple
    • con: users might expect it will change the language of the entire page, whereas it only changes the main content and the navigation that is available in that language
      Note: Current plan is for users to get option to set cookie so that would change the language of other pages they visit that have that language available.
  2. Language of Page
    • pro: maybe clearer that it doesn't change the language of the navigation?
    • con: not quite as smooth
  3. Language of Content
    • pro: maybe clearer that it doesn't change the language of the navigation?
    • con: not quite as smooth
  4. Page Content Language
    • pro: probably clearest that it doesn't change the language of the navigation
    • con: awkward

Select options

Archive note: This was when we were considering Select to reveal the list.

  1. button expands/collapses list: [button mockup](https://w3c.github.io/wai-translation-playground/people-use-web/)
    • pro: can see all languages when expanded
    • pro: better interaction for usability & accessibility
    • pro: can leave expanded (? Can that be site-wide? :-)
  2. [ruled out] drop-down box
    • con: more complex interaction for usability & accessibility
    • con: may not see all languages without scrolling list

Labelling options

Archive note: This was when we were considering Select to reveal the list.

Note in the mockup that the toggle shows and hides the list. Then users click a linked language to select it from the list.

  • The language of the page (e.g, "English" "Français", etc.) as in many examples
  • Change Language
  • Languages or Languages: [just leave wording, not change when list shown]
  • Translations or Translations: [just leave wording, not change when list shown]
  • Select Language
    Hide Language Selector
  • Select Language
    Hide Languages
  • Select Translation
    Hide Translations
  • Show Translations
    Hide Translations List
  • Show Translations
    Close Translations List
  • [add other options if you would like them considered]

Acknowledgements

Project Manager: Shawn Lawton Henry. Contributors: Eric Eggert, Richard Ishida, Stéphane Deschamps, Judy Brewer, Dominique Hazaël-Massieux, @@, and EOWG participants.

Developed with input from the Education and Outreach Working Group (EOWG).

Developed with support from the Ford Foundation.