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
This makes the translation available on the official site. It's not linked yet, but having it available there should make it easier to review the state.
This requires us to run a nightly Rust for our formatting check[1]. Other
users will see a warning when invoking `rustfmt`:
Warning: can't set `imports_granularity = Module`, unstable features
are only available in nightly channel.
This should be harmless overall and help us ensure better consistency
in our import formatting.
[1]: https://rust-lang.github.io/rustfmt/?version=v1.5.1&search=#imports_granularity
* Remove unnecessary jobs names
They are inconsistent with the rest of the jobs and they overflow the
horizontal space in the GitHub UI.
* Remove unnecessary toolchain action
The GitHub runners include rustup and a recent stable Rust. We only
need to add the necessary target and we’re good to go.
This removes a lot of warnings because the action used an outdated
GitHub API: https://github.com/actions-rs/toolchain/issues/219
* Simplify job name
The job is testing a single translation, so it should be singular.
* Test English source with translations
This simplifies the workflow a little and ensures that we get
artifacts uploaded of the English version for every PR.
* Avoid shell command chain
GitHub actions supports setting the working directory directly.
* Upload only the book artifact
Right now, the artifacts all contain the same two top-level folders:
html/ and exerciser/. The former is what we actually deploy, the
second is a side-effect of the exerciser plugin.
With this change, we only upload the HTML and we ensure the zip file
for the xx language has a top-level comprehensive-rust-xx/ folder.
This makes it much nicer to use the generated artifacts.
The i18n-helpers are now available as a stand-alone crate:
https://crates.io/crates/mdbook-i18n-helpers.
Because we cache the Rust binaries in our GitHub workflows, I bumped
the cache prefix to ensure we use a clean cache. Otherwise, Cargo
won’t install the new binaries in mdbook-i18n-helpers because it sees
the old ones from this repository.
* Update mdbook to 0.4.28
This version contains https://github.com/rust-lang/mdBook/pull/1986 which will allow us to test the code in each translation.
* Fix formatting in Korean translation
The extra code block made `mdbook test` fail.
* Make i18n-helpers a requirement
* Skip mdbook-gettext for mdbook-xgettext
* Gettext finds PO file based on `book.language`
* Update workflow
No need to set `preprocessor.gettext.po-file`.
---------
Co-authored-by: Jooyung Han <jooyung@google.com>
The picker is a drop-down menu using the same design as the theme
picker in the top-left.
There doesn’t seem to be an easy way to pass in a list of languages
and descriptions, so for now we’ll have to expand the menu by hand as
we add new languages. A comment has been added to `publish.yml` to
remind us of this.
* Move Cargo.toml for exercises to exercises directory.
* Create a workspace with both exercises and i18n-helpers.
* Build in CI as well as testing.
* Binaries must have a main function.
* No need for workspaces configuration for caching anymore.
This changes the build workflow to first list all available `.po`
files, and then use this information to start parallel jobs which test
each translation.
* add ko.po
* translate ko(~23.01.19)
* change speaker-note ko
* change id
* translate ko(~23.01.20)
* ~day3 keynote
* draft done to f3446a91
* add @jiyongp comments of upstream PR #276.
* sync & apply review comments(upstream)
sync 585509bb
* After 10000 line apply review comments(upstream)
* chgange build.yml
* Fix the inconsistent newline character problem for the KO translation
If a msgid does not end with the newline character, so should the
msgstr.
Test: msgfmt --statistics -o /dev/null po/ko.po
No error, but shows `1085 translated messages, 675 untranslated
messages.`
---------
Co-authored-by: Evan kim(cli) <keispace.kyj@gmail.com>
This publishes translations (currently only the Danish translation) to
subdirectories named after the ISO 639-1 language code: “da/” for
Danish, “ko/” for Korean, etc.
The list of translation is an explicit list to make it easy for us to
enable/disable translations without being tied to the files in po/.
This allows us to experiment with a translation without publishing it
immediately.
I propose that we eventually move the English pages to an “en/”
directory for symmetry with the other locales. However, for now, the
pages remain at the room of our site (which works fine since we don’t
have a subdirectory named “en/” in the course).
* Extract common build steps to composite actions
This allows us to repeat ourselves less across the different jobs.
I also tested using a “reusable workflow” to factor out the common
steps. However, this starts a separate job without a shared
filesystem, which in turn requires us to upload/download artifacts
when we want to use them in several jobs. The artifacts are downloaded
one-by-one and this adds delays and extra steps to all jobs.
* Move Rust cache setup to its own build step
This made it easy to consistently setup the caching of our nested
projects via the “workspacs” config key.
