There are a couple of options, here: 1. add some custom target rule that does a pass of xgettext on the Blueprint files, using the `--language` command line argument to tell it to use the same rules as C files 2. use some script to extract the translatable strings into a C source file that does not get compiled, but is used by xgettext to extract the strings 3. commit the generated XML files, and let xgettext use those instead of the Blueprint files; this also avoids requiring the blueprint compiler when building your project from release tarballs 4. change the Blueprint syntax not to look like Vala or C, and instead use some custom marker; then blueprint can ship an ITS and LOC file pair to let xgettext know how to extract the files
To be quite honest, I'd recommend the last approach; the C syntax is obscure and weird. Ciao, Emmanuele. On Sun, 5 Dec 2021 at 15:13, Zander Brown <[email protected]> wrote: > On Sun, 2021-12-05 at 12:07 +0100, Piotr Drąg via gnome-i18n wrote: > > What are these, why are they needed, what can we do to fix or > > at least work around the problem? > > It's the new ‘Blueprint’ language, not played with it myself but I *think* > treating it as C will work for string extraction > > See: > > https://www.jwestman.net/2021/12/02/introducing-blueprint-a-new-way-to-craft-user-interfaces.html > > Zander > _______________________________________________ > gnome-i18n mailing list > [email protected] > https://mail.gnome.org/mailman/listinfo/gnome-i18n > -- https://www.bassi.io [@] ebassi [@gmail.com]
_______________________________________________ gnome-i18n mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gnome-i18n
