This enforces a consistent formatting for the PO files. The goal of this
is to avoid large diffs due to random and unnecessary reformatting.
We use the format of `msgcat`: this is also waht `msgmerge` produces and
it’s easy to replicate for people by installing Gettext and running
`dprint fmt`.
This is a follow-up to #1351 which started enforcing that the `msgid`
fields don’t change due to reformatting in a PR.
If this turns out to be cumbersome, then we can disable it again.
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.
Initially, I also formatted the templates in `theme/`, but this triggers
https://github.com/prettier/prettier/issues/11834. So I exclude them for
now.
---------
Co-authored-by: Ming-Ying Chung <mych@chromium.org>
Before, we always used the latest English source files when
publishing. This means that translations become outdated as soon as
anything is changed in the source.
This PR changes will instead freeze translations in place: they will
keep using the same English source files until a new POT file is
merged into the translation. We do this by relying on the
POT-Creation-Date field in the PO files.
We still use up-to-date versions of all other files: this allows us to
fix things in the theme, for example. So the assumption here is that
never versions of our infrastructure remains compatible with old
versions of the Markdown files.
This approach has a problem: when files are moved, the English
translation will link to the new name. This name will not exist in the
old translations. We might be able to disable these links somehow.
Part of google/mdbook-i18n-helpers#16. The
logic here should eventually be moved to somewhere in
mdbook-i18n-helpers, most likely to the renderer that @sakex is
building in google/mdbook-i18n-helpers#84.
In v2 of the course, I'd like to include an estimate of the time to be
spent on each segment in the Markdown file. I think a good place for
such metadata is in the frontmatter.
For review purposes, though, I just want to display that information.
So, this is a start at a new mdbook preprocessor that just separates out
the frontmatter and includes it in a `<pre>` block. Eventually, I'd like
to parse it and put the time in the speaker notes.
---------
Co-authored-by: Martin Geisler <martin@geisler.net>
This updates our `mdbook` version to the latest version in Git. I copied
the `index.hbs` file from that version and back-ported our changes into
it. I checked English and Danish locally and they both look fine.
The new version has support for right-to-left languages:
https://github.com/rust-lang/mdBook/pull/1641.
We have an in-progress Persian translation. Download the `fa.zip`
artifact after building the PR to check how it looks. I checked Persian
locally and it looks mirrored like I expect (but we will need someone
who can read Persian to actually verify this).
Fixes#1164.
Hi all!
This CL fixes#1093:
* Avoids including current false-positives in the checking of typos
* Excludes localization-related files, as `typos` works with
English words
* Fixes existing typos caught in the repo
Tested this in CI with a typo and it showed up in the list of actions!
---------
Co-authored-by: Martin Geisler <martin@geisler.net>
I have created PRs to normalize all PO files to the new version of
mdbook-i18n-helpers. Simultaneously, we need to update the version used
to publish the course.
This is indirectly part of #330.
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.
* Run builds on both Mac OS and Linux
This would have helped us catch #570.
* Fix MacOS CI (#848)
* Revert unnecessary changes
The changes might be good, but I want to keep this PR small and
focused. If we end up with the extra `cfg` statements, we should
include a comment to let students know what they do: we’re targeting
people new to Rust, so we need to be careful with explanations.
---------
Co-authored-by: Dominik Maier <domenukk@gmail.com>
These translations all have more than 200 translated messages and
they’ve been updated in the last month.
I suggest we update the list here every few weeks based on input from
the translators: we don’t need a super strict rule here, we just need
interested translators who would like to see their work celebrated.
I suggest we only link completed translations in the language picker
since we have limited space there to differentiate the different
levels of completeness.
The dprint formatter is a flexible system which will use sandboxed
WebAssembly formatters to format our code (mostly: it calls out to
`rustfmt` for Rust code).
A particularly interesting feature is that dprint can format Rust code
blocks in the Markdown files. However, before we turn that on, we need
to have a way to normalize the Markdown text as it is extracted[1].
That is so that the word put into the translations is kept after the
reformatting.
[1]: https://github.com/google/mdbook-i18n-helpers/issues/19
