Re: Is translating server messages really worth it?

Hey everbody!

>Hi,
>
>I know that $SUBJECT is a bit curious from someone who's been
>translating PostgreSQL server messages for quite some time now (I
>checked, I've been doing it for 20 years...). But still, I'm wondering.
>
>Most of the time when I'm at a customer's office trying to help them
>with their PostgreSQL cluster, I tell them to set lc_messages to C, so
>that server messages are in english. It's kind of weird or funny to do
>the translation, and tell people not to use it. But, yeah, I don't know
>if it's a good thing or not, but when someone tries to search if
>someone else already met some weird server messages, this someone has
>more chances to get a hit with an english message than with a french
>message (though I guess it's the same for other non-english languages).
>If you have to use a tool such as pgbadger, this kind of tool only
>knows English messages.
>
>So, yeah, I'm kinda wondering if it makes sense to translate server
>messages. For client tools, such as psql or pg_dump or vacuumdb, it
>definitely makes sense. But the server logs? I pretty much don't know.
>It's a lot of work, with some nearly-impossible-to-translate messages.

Thanks for a great question! I answer it whenever I give an i18n talk or
describe the i18n process.

We are all biased as consultants. We know how to solve problems
efficiently. We know where to search for solutions (usually the source
code). That's why we set C-style messages, run our standard procedures,
follow our methods, apply our own monitoring, etc. That's just a part of
our professional workflow, but it doesn't mean people shouldn't use
localized messages.

Maintaining a glossary
Want it or not, many areas use localized terms and words in everyday
life, e.g., education, medicine, military, etc. We might lose a lot if
we translate only the user interface part, omitting server messages.

Satisfying requirements
It sounds bureaucratic; nevertheless, we need a fully translated product
to pass some government, military, and education requirements. I've met
a situation when a product lost tender only because it wasn't localized.
And I don't need to remind which products are always localized and in
good shape: mssql, oracle, etc.

Feedback
You said already that some messages are nearly impossible to translate.
However, that mainly indicates the low quality of a source message, not
the absence of linguistic tools to express that message. Giving feedback
to developers increases source code quality.

Error codes
If only every single error message had a non-localized error code, we
wouldn't have this question at all. You agree that searching for "E0042"
is much easier than copy-pasting part of an error message. Even more,
having an error code gives you the freedom to change, adapt, and improve
error messages. It's not a rare story when messages are pretty different
between major server versions. We have SQLSTATE error codes, but AFAIR,
they're not mandatory for logging and only apply to SQL errors.

>
>
>Anyway, I was wondering how you feel about this.
>
>And I have another question, quite a bit related :) If a file (let's
>say psql-fr.po) is not translated at 80%, it's not distributed. But I
>was wondering if it was only this file (psql-fr.po) or all the files
>for this language? I'm considering leaving the postgres-fr.po file
>without any translation, but keep the other files up to date.
>
>Thank you for your comments.
>
>Regards.
>
>
>--
>Guillaume.