Repository navigation
feat: add the docs in the nine other languages of the app - #227
Merged
Merged
Conversation
Every page of the 7.x docs in Catalan, German, French, Italian, Dutch, Polish, Portuguese, Japanese and Simplified Chinese, under their ISO 639-1 code like /es/. Each one uses the wording and the form of address of the app's own locale, so a label on the site reads the same as on screen. The language selector lists the eleven languages in the app's order, and a browser in any of them lands on its docs from the root and the old addresses. Japanese and Chinese have no spaces between words, which left search with nothing to match in those two builds. Their index now splits runs of those characters into pairs, on the pages and in the query alike.
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
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.
The docs are now in all eleven languages the app ships: Catalan, German, French, Italian, Dutch, Polish, Portuguese, Japanese and Simplified Chinese join English and Spanish, each under its ISO 639-1 code (/ca/, /de/, /fr/, /it/, /nl/, /pl/, /pt/, /ja/, /zh/), built the same way as /es/.
Every page of the 7.x docs is translated, 195 per language, and stamped with
translated_from, soscripts/i18n-status.shreports nothing missing or out of date for any of them. The on-screen labels follow each language's locale file in the app, form of address included (du/Sie and so on), so the docs say what the screen says. Where a locale file is missing accents ("Esegui piu tardi", "Zeitplaene") the docs write them properly. Code, config keys, link targets and quoted log or error messages stay in English, the same as in the Spanish pages.The language selector lists the eleven in the app's order,
ui.ymlhas the interface strings for each, and every language has its owni18n/<code>.yml. The root and the old addresses already pick the reader's language from the browser, so nothing changes there.One fix beyond the text: search found nothing in Japanese or Chinese, because lunr splits on spaces and its trimmer then removes every non latin character.
_includes/lunr/custom-index.jsnow splits runs of CJK characters into pairs in those two builds only, both in the index and in what the reader types. The other languages keep the theme's search unchanged.How I checked it: a local build of the whole site with the same steps as the workflow, no warnings. Every translated page has the same headings in the same order as its English page, so all heading ids in the build match the English ones in every language. Code blocks, Liquid tags, kramdown attributes, links and tables are identical to English, and the menu has the same 196 entries in every language. Search was run against the built Japanese and Chinese indexes. Internal links and anchors were checked across all eleven builds.
Two links were already broken in English and Spanish and still are in every language: the
#build-your-own-rteanchor in upgrade-7 and the FAQ anchor#how-do-i-access-parent-form-data-inside-a-subformfrom the wizard page. I left them for a separate fix.