Mailing List Archive

Daniel Resare <noa@melody.se>:

> When translating the gnupg messages to swedish i noticed the following
> entry
>
> #. a string with valid answers
> #: g10/pkclist.c:197
> msgid "sSmMqQ"
>
> and i wondered if it was ok to translate this message, or if the
> english standard behaviour of the program would break if i did.
> Checking the source I came to the conclution that my worries were
> relevant, if the string sSmMqQ is translated to another language
> not only the translation of the program changes but also the behaviour,
> which is not desired. So i wrote the following patch to solve the
> problem.

I'm not sure this is the right way to do it. Hard-wired things are to
be avoided, I think ...

An alternative would be to change the notation: use a string like
"sS,mM,qQ", which a translater could translate as "xX,yY,zZ", if they
don't want the English keys to be accepted, or as "xXsS,yYmM,zZqq", if
they do. Either way, the translator can see the consequences of their
decision, whereas your patch might have nasty circumstances if someone
were translating into a language in which the word for "quit" starts
with 's' ... particularly if the word for "show" happens to start with
'q'!

I sent a patch to the list last night in which I suggest a similar
solution for the commands in keyedit.c.

But I suppose we really ought to be thinking about wide characters and
charset support, too; a Russian user might be using koi8-r or utf-8.
The same problem effects lots of programs, not just gnupg ...

Edmund

Sorry to reply to myself like this ...

> But I suppose we really ought to be thinking about wide characters and
> charset support, too; a Russian user might be using koi8-r or utf-8.
> The same problem effects lots of programs, not just gnupg ...

I've heard that soon gettext will automatically convert message
strings to the charset of the user's current locale. A single
non-ASCII character will become several octets when converted into
UTF-8 (which will be the most widely used charset soon). So any code
that wants to look at the third character of a translated string by
just doing ans[2], say, will break horribly.

Perhaps it would be useful to use a function that searches for an
exact match or an unambiguous prefix in a set of commands. For
example:

int f(char *cmd, char *cmds, int *x);

f("a", "a,cw;bx,by;cz", &x) = 0, x = 1 /* exact match in group 1 */
f("b", "a,cw;bx,by;cz", &x) = 1, x = 2 /* unambiguous prefix in group 2 */
f("c", "a,cw;bx,by;cz", &x) = 2, x = ? /* ambiguous prefix (1 or 3) */
f("d", "a,cw;bx,by;cz", &x) = 3, x = ? /* no match */

The cmds string would be translated, of course, and it shouldn't
matter if charset conversion changes the number of bytes. If a system
like this were in general use in GNU software, translators would soon
learn.

The question of whether to use the English commands as a canonical
alternative is left to individual translator teams.

Edmund

On tor, jan 27, 2000 at 04:29:25 +0000, Edmund GRIMLEY EVANS wrote:
> Daniel Resare <noa@melody.se>:
>
> > When translating the gnupg messages to swedish i noticed the following
> > entry
> >
> > #. a string with valid answers
> > #: g10/pkclist.c:197
> > msgid "sSmMqQ"
> >
> > and i wondered if it was ok to translate this message, or if the
> > english standard behaviour of the program would break if i did.
> > Checking the source I came to the conclution that my worries were
> > relevant, if the string sSmMqQ is translated to another language
> > not only the translation of the program changes but also the behaviour,
> > which is not desired. So i wrote the following patch to solve the
> > problem.
>
> I'm not sure this is the right way to do it. Hard-wired things are to
> be avoided, I think ...

I agree my solution is not the ideal one, but sometimes Worse Is Better[1]
The hardcoded solution i've implemented is modeled from the yesno functions in
util/miscutil.c and I think they are an improvment over the current situation
where only the user supplied input is checked against the translated string
only which leads to a situation where gnupg changes behaviour (not just language
output) depending on the current locale.

>
> An alternative would be to change the notation: use a string like
> "sS,mM,qQ", which a translater could translate as "xX,yY,zZ", if they
> don't want the English keys to be accepted, or as "xXsS,yYmM,zZqq", if
> they do. Either way, the translator can see the consequences of their
> decision, whereas your patch might have nasty circumstances if someone
> were translating into a language in which the word for "quit" starts
> with 's' ... particularly if the word for "show" happens to start with
> 'q'!

Perhaps the program should check for inconsistencies in the translation
and warn the user telling him to contact the translators for his language
to solve this situation.

>
> I sent a patch to the list last night in which I suggest a similar
> solution for the commands in keyedit.c.

i missed that one, to which list wasit?

>
> But I suppose we really ought to be thinking about wide characters and
> charset support, too; a Russian user might be using koi8-r or utf-8.
> The same problem effects lots of programs, not just gnupg ...
>

If anyone has a bunch of free time a set of functions handling user input
with respect to case conversion in different charsets, unicode and so on
would be really nice.

/daniel

--
Daniel Resare @ Melody Interactive Solutions
address: Bredgränd 4, Box 2163, SE-103 14 Stockholm
phone: +46 8 454 96 15 cellphone: +46 707 333 914

Daniel Resare <noa@melody.se>:

> > An alternative would be to change the notation: use a string like
> > "sS,mM,qQ", which a translater could translate as "xX,yY,zZ", if they
> > don't want the English keys to be accepted, or as "xXsS,yYmM,zZqq", if
> > they do. Either way, the translator can see the consequences of their
> > decision, whereas your patch might have nasty circumstances if someone
> > were translating into a language in which the word for "quit" starts
> > with 's' ... particularly if the word for "show" happens to start with
> > 'q'!
>
> Perhaps the program should check for inconsistencies in the translation
> and warn the user telling him to contact the translators for his language
> to solve this situation.

If not the program, perhaps the build process or "make test" phase.

> > I sent a patch to the list last night in which I suggest a similar
> > solution for the commands in keyedit.c.
>
> i missed that one, to which list wasit?

This one. Obviously it didn't get through. I'll repost it ...

> > I've heard that soon gettext will automatically convert message
> > strings to the charset of the user's current locale. A single
> > non-ASCII character will become several octets when converted into
> > UTF-8 (which will be the most widely used charset soon). So any code
> > that wants to look at the third character of a translated string by
> > just doing ans[2], say, will break horribly.
>
> When that day comes lots of things will break horribly in gnupg. Perhaps
> someone with knowledge of the UNICODE system could review the code
> and write an intelligent replacement to all the character comparison
> cases.

It might not be too hard. UTF-8 is US-ASCII-compatible, provided you
don't make assumptions about the length of a string or its width when
printed. And you should avoid using "char" as a character.

Stuff like printf("%-10s %-10s", x, y) won't make nice screen columns
in UTF-8, so you need a function for that. That's the sort of thing I
had to change to make mutt work in UFT-8 (www.rano.org/mutt.html). Of
course mutt displays gnupg's output when it verifies a signature, etc,
so I really ought to patch gnupg just to finish the job properly ...

Edmund

On Thu, 27 Jan 2000, Daniel Resare wrote:

> + /* translation is ok, since the english version is hardwired */
> + /* and will always work */
> const char *ans = _("sSmMqQ");
> + #define EN_ANS "sSmMqQ"

I think the patch is small enough to be applied. But I don't think
this is a good solution. User interface design is something I try to
avaoid for many years now.

--
Werner Koch at guug.de www.gnupg.org keyid 621CC013

On Thu, 27 Jan 2000, Edmund GRIMLEY EVANS wrote:

> I'm not sure this is the right way to do it. Hard-wired things are to
> be avoided, I think ...

I know it is not a perfect solution but it is also done for yes/no

> "sS,mM,qQ", which a translater could translate as "xX,yY,zZ", if they
> don't want the English keys to be accepted, or as "xXsS,yYmM,zZqq", if

Not in this version. Maybe we can rework the user interface in the
future

> But I suppose we really ought to be thinking about wide characters and
> charset support, too; a Russian user might be using koi8-r or utf-8.

At the Tokyo BOF we talked about such things and the common sense was
not to do it in a program but leave it to the library. The Japanese
folks have some experience with character sets ;)

--
Werner Koch at guug.de www.gnupg.org keyid 621CC013

On Fri, 28 Jan 2000, Edmund GRIMLEY EVANS wrote:

> Stuff like printf("%-10s %-10s", x, y) won't make nice screen columns
> in UTF-8, so you need a function for that. That's the sort of thing I
> had to change to make mutt work in UFT-8 (www.rano.org/mutt.html). Of
> course mutt displays gnupg's output when it verifies a signature, etc,
> so I really ought to patch gnupg just to finish the job properly ...

There are some option (--utf8-strings?) which should help at least on
the input side.

--
Werner Koch at guug.de www.gnupg.org keyid 621CC013