Restructure for translations#6
Conversation
|
LGTM as long as it's good for the moon-landing side (especially on how to handle missing pages in a given language). |
|
See the PR I opened in moon-landing: https://github.com/huggingface/moon-landing/pull/2028. The course structure in this PR will work out-of-the-box w/ it.
The moon-landing PR only takes care of handling the new structure, the language in the URL, and returning the matching content. Pinging @gary149 on those points since it's a UX/UI decision (a decision that is not blocking for merging this PR since nothing will change visually on hf.co for now) |
Cleaner svelte imports
Thanks a lot for adding support for the translations on the |
|
Your plan LGTM @lewtun! 👍 Will merge https://github.com/huggingface/moon-landing/pull/2028 once this one is merged. |
…nslations Restructure for translations
This PR restructures the chapter content to enable the frontend to toggle between different languages. After discussing internally with @Pierrci we've settled on the following tree:
Here, the idea for translators is to (minimally) copy-paste the table of contents file
_chapters.ymland one or more chapters to translate. I've translated the first chapter to Spanish so we can test it on the frontend when this PR is merged.Questions
moon-landingto resolve the specific language directories likeenandes?_chapters.ymlbe filled out to match the English source? For the Spanish example, I've only included the entry for the single translated chapter, but I'm wondering if this will cause havoc with the table of contents on the left-hand side of the website?cc @mishig25 @julien-c @sgugger (since this might be relevant for the community-driven translations of our library docs)