On Tue, Sep 09, 2025 at 04:27:04PM +0200, Martin Quinson wrote: Perfect, thanks! I do not know what will last longer, but for GNU Texinfo, I can tell that we sometime dig up some old (> 20 years) mailing lists discussions for useful information, for instance to understand some design choices... The commit message I had envisionned is: New parser for Texinfo * lib/Locale/Po4a/TexinfoParser.pm: parser based on the GNU Texinfo libraries SWIG interface, with tests. The SWIG interface is only available in the development sources in the version control system but should be released as part of the next GNU Texinfo release. Associated name is texinfoparser. Regarding the new Texinfo parser situation, the main issue is obviously that it depends on unreleased code. The GNU Texinfo next release is probably not so far away, we only have one pending feature to implement, and then some cleanups, working on CI and some issues to fix, maybe documentation, and pretesting. Then there would be a need to wait for the next release to be packaged and become common. Because of this, it could make sense to keep the other Texinfo parser implementation for a while. Regarding the code, it seems to me that the two main things that remain to do are some better integration with build system, and passing options. The main options to pass are no-warn, which (for some reason I do not understand) I had to comment out in order to have the tests running, otherwise the message ends up on stderr, even though there is the option in t/fmt-texinfoparser.t. And a way to specify include directories. I would appreciate some help on the no-warn issue, and for specifying the include directories some advice on how to pass that information in a way that is consistent with other parsers. The testsuite coverage should be pretty good, I tried to test all the situations and @-commands that could interact with translations (except for @include and @verbatiminclude that remain to be done). There is something that should be done for @documentlanguage, but I couldn't find a way to test a real language in the testsuite, so I left that for later. There may be something specific to do with comments with TRANSLATIONS in them, so far they are treated as normal comments, but there is something in the other Texinfo implementation in POD and in tests about that. Please tell me if there is something to do for that. In the beginning I wanted to wrap paragraphs in translations, but end of lines and beginning of lines may be significant, so currently no situation with wrapping. Example of paragraph with beginning and end of lines significant that would be messed up by wrapping (commandsinpara test): A paragraph begins, and @comment in pcomm it continues between @comment a comment in line @cindex i entry commands. Also, currently, but you may tell me if it could be improved, if a parent Texinfo tree element is translated, all the children of this element will be translated as part of this element and not separately. For example, if there is a separate @cindex i entry the string "i entry" will be translated. But if the @cindex is part of a paragraph, as in the example above, it will be translated as part of the whole paragraph, with the @cindex @-command visible. When the @-command is at toplevel, in some case the translated string includes an @-command, in some case it is the @-command argument that is translated, some choices I made could be discussed. But I do not think that it is so important, and could be changed afterwards. I set the License to GPLv2+ to be consistent with the remainder of the po4a code. I would have preferred to have GPLv3+ for consistency with Texinfo, but it is up to you. -- Pat