Re: [bug-gettext] picking strings to translate from a program's output

[Egmont Koblinger]

Hi Bruno,

> > B. Care has to be taken that input sanitization (e.g. removal of
> > escape sequneces) happens before applying the hyperlink. E.g. a
> > pseudo-code like
> >
> >     printf(_("Cannot remove file %s\n"), filename);
> >
> > might mess up the terminal if filename contains escape sequences.
>
> This case can be ignored. File names with escape sequences don't occur
> _that_ frequently. Therefore they only need to be considered when
> thinking about security and malicious attackers. But here, only
> translators will set the environment variable(s) that activate the
> hyperlinks.

I really don't think this case can be ignored. I missed to emphasize the point.

The developer of a well-written code takes care of sanitizing
untrusted source, whether it's a filename printed by "ls", or a song
title printed by "mpg123" (see pending bug
https://sourceforge.net/p/mpg123/bugs/267/ ), or anything similar.
This has nothing to do with translating per se, and indeed a
translator is unlikely to come across a use case where it matters. But
because other regular (non-translator) users might come across such
cases, or an attacker might exploit the lack of such sanitization, we
can assume that the code sanitizes untrusted input.

And if the code does it along the lines of

    printf(sanitize(_("Cannot remove file %s\n"), filename));

then the hyperlink trick will fail. So the developer needs to do it
along the lines of

    printf(_("Cannot remove file %s\n"), sanitize(filename));

which already means that they might have to modify their current code
in order to please the requirements of a new translation
infrastructure. That is, the hyperlink trick for translating isn't
transparent.

And this latter design pattern becomes more problematic if the code is
generic enough so that at the time of the construction of the message
it's not yet known where it will be sent to. E.g. if you have these
two methods split out:

    string construct_remove_error_message (string filename) {
        return _("Cannot remove file %s", filename);
    }

    deliver_message (string message) {
        if (blah)
            printf("%s\n", message);
        elif (baz)
            send_to_log(message);
        elif (html)
            add_to_dom(message);
        ...
    }

then I can't see where/how to add sanitization and in the mean time
keep the hyperlink trick working.

I'm not sure how typical such a code structure is, though. You might
want to argue that this is also a negligible fraction of the cases
which will be fixed in the linear translating phase.

> Yes, but this is a large class of programs. Whereas there are fewer
> programs that use ncurses. [...]
>
> bash, binutils, bison, clisp, coreutils, cpio, diffutils, findutils, [...]

Okay, so nothing new I didn't think of :)

I believe that for ncurses or similar interactive apps it's more
important to see the messages in their exact context, whereas for
coreutils and friends I would guess that doing a linear translation
does a pretty good job – is it not the case?

> Many maintainers of terminal emulators will reject the idea to implement
> an ad-hoc hack. The cool thing about the protocol is that it's applicable
> to many more use-cases.

I find it a much more viable approach to give translators one
specially crafted terminal emulator that fully transparently allows
them to use the software and translate its strings; rather than an
approach that's not transparent from the app, the author of the code
might need to perform modifications for the strings to be translatable
using this method, and has many other limitations (e.g. the ncurses
one).

That being said, I'm not a regular translator, so I have no real idea
what they are looking for.

> But we'll see. Without trying it, we'll never know.

Just wondering, are you (or someone else here) actually planning to
implement it to give it a try? Would indeed be nice to have real life
feedback. Or is it just the idea that you shared with us, at least for
the time being?


thanks a lot,
egmont