[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Support for Blueprint markup language
From: |
Bruno Haible |
Subject: |
Re: Support for Blueprint markup language |
Date: |
Mon, 09 Sep 2024 18:33:43 +0200 |
Hi,
James Westman wrote:
> I'm the maintainer of Blueprint, a markup language for GTK UI files:
> <https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/>
>
> Right now, blueprint files can be scanned with xgettext's C scanner,
> but with some limitations, most notably that Blueprint allows
> single-quoted strings but the C scanner does not.
>
> Translations in Blueprint are very simple. It doesn't support format
> strings (that has to be done in application code) nor does it support
> changing the translation keywords (they are always _ and C_).
>
> I've attached a patch that adds support.
Before we discuss the patch, I need to point to more fundamental things.
1) A new language in xgettext has some maintenance cost. Since I see that
your project exists for quite some time, is actively maintained,
packaged in Debian, [1][2][3][4][5] it's probably warranted to support
it in GNU gettext.
2) Before a language can be added, however, it needs to have a specification
that documents things that are important for xgettext. I don't see the
following documented in [1]:
- What is the standard file suffix for such files?
- What is the character encoding of such files?
- What is the syntax for comments?
(It may be in your patch, but I want it documented anyway.)
3) The note in [1] "Blueprint is still experimental. Future versions may
have breaking changes" is deterring me from having a hand-written
xgettext backend for this language, because I don't want to rewrite
this backend two or three times.
The way forward, to get along with less maintenance on the GNU gettext
side, is that you provide a tree-sitter [6] grammar (in source and
compiled form, e.g. like in [7]). This will be useful not only for
GNU gettext, but also for editing such files in GNU Emacs and neovim.
4) Next, we will need a documentation section for it.
Take [8] as an example and fill in the infos.
5) There is a checklist for new languages in [9]. Could you please give
details? In particular, I don't understand your statement
"It doesn't support format strings (that has to be done in
application code)"
Can you give an example of it, please?
6) Finally, for the unit test that you provided, we will need a copyright
assignment to the FSF. It doesn't need to be today, but I want to
state it, so that it doesn't come as a surprise later.
Bruno
[1] https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/
[2] https://gitlab.gnome.org/jwestman/blueprint-compiler
[3] https://packages.debian.org/trixie/blueprint-compiler
[4]
https://www.jwestman.net/2021/12/02/introducing-blueprint-a-new-way-to-craft-user-interfaces.html
[5]
https://medium.com/@codenomad/gnome-builder-using-python-libadwaita-and-blueprint-c9c3e138801e
[6] https://tree-sitter.github.io/tree-sitter/
[7] https://github.com/tree-sitter/tree-sitter-java/tree/master/src
[8] https://www.gnu.org/software/gettext/manual/html_node/gawk.html
[9]
https://www.gnu.org/software/gettext/manual/html_node/Language-Implementors.html