WAI Translations
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
- Instructions to Translators
- Comments on translation vs. content
- Content negotiation for language and cookies
- Motivation, Recognition
- Using GitHub, Markdown, HTML
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:
- check if there is an existing GitHub issue (opened and closed) for your point:
- if so, add your comment to the existing issue (and if it is closed, re-open it)
- if not, create a new GitHub issue
Background
From W3C Internationalization:
- Guiding users to translated pages
- Navigation section (the last section) of Authoring HTML & CSS including:
- Linking to localized content
- Using content negotiation
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 " that provides a list of all languages and all pages in a specific language.
- Far right is "Hide Options [-]"
Getting to a translation from a specific page/resource:
- Language list on individual pages - in two places:
- Top, right aligned
- 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:
- List of all resources in a specific language.
- Instructions for translators "Translating WAI Resources"
They are linked in multiple places:
- On all pages, at the top right is "All Translations "
- 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:
- blank flag: World Digital Library has at top right a little gray flag and arrow that displays list.
- flag cluster and now also "Language": W3C CSS pages has flags image at the top right that links to list at the bottom of the page. list has no separator character.
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 left column, low down: Wikipedia home has just the languages (no other content). Wikipedia main page has Languages listed in the left column, lower down.
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
- 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.
- [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:
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:
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):
- 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
- 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
- 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?"}
- note:
- 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)
- 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)
- comma
- icon such as or
- 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:
- 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.
- 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?
- 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
- 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
- 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)
- other translations icons
- 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
- series of characters (old WAI site used)
- pro: short height so doesn't add space
- con: maybe not understandable and just confusing
- [ruled out] 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:
- UI/design of this page - input in User experience for the list of resources in language below.
- Where does this page live in the IA (for the breadcrumb)?
- Integrating relevant TR translations...
Links to list of resources in language
- "All Translations " 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.
- 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.)
- [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):
- 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:
- 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:
- 3: Translations disclaimer wording - in Translations Info box
- 2: Translations thanks and link wording - in Translations Info box
- 1: Translation up to date or not wording & icons - in Translations Info box
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
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:
- 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:
- 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.
- 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:
- icon to indicate "in English" - probably [EN]
- text to indicate "in English" - probably "(EN)"
- Italicized (in addition to "EN" or other easily-visually-discernable and programmatically-determined indication)
- … other ideas? …
- 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
- [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:
- 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). - Link to English version (maybe in breadcrumb area)
- 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.)
- List of all WAI pages in that language (probably in secondary nav area (left column))
- 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:
- Examples of translated navigation going to English (or other language) pages with an indication:
- ?
- Examples of navigation not translated:
- Czech Chcete se naučit základy webového designu? Začněte tady.
English Want to Learn Web Design Basics? Start Here - several listed under Examples section
- Czech Chcete se naučit základy webového designu? Začněte tady.
- Examples of all navigation pages translated (that is, the linked page is translated):
- English Atmedia 2005 wind-down: everything you’d want to know (or not)
French Tout ce que vous vouliez savoir sur atmedia2005 (ou pas) - several listed under Examples section
- English Atmedia 2005 wind-down: everything you’d want to know (or not)
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:
- 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, options:
- Title translated and include in the link "(in English)" in that language, <--proposed
e.g., Quelques utilisateurs du Web (en anglais) - Title translated and in English and include in the link "(in English)" in that language,
e.g., Quelques utilisateurs du Web (en anglais: Stories of Web Users) - Title in English and not include in the link "(in English)" in that language,
e.g., Stories of Web Users - Title in English and include in the link "(in English)" in that language,
e.g., Stories of Web Users (en anglais)
- Title translated and include in the link "(in English)" in that language, <--proposed
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.
- Background: When to use language negotiation
- Example: W3C i18n pages
Setting preferences
Proposed:
- Use content negotiation for language.
- If user selects another language, offer cookie setting like i18n does.
Serving pages
Proposed:
Long description for “Proposed workflow for serving pages according to language” schema:
- Does the user have a language cookie?
- If yes, go to Check for page in language
- If no, continue
- Language negotiation: is the browser requesting a language via
HTTP_ACCEPT_LANGUAGE
? - If no, go to Serve original page
- If yes, continue
- Check for page in language: is there a page in this language?
- If yes, go to Serve page in user language
- If no, go to Serve original page
- End result: two possible outcomes
- Serve page in user language
- Serve original page
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.)
- OPEN How?
- 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:
- Inform translators of what needs to be updated.
- 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)
- If the comment is on the translation itself:
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.
- A translator signals their desire to translate a WAI resource by sending e-mail to public-wai-translations and w3c-translators lists.
- 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.
- Preparation: update frontmatter per below, update link markup.
- e-mail template below
- Records it in W3C Translations Management.
- 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.
- 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.
- After the translation "passes" review, staff
- publishes it.
- sends e-mail to public-wai-translations and w3c-translators lists.
- updates its status in W3C Translations Management.
Misc Notes
- Old process notes are archived below.
- We might get translations that messed up the markup/markdown.
- Eventually we might have separate language-specific lists. Related info: https://github.com/dontcallmedom/github-notify-ml/ & configuration for i18n
- Possible sticky situations:
- 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?
- tracking translations – related: i18n translations tracking GitHub project, W3C Rec database tracker plans, W3C Translations Management
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:
- @@ To Do: Guidance for specific languages — like a translations "glossary" for common and challenging terms and phrases (especially important for careful translation of disability wording). add to frontmatter & e-mail
- Shawn coordinating with Dom to make stuff re-usable/synched with W3C-wide info for /TR/ translations, as much as feasible
- WCAG 2.1 note
- Related info: i18n Translator's checklist, i18n Translation instructions, CSS Translations , old Translating WAI documents
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:
- Important Translations Guidance https://www.w3.org/WAI/about/translating/#important [@@may move elsewhere later when there is more]
- Translation Notes for this resource [@@link]
- Translation Notes for your language, if available [@@link]
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
- [Guiding users to translated pages](https://www.w3.org/International/questions/qa-site-conneg)
- [Restarting W3C Volunteer Translation Tracking](https://lists.w3.org/Archives/Public/w3c-translators/2018JulSep/0048.html). It proposes: based in github, minimal quality reviews, W3C automatically publish it. It is for /TR/ documents (not most WAI pages) for the first phase. We will coordinate to maximize efficiencies now and for possible future integration.
- [i18n Translation instructions](https://www.w3.org/International/2004/06/translation.en.html)
- [Translator's checklist](https://www.w3.org/International/2004/06/translation-checklist)
- [CSS Translations](https://www.w3.org/Style/CSS/translating.en.html) = instructions to translators
- [WCAG 2 Translations](https://www.w3.org/WAI/standards-guidelines/wcag/translations/)
- [Policy for Authorized W3C Translations](https://www.w3.org/2005/02/TranslationPolicy)
- … {other examples of how translations are handled in UIs, policies, etc.}
Archived Analysis and Past Proposals
Status: Proposals below were replaced by decisions above.
EOWG questions:
Archive note: This was for 23 October 2018 meeting.
- Comments on straw proposals above? (Goals, options, pro, cons, and considerations are listed throughout this page.)
- Comments on Image/icon options?
- Who would be interested in helping format or check translation submissions? Need to be comfortable with markdown and GitHub.
- 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
- 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.
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.
- 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. - 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.
- 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
- What can be automated?
- (ee note) Unsure what can be automated or how one would implement such an automation.
- 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
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):
- 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)
- 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
- 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
- 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
- Web Content Accessibility Guidelines (WCAG) Overview
- pro: of broad interest around the world
- pro: fairly straightforward; medium length
- 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:
- 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/)
- Instructions to translators -- AUDIENCE: translators
- Translations priorities -- AUDIENCE: translators
Proposed:
- "Languages" new page under https://www.w3.org/WAI/roles/ <-- proposed
- Options:
- 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
- [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
- 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
- includes link to Translating WAI Documents
- possibly also link to WCAG Translations
- Options:
- 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.b. "Change Text & Colors" and [icon]
2.c. "Change Text Size or Colors" and no icon
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.)
- In "desktop" view, list will default to visible. Users can hide the list. Cookie makes that persistent. Collapsed text is "... Show Languages".
- After list is "All Translations " that provides a list of all languages and then all pages in a specific language.
- Mobile/small viewport:
- When no translations, mobile & desktop has at top right: "All Translations " 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:
- List of all resources in a given language.
- 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:
- On home page, in "Get Resources for…" section, last link is " 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:
- 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.
- 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
- 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:
- 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 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"?- The toggle "label" after the icon is "Languages"
[ Languages ]
- pro: probably best option if non-English speakers know the word "Languages"
- con: not common in examples found
- (other label options)
- The toggle "label" before or after the icon is the current language (usually "English" or the reader's language from language negotiation):
[ English ] or [ français ] or [ Deutsch ] 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
- [ruled out] When on a non-English page, English is first and linked, then the language, then the icon:
English(original) français [ ]
- 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
- The toggle "label" after the icon is "Languages"
- 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
- [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:- 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)
- [image] Different languages
- pro: follows better after "Get Resources for…"
- [image] Translations
- con: confusion with "Translations" in footer that goes to translations overview page.
- pro: simpler wording, common terminology
- Languages
- 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")
- 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)
- 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
- 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)
- [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
- [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
- [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:
- Commenting info near the bottom, right before "Help improve this page" box. <-- proposed
Maybe similar box?
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:
- breadcrumb, at end of links (not right-aligned) <-- currently in the mock-up
- breadcrumb area, right-aligned
- breadcrumb area, first thing on the left
- h1, at end
- h1 area, float top right
- secondary nav area (blue box on left), at end of page title
- very top right, at end of "Skip to Content" line
Image and text options:
- image only
- 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.
- 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.
- Language of Page
- pro: maybe clearer that it doesn't change the language of the navigation?
- con: not quite as smooth
- Language of Content
- pro: maybe clearer that it doesn't change the language of the navigation?
- con: not quite as smooth
- 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.
- 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? :-)
- [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.