Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qlEVZ-001r42-9G for pgsql-translators@arkaria.postgresql.org; Tue, 26 Sep 2023 20:18:13 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1qlEVX-00Elcf-Tv for pgsql-translators@arkaria.postgresql.org; Tue, 26 Sep 2023 20:18:11 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qlEVX-00ElcK-GM for pgsql-translators@lists.postgresql.org; Tue, 26 Sep 2023 20:18:11 +0000 Received: from mail-yb1-xb30.google.com ([2607:f8b0:4864:20::b30]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1qlEVU-007kZn-0a for pgsql-translators@lists.postgresql.org; Tue, 26 Sep 2023 20:18:10 +0000 Received: by mail-yb1-xb30.google.com with SMTP id 3f1490d57ef6-d776e1f181bso11159298276.3 for ; Tue, 26 Sep 2023 13:18:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lelarge-info.20230601.gappssmtp.com; s=20230601; t=1695759485; x=1696364285; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=pnSfy7MNPqDZhSIDmL5XtnTIjwuM3GxKRTfcRUo2Qgc=; b=Sn9EAHeqib45q9xkKeAmF9Jk/OlYjZ4akFczPCyu1Ypq+Tp6kwttUQr071jAIXHULT PtpavdtzauyDnV2fnZcVGzeZ+/Keg7m6l4QveVuZ0l3tjmUXTEkTrWDKobqmDUiQ2byS alTJMFW67NV79Ndr1nDwwiSNWJo8dIP9rRlFY4Ohff1XIVTMLD/OZSQCw0IVOkoD0VxR cU82gAvhnlj8YDZpvQvs+1GJF3FJNLoPBHG4N2FJ4bJO6LpbTtLKKm2TfE4J6aGZcDdO /g1gkUKeBsBXWZrlNby10p4DPDEQah043VSYWChrBZ26joycLu26jRfo/xQ+fRSJGA+x 6gZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695759485; x=1696364285; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=pnSfy7MNPqDZhSIDmL5XtnTIjwuM3GxKRTfcRUo2Qgc=; b=grzU0q38qtxI5xNhalQ/HMROWqQdlVWmuWF7bb+V3bN62BGEz/d/Gw/gmdRa3K3Vhi xovvsNO6hV7dvb0TINc41jcLlB3GMC5bMmoo/+GYsUqVgg831F21B8zX19Pfi5qK+sFI GoJ0nD5bq+/29RM7BD+YZc+ymqUPLojemMzyUJEPXDgz7b5kq2JP6vzTIwjwhMulbcVW S9+u6AgR521grWsjXWQbfmmDOfQHt7B2G8t2opK7BN6jhnCdMJdQHoIQE5HZPzq+ePev u3xeGKeBBjZd9gFzLnRhda2JodtZxGuqaESwAn2wQUa2FrdKH0y/VKf/exjgo65bOouA Geeg== X-Gm-Message-State: AOJu0YxmdgR/pEkelNc7ye01zkFxjl4+hhPCp1c03LVqWqz0B+EzwFTp 08/WaxdNQWxsD2MUlgvXSYT26sWrKKE/Hy1PdBHFxg== X-Google-Smtp-Source: AGHT+IFCk2fPLRI/dRudHxjquAErvgzZt8nmbQHLKMUlE6X0Th931OaTQ8gvdwjTzKKBN1c24WNVR3VaQcj1ORXm8X0= X-Received: by 2002:a5b:4c:0:b0:d7b:9bd7:f280 with SMTP id e12-20020a5b004c000000b00d7b9bd7f280mr15754ybp.0.1695759485496; Tue, 26 Sep 2023 13:18:05 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Guillaume Lelarge Date: Tue, 26 Sep 2023 22:17:54 +0200 Message-ID: Subject: Re: Is translating server messages really worth it? To: Pavlo Golub Cc: pgsql-translators@lists.postgresql.org Content-Type: multipart/alternative; boundary="000000000000c20971060648c5e9" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000c20971060648c5e9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Le mar. 26 sept. 2023 =C3=A0 11:28, Pavlo Golub a = =C3=A9crit : > 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. An= d > 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 t= he > 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 betwee= n > major server versions. We have SQLSTATE error codes, but AFAIR, they're n= ot > 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. > > --=20 Guillaume. --000000000000c20971060648c5e9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Le=C2=A0mar. 26 sept. 2023 =C3=A0=C2=A011:28,= Pavlo Golub <pavlo.golub@gmail= .com> a =C3=A9crit=C2=A0:
Hey everb= ody!

Hi,

I know that $SUBJECT is = a bit curious from someone who's been translating PostgreSQL server mes= sages for quite some time now (I checked, I've been doing it for 20 yea= rs...). 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 me= ssages are in english. It's kind of weird or funny to do the translatio= n, 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 alread= y met some weird server messages, this someone has more chances to get a hi= t 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 suc= h as pgbadger, this kind of tool only knows English messages.
So, yeah, I'm kinda wondering if it makes sense to translat= e server messages. For client tools, such as psql or pg_dump or vacuumdb, i= t 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 i18= n talk or describe the i18n process.

We are all biased as consultants. We know how to solve problems efficie= ntly. 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 prof= essional workflow, but it doesn't mean people shouldn't use localiz= ed messages.

Maintaining a glossa= ry
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 transl= ated product to pass some government, military, and education requirements.= I've met a situation when a product lost tender only because it wasn&#= 39;t localized. And I don't need to remind which products are always lo= calized 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. B= ut French translation of server logs, I don't think so.
=C2= =A0
Feedback=
You said already t= hat some messages are nearly impossible to translate. However, that mainly = indicates the low quality of a source message, not the absence of linguisti= c tools to express that message. Giving feedback to developers increases so= urce code quality.
=

Definitely true. To = be honest, I don't do this for the .po files, but I frequently report t= ypos or parts I don't understand in the manual.
=C2=A0
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 give= s you the freedom to change, adapt, and improve error messages. It's no= t a rare story when messages are pretty different between major server vers= ions. We have SQLSTATE error codes, but AFAIR, they're not mandatory fo= r logging and only apply to SQL errors.


Totally agree, though I don't think it will happen at all. It would al= so help a lot coding tool such as pgBadger.

Thanks= for your comments.




Anyway, I was wondering how you feel about this.

<= /div>
And I have another question, quite a bit related :) If a file (le= t'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 wit= hout any translation, but keep the other files up to date.

Thank you for your comments.

Regards.


-- =
Guillaume.


--
<= div dir=3D"ltr">
Guillaume.
=
--000000000000c20971060648c5e9--