Open charlesreid1 opened 6 years ago
The user points to a docs/
folder as inputs, we generate a docs_translation/
folder as output. This step is documentation-agnostic, and just requires github-flavored markdown.
Option 1: Assume the user has or wants mkdocs. We load an existing mkdocs.yml
for docs
and we create a new mkdocs_translation.yml
for docs_translation/
. This literally gets the user a duplicate mkdocs site. (This is exactly what we want: the user runs one step and they're finished.)
Option 2: Don't assume anything about the user's documentation system. (More flexible, but also leaves the user with a pile of translated docs and no clear next steps.)
Option 3 (please kill me): deal with Sphinx stuff. This runs counter to the entire frickin point of the frickin project. The project is: "Here's a pile of Markdown. Here's a language. Gimme the frickin docs."
Give the user an --mkdocs
command line flag. If they have an mkdocs.yml
file, this command line option will load it, translate the page titles, and deposit the new file in mkdocs_translation.file
.
One of the problems we are having with page elements not being translated is not a markdown/pandoc issue, it's an mkdocs issue.
Specifically, when we generate russian-rainbow-mind-machine documentation we generate the Russian docs from the English docs. But the
mkdocs.yml
file for our Russian docs contains page titles that are still in English.We need to include a step to generate an
mkdocs.yml
file. This raises other issues about how we want this repository to be organized and how we want it to generate files. Need to think this through before jumping in.