1
0
mirror of https://github.com/google/comprehensive-rust.git synced 2025-01-09 01:02:47 +02:00
Commit Graph

7 Commits

Author SHA1 Message Date
Andrew Walbran
ecbb7e41bb Format imports with imports_granularity = "Module". 2023-03-20 14:26:57 +00:00
Andrew Walbran
f0b59d0818 cargo fmt 2023-03-20 14:26:57 +00:00
Dustin J. Mitchell
ba28dd2d4c
Parse Markdown in mdbook-xgettext (#449)
* Parse Markdown to support translation.

This upgrades from just splitting Markdown files on double-newlines, to
using a Markdown parser to break them into more appropriate chunks. The
upshot is that code samples are all in one message, lists are bundled
together, and generally it should be easier to translate.

* [WIP] helper to update po files for new translation

* process synthetic input file-by-file

* review comments

* remove temporary code

* fix msgfmt lints
2023-03-07 18:07:07 +00:00
Jooyung Han
1821a3fd12
Make i18n-helpers a requirement (#461)
* 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>
2023-02-28 22:05:09 +09:00
Andrew Walbran
20f02db5f5
Add a cargo workspace containing both crates (#321)
* 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.
2023-02-02 16:14:34 +00:00
Martin Geisler
690039fd53
Filter out “fuzzy” translations (#212)
When the source text is updated, existing translations become
outdated. The `msgmerge` program will attempt to find a similar source
text among the existing translations and will reuse the translation.
The translation is marked “fuzzy” to signal to the translator that it
needs to be proofread.
2023-01-28 14:36:57 +01:00
Martin Geisler
48ec773052 Add support for translations
This implements a translation pipeline using the industry-standard
Gettext[1] system.

I picked Gettext for the reasons described in [2] and [3]:

* It’s widely used in open source software. This means that there are
  graphical editors which will help you in editing the `.po` files. An
  example is Poedit[4], which is available for all major platforms.

  There are also many online systems for doing translations. An
  example is Pontoon[5], which is used for the Rust website itself. We
  can consider setting up such an instance ourselves.

* It is a light-weight yet structured format. This means that nothing
  changes with regards to how you update the original English text. We
  can still accept fixes and PRs like normal.

  The structure means that translators can see exactly which part of
  the course they need to update after a change. This is completely
  lost if you simply copy over the original text and translate it
  in-place in the Markdown files.

The code here only adds support for translations. They are not yet
tested, published or used for anything. Next steps will be:

* Add support for switching languages via a bit of JavaScript on each
  page.

* Update the speaker notes feature to support translations (right now
  “Speaker Notes” is hard-coded into the generated HTML). I think we
  should turn it into a mdbook preprocessor instead.

* Add testing: We should test that the `.po` files are well-formed. We
  should also run `mdbook test` on each language since the
  translations can alter the embedded code.

Fixes #115.

[1]: https://www.gnu.org/software/gettext/manual/html_node/index.html
[2]: https://github.com/rust-lang/mdBook/pull/1864
[3]:
https://github.com/rust-lang/mdBook/issues/5#issuecomment-1144887806
[4]: https://poedit.net/
[5]: https://pontoon.rust-lang.org/
2023-01-18 16:12:53 +01:00