Re: Use "simple parsers" for translations again?

[Gavin Smith]

On Sat, Nov 25, 2023 at 09:35:28AM +0100, Patrice Dumas wrote:
> On Fri, Nov 24, 2023 at 11:24:55PM +0000, Gavin Smith wrote:
> > As I understand it, it is not any part of the state that is problematic
> > to modify for simple_parser.  It is only the structures that are referred
> > to when creating the simple parser:
> 
> I think so too.
> 
> > Many of these relate to the creation of new Texinfo commands, or indices.
> > These structures should be the same for all of the parser objects used
> > for translations so copying them (with dclone) for every single translated
> > string is a waste of time.
> 
> I am not sure about that.  The underlying question is what limit we set
> on the users defined translations.  This is very unclear to me, we could
> imagine large/complex Texinfo code to be used in user defined
> translations if they have, for example, repetitive parts that they want
> to generate ahd have them different for different languages.

Should the result of customized translations be able to create index
entries?  That is what broke the "translation_in_parser_in_translation"
test with the "simple parser" patch: the customized translation entered
an index entry (with @deftypeop), which persisted into following translations. 

This then led to an infinite loop in complete_indices, as this itself
created a new parser to translate "{name} on {class}", but this new parser
referenced the same index entries which also needed translating, and so on.

On the previous patch I posted, all that is needed is the following change:

-  $parser->{'index_names'} = $simple_parser_index_names;
+  $parser->{'index_names'} = dclone(\%index_names);

- then the test suite passes.  It is still not ideal, but still worthwhile,
as execution time is still saved on the other dclone calls.

(Even without the "simple parsers", it seems that a customization of the
translations could generate such an infinite loop by making the output of
"{name} on {class}" itself create an index entry that then needed
"{name} on {class}" to be translated.  If the translation of this string
actually worked in t/init/translation_in_parser_in_translation.pm then
that would lead to an infinte loop too.)

The example in t/init/translation_in_parser_in_translation.pm is contrived
as it would make no sense to translate the string "Next" as something using
@deftypeop or @deftypemethod.

Can we simply forbid, or disable, creating index entries in parsers for
translations?  (I doubt it makes a difference as I expect that such index
entries are not actually used.)

> I think that we should not put important restrictions on translated
> strings, maybe we could forbid using @node and sectioning commands, but
> it is not clear to me that there couldn't be use cases for those.

It seems to me that it's likely that people run texi2any with XS modules
disabled (although I have no information on how prevalent this is), but
use of customization files is much rarer, and use of customization files
that customize translating strings to give bizarre translations involving
index entries (or sectioning commands...) is not done and is not likely
to be done.  We should prioritize the existing use cases rather than
rare or hypothetical use cases.