plume-org / gettext-macros Goto Github PK

• Check that the number of format arguments matches the one in the source string.
• Check that the same arguments are used in source strings and translations in compile_i18n?

see Plume-org/Plume#769

main uses rt_format. plural_fix does not, it uses a custom, far more limited, but sufficient function for that.
It would be nice to port that function to main (and maybe update plural_fix so it's not 17 commits behind main)

Hey there! Thanks for developing this crate, it is well appreciated since we use it for Hagrid.

I noticed there is a version 0.6 on crates.io, but this repository contains only version 0.5.2?

when I update to gettext-macros to 0.6, I'm receiving this error from gettext during compilation:

.../hagrid/po/hagrid/hagrid.pot:35: keyword "email" unknown

-> line 35 of hagrid.pot:

msgid "We found an entry for <span class="email">{{ query }}</span>:"

It seems that gettext-macros doesn't escape quotation marks in its .pot output anymore?

Relatedly (#15), I couldn't look into this issue myself since there's no source for it :)

They are making diffs bigger for little value

see SpaceManiac/runtime-fmt#7

please bump the version to 0.4 :)

I don't know if proc-macros allow this, but if they do it would be better than using files to store config/state, as it would mean a lot less I/O.

The current workflow works well with Weblate I think, but for Crowdin, being able to only compile po to mo, and not pot to po would be nice, since Crowdin is doing this step itself and thus causes conflicts.

I don't know what the syntax for that should be. Ideally, if it possible to access token outside of proc-macros calls, we should look for a comment starting with // CONTEXT: … or something like that.

In order for the proc macro to recognize the argument properly, I need to put parentheses around struct properties.

i18n!(catalog, (my_struct.my_property))

This causes a lot of compile warnings, since Rust thinks the parentheses are unneeded. If I remove the parentheses, I get compile errors, since the macro stops reading at the .

The current build process is a bit complicated/fragile for the following reasons:

1. The fuzzy matches msgmerge creates are not reported during cargo build
2. errors are out of context (e.g. #7, or sometimes when it doesn't find the po/$DOMAIN/ folder)
3. include_i18n! panics when translations/ doesn't exist, but this folder is only created by compile_i18n!, which is executed after
4. the translations folder, and .pot files are compilation artifacts, but aren't in target/
5. CARGO_TARGET_DIR is only set by the user, Cargo only reads it (rust-lang/cargo#5457), (

   gettext-macros/src/lib.rs

   Line 366 in 27483fa

   let out_dir = Path::new(&env::var("CARGO_TARGET_DIR").unwrap_or("target/debug".into()))

   ). It will later be available in build scripts (maybe), but it is absent in proc_macros
6. cargo build has to be run twice to apply changes in .po files

I suggest that:

1. init_i18n and compile_i18n should be normal functions, that are to be called in a build script.
   Output of build scripts is inhibited by Cargo, except when it's formatted as cargo:warning=..., then it shows as a compilation warning. Warnings can be used to show msgfmt --statistics output (especially to see if there are new fuzzy translations).
2. translations/ should be target/translations/
3. target/debug/gettext_macros/$DOMAIN should be inside target/translations, because it's common to debug and release builds

So.. an example of the new process would be:

// src/main.rs
extern crate gettext_macros;
extern crate gettext_utils;
use gettext_macros::{i18n, include_i18n};

fn main() {
    let catalog = &include_i18n!()[0].1;
    let s = i18n!(catalog, "Translated string");
    println!("{}", s);
}

// build.rs
extern crate gettext_utils;

fn main() {
    gettext_utils::compile_i18n("domain", &["en", "fr", "de"]);
}

Because build script are called before the actual compilation starts, the first time compile_i18n is called, it would only do what init_i18n! does:

• create the file with the domain and the list of languages
• create empty .pot/.mo files for the new languages (though don't know which one it should create? cf. #4, include_i18n! reads from the .mo, but init_i18n! creates a .pot)
• create the needed po/$DOMAIN/$LANGUAGES.po files with msginit
• issue a warning to tell the user to run cargo build again

Then during the first compilation, i18n! macros would populate the .pot file, and include_i18n! would silently include the contents of the (empty) .mo file (instead of crashing).

During the next build, compile_i18n would do what's listed above, then call msgmerge with the populated .pot files, and msgfmt to create the .mo file. This would allow include_i18n! to include the new translations directly, instead of having to call cargo build twice

I encountered this when building Plume:

$ cargo web deploy -p plume-front
[...]
   Compiling plume-front v0.1.0 (MASKED/plume-front)
error: proc macro panicked
  --> plume-front/src/main.rs:18:1
   |
18 | compile_i18n!();
   | ^^^^^^^^^^^^^^^^
   |
   = help: message: Couldn't update PO file: Os { code: 2, kind: NotFound, message: "No such file or directory" }
error: aborting due to previous error
error: Could not compile `plume-front`.

The "No such file or directory" is referring to msgmerge. It would be helpful to include the missing path as part of the error message, or even explicitly warn about gettext unavailability.

Instead of our custom crate