Repository navigation
Conversation
Adds a po/ catalogue compiled by i18n.gettext and a gettext-rs setup that
initialises the text domain in main() before any widget is built. The
translatable="yes" strings in the compiled .ui (from the _("...")
calls in window.blp) resolve through the same domain.
Extraction is configured in po/meson.build with the keywords the code
actually uses (i18n, i18n_f, i18n_k, ni18n, gettext_noop, gettext).
POTFILES lists both the Blueprint source and the Rust files that carry
translatable strings; no --language is forced so xgettext's C parser
doesn't choke on Rust lifetimes in the .rs files.
Wraps every string the user sees in i18n/i18n_f/i18n_k/ni18n so the catalogue actually gets used, and marks the static capability-registry strings with gettext_noop so xgettext extracts them (translated at render time). rsync-events' exit-code messages now go through gettext too — a plain libc binding, not a GUI dependency, so the crate stays testable on any host. Rust's format! cannot take a translated string as its format, so i18n_f/i18n_k do the placeholder substitution after gettext.
Full es.po catalogue and an es entry in LINGUAS and the metainfo <languages> block. Castilian Spanish throughout.
Uses ngettext for the change/file/rule counts instead of the hardcoded
(s) plural, and routes the remaining loose labels (Starting…, Scanning…,
Done, Choose a preset…, and the Exclude/Include dropdown) through
gettext. The dropdown strings in window.blp now use _("...") so
blueprint-compiler marks them translatable.
Owner
|
Thank you for this — a whole translation layer and a complete catalogue is a lot of work, and the approach (standard gettext through Meson, strings routed through helpers, I want to review this a little more. There's a lot more that will be done, and it would be more work to add this now. Two things first, both my doing rather than yours:
|
Author
|
Works for me. I'll hold until 1.0.2 is out, then rebase and pick up the new strings (filter-rule warnings, the confirmation dialog, whatever else lands) in a single catalogue update. |
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
This PR gives Foresight a real translation layer and ships the first catalogue: Spanish (Castilian). The UI is now fully translatable and translated — menus, dialogs, the capability registry, and the rsync exit-code messages.
Foresight had no i18n at all. This adds the standard GNOME/gettext setup and routes every user-facing string through it.
How
po/catalogue —LINGUAS,POTFILES,meson.buildwithi18n.gettext, andforesight.pot. Meson compiles and installs the.mofiles intolocaledir.gettext-rs+ domain setup —main()callssetlocale/bindtextdomain/textdomainbefore any widget is built, so thetranslatable="yes"strings in the compiled.ui(from the_("…")calls inwindow.blp) resolve through the same domain.i18nhelpers (crates/foresight/src/i18n.rs) —i18n,i18n_f(positional{}),i18n_k(named{name}),ni18n, andgettext_noopfor the static capability table. Rust'sformat!can't take a translated string as its format, soi18n_f/i18n_kdo placeholder substitution after gettext.rsync-eventsnow translates its exit-code messages throughgettext-rs— a plain libc binding, not a GUI dependency, so the crate stays testable on any host.es.po— full Castilian Spanish catalogue.CONTRIBUTING.md— documents the translation workflow so new languages are easy to add.Extraction
xgettextis configured with the keywords the code actually uses. The Blueprint source is extracted via--keyword=_; the Rust sources via thei18n*keywords. No--languageis forced, so xgettext's C parser doesn't trip over Rust lifetimes in the.rsfiles (learned by measuring).Verification
cargo test --workspacepasses (the one timing-sensitive cancel test is flaky on fast machines — pre-existing, verified against the base commit).cargo clippy --all-targets -- -D warningsandcargo fmt --checkclean.meson test(metainfo validation) and install of the.mofile verified.gettextresolves e.g. "Dry Run" → "Simulación", "Sync completed." → "Sincronización completada." with the installedeslocale.Suggested follow-ups (not in this PR)
These are the author's calls, so I left them out:
LICENSEfile (the Cargo.toml and meson.build already say GPL-3.0-or-later).SECURITY.md,CODE_OF_CONDUCT.mdand.github/ISSUE_TEMPLATE/— standard community files for a public repo.Closes #1