Re: Is translating server messages really worth it?

Hi,

Le mar. 26 sept. 2023 à 11:28, Pavlo Golub <pavlo(dot)golub(at)gmail(dot)com> a écrit :

> 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.
>
>
I don't believe we have this issue in France. At the very least, I've never
heard about this in France. Having a french manual, yes. But French
translation of server logs, I don't think so.

> 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.
>
>
Definitely true. To be honest, I don't do this for the .po files, but I
frequently report typos or parts I don't understand in the manual.

> 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.
>
>
Totally agree, though I don't think it will happen at all. It would also
help a lot coding tool such as pgBadger.

Thanks for your comments.

>
>
> 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.
>
>

--
Guillaume.