Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use mdbook-i18n-helpers to support translations #356

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

mgeisler
Copy link
Contributor

@mgeisler mgeisler commented May 16, 2023

This PR expands the publishing step to also publish a (very partial) Danish translation of the book. The result of this can be seen here: https://mgeisler.github.io/rust-embedded-book/da/intro/index.html.

The infrastructure uses the GNU Gettext tools, as well as a mdbook plugin:

sudo apt install gettext
cargo install mdbook-i18n-helpers

The translation lives in po/da.po, which was created with

MDBOOK_OUTPUT='{"xgettext": {"pot-file": "messages.pot"}}' mdbook build -d po
msginit -l da -i po/messages.pot -o po/da.po

After creating the da.po file, the translation can be served locally with:

MDBOOK_BOOK__LANGUAGE=da mdbook serve

The publication flow on GitHub has been expanded to publish translations into subdirectories named after the two-letter ISO_639-1 language codes. The English source text stays the same.

Links to the new translations are added manually in the index.hbs theme file. I imported the one from mdbook and added a very simple language picker in the top right corner. If someone knows how to extend the existing file without copying it, then I would love to hear about it πŸ˜„

The whole setup tries to be very pragmatic: publishing a language is decoupled from accepting the PO file into the repository, and linking to a translation is decoupled from publishing it.

I replaced the GitHub pages publish step with one that uses a GitHub action instead of a branch β€” this is not essential, it just matches what I did for my own repository. Feel free to ignore this as you like. Similarly for how the new dependencies are installed and cached: this is just a cargo install mdbook-i18n-helpers behind the scenes.

Fixes #326.

This PR expands the publishing step to also publish a (very partial)
Danish translation of the book.

The infrastructure uses the GNU Gettext tools, as well as a mdbook
plugin:

    sudo apt install gettext
    cargo install mdbook-i18n-helpers

The translation lives in po/da.po, which was created with

    MDBOOK_OUTPUT='{"xgettext": {"pot-file": "messages.pot"}}' mdbook build -d po
    msginit -l da -i po/messages.pot -o po/da.po

After creating the da.po file, the translation can be served locally
with:

    MDBOOK_BOOK__LANGUAGE=da mdbook serve

The publication flow on GitHub has been expanded to publish
translations into subdirectories named after the two-letter ISO_639-1
language codes. The English source text stays the same.

Links to the new translations are added manually in the index.hbs
theme file[1]. I imported the one from mdbook and added a very simple
language picker in the top right corner.

[1]: https://raw.githubusercontent.com/rust-lang/mdBook/master/src/theme/index.hbs
@therealprof
Copy link
Contributor

Thanks for the PR. This looks like a great step into the right direction as it is similar to a lot of other projects which have taken the gettext route.

I think we'll need to gauge the interest in the community to help with the translation though since simply having the mechanism to provide all translations from the same repo and maintaining it together is not providing a lot of benefit on it's own and actually increases the maintenance effort required.

Experience from past projects which have taken the exact same route (From English only version over full external translations to gettextized approach) like https://docs.gimp.org/ show that the setup requires a lot of initial work (partially done by this PR), often a restructuring of the existing text to better suit the paraphwise translation mechanism better and a lot of heavy lifting to get a signifcant chunk of translation going before becoming a community driven effort.

Also having the translations in this repo means that now the WG is required to judge the conformance of the offered translations to the community guidelines which might be close to impossible for some languages...

@mgeisler
Copy link
Contributor Author

Hi @therealprof,

Thanks for the PR. This looks like a great step into the right direction as it is similar to a lot of other projects which have taken the gettext route.

I'm glad you know the system! The infrastructure here is actually the same as what I wrote ~10 years ago for the Mercurial project πŸ˜„ As you say, it's a well-known system for software (less so for books).

I think we'll need to gauge the interest in the community to help with the translation though since simply having the mechanism to provide all translations from the same repo and maintaining it together is not providing a lot of benefit on it's own and actually increases the maintenance effort required.

Experience from past projects which have taken the exact same route (From English only version over full external translations to gettextized approach) like https://docs.gimp.org/ show that the setup requires a lot of initial work (partially done by this PR), often a restructuring of the existing text to better suit the paraphwise translation mechanism better and a lot of heavy lifting to get a signifcant chunk of translation going before becoming a community driven effort.

I agree, having the infrastructure is only the first step. Actually, people often show up with translations even without having a system in place, as show by all the issues here: https://github.com/rust-lang/book/labels/Translations. For Comprehensive Rust, we had the first translation appear out of the blue about two weeks after we published the course β€” which prompted me to prioritize the plans for writing a i18n infrastructure.

One step (which I haven't yet done for the Rust course) is to guide people to an online platform for the translations. I'll probably set that up eventually since I hope it will lower the barrier to entry for people.

Also having the translations in this repo means that now the WG is required to judge the conformance of the offered translations to the community guidelines which might be close to impossible for some languages...

Yes, that's very true! For my Rust course, I have the advantage of being able to draw on a vast network of other Googlers, so I can find someone who speaks almost any language πŸ™‚ For other projects, I would apply a simpler standard: let the first person who show up speaking language X be the maintainer of that language. They can then work with other contributors to determine a consistent way to translate the technical terms. Where possible, I've suggested to the translators that they should mimic the translations of the Rust book, but it's not something I'm able to actually check or enforce.

In any case, I hope people can give it a try. If someone (such as @DownyBehind from #350 and @Jzow from #326) wants to play with a Gettext-based translation, then they're free to open PRs against https://github.com/mgeisler/rust-embedded-book. That repository can be a temporary "translation playground" so that you don't have to deal with anything in this repository.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

I think this repository can support more languages
2 participants