[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Egmont Koblinger
Subject: Re: [bug-gettext] picking strings to translate from a program's output
Date: Thu, 2 May 2019 12:54:33 +0200


Thinking further along the lines of your idea and my response...

I mentioned that the terminal emulator could be tweaked to do
something slightly different on OSC 8 sequence (push/pop). Thinking
along these lines: If purely for translating, there doesn't have to be
a specification, a "semi-official" extension to the protocol such as
the hyperlink one. It could be just a random ad-hoc hack to one of the
terminal emulators, and translators asked to use that as part of their

So let's abandon the explicit hyperlink approach, and let's assume
that a small custom patch (some new functionality) for one of the
terminal emulators is okay to go with.

The simplest, least intrusive approach I can think of now: Let gettext
prefix each and every message with a separate character that's not
used elsewhere; probably from the Unicode private use area. The first
message in the .po file would be prefixed with a U+E000, the second
with U+E001 and so on.

There are plenty of ways to implement it: override gettext(), or add a
special option to msgfmt so that it adds these into the .mo files, or
just an ad-hoc shell script reading a .po file and writing out another
which contains these additional characters.

The terminal would be modified to show some special hardwired symbol
(maybe even in special colors, or doing special things on mouseover)
for these codepoints, and also to open a webpage at the given message
when clicked (ctrl+clicked, whatever). The webpage would be just like
with your hyperlink idea. (The webpage address would have to be
hardwired in the terminal, though. Or configurable via some new escape

For checking the character under the click location in gnome-terminal,
the abandoned/rejected
https://bugzilla.gnome.org/show_bug.cgi?id=757541 might be a good
starting point. I'm happy to come up with an up-to-date and
non-crashing patch if it would really be used.

Does this make sense? I believe this approach addresses all the five
points I had in my previous mail.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]