Re: Texinfo::Structuring::gdt

[Karl Berry]

    Using texinfo commands in document strings appeared as an
    interesting feature to me,

I thought so too.

Although, looking at the texinfo_document/*.po files, I see both that
some *.us-ascii.po have non-ascii characters and that some *.po files
have only ascii.  Indicating that there is confusion in both directions
among the translators.  Not too surprisingly, since (afaik) there is no
way they can check their .po in this regard.  Maybe we should provide
something.

    * translators need to understand Texinfo at least to some extent

That seems like a feature to me, not a bug.

    * error reporting within the gdt strings is not easy as it doesn't
      flow naturally in the document.

But should affect only the translators, and they should be able to deal.
And, if we provided some kind of validator for translators as above, it
could help them.


Regarding the TODO item:

> * Convert the values with $self->_convert to strings, then give the 
> values as strings, followed by parsing as Texinfo.  

I don't think I follow, but at least it seems to preserve the basic
idea.  Clearly message translations are a tiny subset of full Texinfo
(essentialy, in-paragraph text), so if we can take advantage of that,
that is good.

> it could be
> msgid "{category} on {class}: <strong>{name}</strong>"

I don't understand how this can work.  Translators cannot provide
per-output-format translations, nor would we want to impose that work on
them even if they could.  That's what Texinfo is for :).

> Some of the translation strings use Texinfo commands for characters, 
> e.g. "@'e".  This would have to be replaced with whatever method other 
> programs using gettext use for special characters.

I don't know of any such alternative method for special characters.
All I have ever seen in .po files is literal UTF-8 or Latin 1 or ...
In fact, using Texinfo commands is the most elegant and
encoding-agnostic solution I have seen.

FWIW ...
Karl