Re: Internationalized error messages

Tom Lane writes:

> I guess I don't understand what you have in mind, because this seems
> self-contradictory. If "client programs can look at the code only",
> then how can the error message text be chosen independently of the code?

Let's say "type mismatch error", code 2200G acc. to SQL. At one place in
the source you write

elog(ERROR, "2200G", "type mismatch in CASE expression (%s vs %s)", ...);

Elsewhere you'd write

elog(ERROR, "2200G", "type mismatch in argument %d of function %s,
expected %s, got %s", ...);

Humans can look at this and have a fairly good idea what they'd need to
fix. However, a client program currently only has the option of failing
or not failing. In this example case it would probably better for it to
fail, but someone else already put forth the example of constraint
violation. In this case the program might want to do something else.

> >> Surely we do not expect gettext to start with 'Attribute "foo" not
> >> found' and distinguish fixed from variable parts of that string?
>
> > Sure we do.
>
> How does that work exactly? You're assuming an extremely intelligent
> localization mechanism, I guess, which I was not. I think it makes more
> sense to work a little harder in the backend to avoid requiring AI
> software in every frontend.

Gettext takes care of this. In the source you'd write

elog(ERROR, "2200G", gettext("type mismatch in CASE expression (%s vs %s)"),
string, string);

When you run the xgettext utility program it scans the source for cases of
gettext(...) and creates message catalogs for the translators. When it
finds printf arguments it automatically includes marks in the message,
such as

"type mismatch in CASE expression (%1$s vs %2$s)"

which the translator better keep in his version. This also handles the
case where the arguments might have to appear in a different order in a
different language.

> Sorry, I meant that as an example of the "secondary message string", but
> it's a pretty lame example...

I guess I'm not sold on the concept of primary and secondary message
strings. If the primary message isn't good enough you better fix that.

--
Peter Eisentraut peter_e(at)gmx(dot)net http://yi.org/peter-e/