Re: Texinfo::Report::gdt

[Gavin Smith]

>     * 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.

Coming back to this, I've got an attempt at getting this to work. The
attached patch shows some of what I've been trying.

To summarize, Texinfo trees, which had been created at the parser
stage, are now being passed as @value's by the output converters to
the parser in order to get a translated string for output into the
document. The C parser can't get Texinfo trees from the Perl code as
@value's; it can only get strings.

I've been trying to convert the trees into strings first, but there
are complications of course. For example, if we are outputting to
HTML, and when we convert a value we get an HTML tag in the output
like "<p>", if we then interpret this as Texinfo source it will be
transformed for HTML output to "&lt;p&gt;". One idea is to use
@inlineraw, which should work in theory (although when I tested it the
output of it was blank). Another problem is how to convert these trees
into strings without getting unwanted formatting, like an initial
paragraph indent. Another problem is formatting: will we get proper
line wrapping if we have long strings as values to be substituted in
the translation strings?

Another idea is to have a 'rawvalues' array which is recognized as
being in the output format already, not Texinfo, which would be easy
to implement in both C and Perl - there'd still be the possible
problem with formatting though.

Another idea which I had while writing this email, which I haven't
explored yet, is for the parser to be able to return in the tree it
creates elements that are "free variables", which could be substituted
in afterwards. This could be done for undefined @value's; or maybe
another command could be invented for this purpose. Actually, looking
at the code in Parser.pm I think undefined @value's stay in the tree
already, so this could work well.

>> 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.

In the libc manual it says that gettext can convert between character encodings:

`gettext' not only looks up a translation in a message catalog.  It
also converts the translation on the fly to the desired output character
set.  This is useful if the user is working in a different character set
than the translator who created the message catalog, because it avoids
distributing variants of message catalogs which differ only in the
character set.

(Info node "(libc)Charset Conversion in gettext".)

Texinfo-Report-gdt.patch
Description: Text Data