Before we would run `mdbook test` using the current Markdown sources.
This is subtly wrong: we publish the course using back-dated sources,
so we should therefore also run the tests using the same sources (this
ensures that the code snippets actually work).
After this commit, all translatable content lives in exactly two
directories:
- `src/`
- `third_party/`
We need to restore both directories when testing and when publishing.
This ensures consistency in the Markdown text and in the included
source code.
A new `.github/workflows/build.sh` script takes care of preparing the
two directories according to the date in the PO file (if any).
To ensure we can restore all of `third_party/` to an old commit, the
non-changing `third_party/mdbook/book.js` file has been moved to
`theme/book.js`. The file is generated by `mdbook init --theme`,
making it suitable for modification by the user (us). Symlinks have
been added to `third_party/mdbook/` to indicate that the files
ultimately came from upstream.
This also ports over the latest changes to `book.js` and `index.hbs`.
We probably need to come up with a more systematic way of doing this,
e.g., we could store our changes in a patch and automatically attempt to
apply it onto the latest upstream files.
I also updated `book.js` and `index.hbs` to the latest versions while
keeping our local modifications.
I tested this locally with `mdbook serve` for both English and
Brazilian Portuguese and everything seems to work fine.
* Integrate GA4 code directly with `book.js`
The main advantage of this is that it simplifies the setup since we
can avoid the monkey-patching we did before.
A secondary advantage is that it should make things a little faster
since we avoid a request to the server on every page load.
* Remove unreachable return
* Watch all of `third_party`
It just occurred to me that we want to refresh the page in `mdbook serve` when anything changes in `third_party`.
We often see timeouts when running the course. Most of the time, the
code compiles on the second try, which indicates that we just need to
wait a little longer.
Fixes#406.
