It would be nice to have a GMarkup subparser designed for dealing with simple text sub-strings.

The pattern that I find myself using is always the same:

 - create a GString in start_element(), making note of the value of
   optional "translatable" and "context" attribute on the opening tag

 - append to the string in text()

 - in end_element() do various things to translate the string

 - in text(), if we get any non-whitespace characters and the string is not set
   in the parser state, give an error


We could make a really nice subparser for dealing with this:


void    g_markup_string_parser_start    (GMarkupParseContext *context,
                                         gboolean             translatable,
                                         const gchar         *gettext_domain,
                                         const gchar         *context);

gchar * g_markup_string_parser_end      (GMarkupParseContext *context);

void    g_markup_parser_reject_text     (GMarkupParseContext *context,
                                         const gchar         *text,
                                         gsize                text_len,
                                         gpointer             user_data,
                                         GError             **error);



The idea is that you would give 'g_markup_parser_reject_text' as the 'text' vfunc in your GMarkupParser struct.  It would reject any non-whitespace text it encountered in the document (while not subparsing).

Then the subparser would work by taking the translatable/gettext-domain/context strings from the context of the opening tag and collecting text, while rejecting nested tags.

At the end, you get your already-translated string out of g_markup_string_parser_end().


Would be worth considering applying the GSettings schema whitespace handling rules here.  I believe them to be quite sane for general-purpose use (in short: remove leading and trailing whitespace, collapsing all other whitespace except for double-newlines which are preserved as paragraph breaks).  intltool knows about these conventions and it produces the normalised strings for the .po files...