Add zh-hans translation for accessibility guide, filter language switcher to translated articles - #3736
Open
czllll wants to merge 3 commits into
Open
Add zh-hans translation for accessibility guide, filter language switcher to translated articles#3736czllll wants to merge 3 commits into
czllll wants to merge 3 commits into
Conversation
Follows the process in docs/translations.md: translated title/description and body, kept front matter field names and non-string values unchanged, and removed the untranslated field now that the translation exists.
The language switcher listed every locale regardless of whether the current article had a translation in it. Picking an untranslated language for an article-type page sent the reader to a 404, since loadLanguage() in assets/js/locale.js rewrites the URL's language segment without checking the target page exists. Filter the dropdown at render time using the same site.articles | where: 'lang' / where: 'class' lookup already used in _layouts/article.html for related-article links, so only languages that actually carry a translation of the current article are offered. Non-article pages (index, static pages) are unaffected since every locale ships those.
_includes/head.html has the same bug as _includes/nav.html: it builds an hreflang link for every locale unconditionally, so an under-translated article ships <link rel="alternate" hreflang="..."> tags pointing at pages that 404. CI caught this via html-proofer's internal-link check on the new zh-hans article (27 dead links, one per locale lacking the translation). Apply the same site.articles | where: 'lang' / where: 'class' guard used in nav.html and in the existing related-article lookup in article.html.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this does
zh-hanstranslation ofaccessibility-best-practices-for-your-project.md, following the process indocs/translations.md: front matter field names and non-string values unchanged,title/description/body translated,untranslatedfield removed._includes/nav.html) and the hreflang alternate tags (_includes/head.html) so, on article pages, only locales that actually have a translation of the current article are offered/linked. Both used the same unconditional loop over every locale, matched viasite.articles | where: 'lang' | where: 'class'— the same lookup already used for related-article links in_layouts/article.html.Why it adds value
accessibility-best-practices-for-your-projectcurrently has no translation in any locale, and picking any language from the nav selector on that article 404s — that's how I found this. The underlying bug isn't specific to this one article: any under-translated article will 404 the same way when a reader switches languages, and (per html-proofer, see below) also ships deadhreflanglinks for SEO crawlers. This fixes the mechanism for all articles, not just this one, and adds one more translated article in the process.Test plan
curlthat/accessibility-best-practices-for-your-project/returned 200 in English and 404 in ~10 other locales before this change.script/testlocally (this environment's Ruby is newer than thegithub-pagesgem in the Gemfile supports, sobundle installfails to resolve). The first commit's fix (nav.htmlonly) went through CI instead: html-proofer failed the build with 27 dead internal links from the new zh-hans page — onehreflangtag per locale still lacking the translation, coming from_includes/head.html, which had the identical unconditional-loop bug. That's what the second fix commit addresses.