Test translated pages #1350
Test translated pages #1350
Conversation
|
Visit the preview URL for this PR (for commit cd092ad): https://cp-algorithms--preview-1350-pubcypqk.web.app (expires 2024-10-19T11:06:55.610634926Z) |
|
So, see e.g. https://cp-algorithms--preview-1350-pubcypqk.web.app/pt/. Navigation still only refers to English pages, and the site GUI is in English as well. squidfunk/mkdocs-material#2346 includes some potential ways to address it, like adding to mkdocs overrides. So, it's probably better to keep things somewhat connected to be in proper sync with each other, but maybe put out language-specific files in separate repos for more granular maintainer access and to keep github histories separate. So, e.g. a separate fork repo could build its own "staging" version of the site, and then new changes would be merged into main site automatically once every day or week. |
|
I’m not very familiar with MkDocs to be honest, but I’m more than willing to contribute by translating the content into Portuguese in the best way I can. Initially, my idea was to fork the repository and create a self-hosted mirror in Portuguese. However, if implementing the modifications you’re suggesting for cp-algorithms is feasible, I’d be happy to collaborate in that direction as I think it would be a great approach. If we go down that path and add a language selector to the cp-algorithms site, I believe it’s important for the navigation to clearly indicate which languages each article is available in. For example, if I choose to browse the site in Portuguese, the navigation should still show all the articles but highlight which ones are available in Portuguese and which aren’t (perhaps with a flag or some other indicator). |
|
I'm against adding support for multiple languages. |
|
Alright, closing this for now. |
Addresses #1311 as a proof of concept.
In principle, one way to maintain translated versions is to keep them in
/pt/,/en/, etc subfolders of the main directory and specify it inmkdocs.ymlasextra/alternate. There are some obvious issues that we need to address:mkdocs.yml, e.g. to maintain a separate search index. One way to work with it is found at Setting up multi-language installations squidfunk/mkdocs-material#2346.Generally, taking (1) and (2) into account I feel like it could be easier to make a separate fork repo for each interested language that will be maintained independently, and then set up the navigation between them in
extra/alternate. Though doing it in this manner can complicate sync of technical changes, e.g. inmkdocs.ymlor other files that are more related to the site engine than the content.