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.
This removes a bunch of boiler-plate comments which were left from the
template I used originally.
It also simplifies the name to just “Publish” since I feel this fits
better for what we do here.
