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 1ql4NL-000xbK-5z for pgsql-translators@arkaria.postgresql.org; Tue, 26 Sep 2023 09:29:03 +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 1ql4NJ-00B3NK-UT for pgsql-translators@arkaria.postgresql.org; Tue, 26 Sep 2023 09:29:01 +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 1ql4NJ-00B3N6-KE for pgsql-translators@lists.postgresql.org; Tue, 26 Sep 2023 09:29:01 +0000 Received: from mail-wr1-x436.google.com ([2a00:1450:4864:20::436]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1ql4NG-007ebe-7y for pgsql-translators@lists.postgresql.org; Tue, 26 Sep 2023 09:29:00 +0000 Received: by mail-wr1-x436.google.com with SMTP id ffacd0b85a97d-3231df054c4so4444407f8f.0 for ; Tue, 26 Sep 2023 02:28:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695720537; x=1696325337; darn=lists.postgresql.org; h=mime-version:user-agent:reply-to:references:in-reply-to:message-id :date:subject:to:from:from:to:cc:subject:date:message-id:reply-to; bh=rLR4r4GGUVWKeZXgrl5ZVamE1y/M/VUnfXqU+zDldPY=; b=GCCj/YhV1pnUBLwG8XHRRiwcVLbplSjToGreGAecf1n86DfFTYMGGweajgg5+v8dAn qc0Kyd0oWyVotDWrXrLyjqimRVtfGhGafdOUHUFX1xG+r6yoSqo9Xaacx19LNQfPnJCi aO8pOEx+R73D7vzqD9g3rH9nMcTHj9ctRy4pY/63y1hMKCSFU5dlHmEEHq6U71wepNz1 6atDkhKQq7D+lTkc+EX+eewskXuhVBg2VXxXjzwHMwF0EAHJCBokI1zMtZZq9hCn1i3h SJoltXS5XWhZN9Tc/16WdvsvNMNy8SVR2Z4PwvEO5P5mSeOuh/JhGKuaO9tC4wW2XPmg DngQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695720537; x=1696325337; h=mime-version:user-agent:reply-to:references:in-reply-to:message-id :date:subject:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=rLR4r4GGUVWKeZXgrl5ZVamE1y/M/VUnfXqU+zDldPY=; b=dFBnWI/sGqJNJ3n7zwqki/uBfKcvEGpx7/oEqE0TJBVIK36BL0qgDZBwhtmhIni9CY Dt28GQtOooABq4T4jQAxf7BMX0Hq4D0MRggBZ1DnPlA3ZOIeJrrRma7X/w6OegNUpbmn 8NyXmitnDo15vkKBhoSsS5eXvTwdr86jN835Wdtl/5GDXxkHEdIeXzwC6mrSyEAU9Cuj gVtvy5JnWoInmQh82NXqG+MBrA8r+AqS6HdeScCF4Glt5S5tWTJckNjO7MxShw19DeZP VVniw+ou2S3yRxfV91oquaNqyQqV2qbt01zdV6yzbnsAruZVkvVsxyjrm6/kmTHzRGHQ h6iA== X-Gm-Message-State: AOJu0Yxo0po4HTvy7A6emmh//88o3NP0Akq0161YMFsu7VJdsrys2NBG QkhuMHSgY7FCIoPus4vQ7Mg= X-Google-Smtp-Source: AGHT+IH94nnfoMJv7naiKwFht8FBpk2o0PD7EbpdbpJxnR7oGyWhO6aEbscykSwMi7IoNy8klQlP3g== X-Received: by 2002:a5d:4310:0:b0:315:a1d5:a3d5 with SMTP id h16-20020a5d4310000000b00315a1d5a3d5mr8623785wrq.22.1695720536636; Tue, 26 Sep 2023 02:28:56 -0700 (PDT) Received: from [192.168.0.167] ([62.197.243.85]) by smtp.gmail.com with ESMTPSA id g18-20020a5d5552000000b003196b1bb528sm14225496wrw.64.2023.09.26.02.28.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 26 Sep 2023 02:28:56 -0700 (PDT) From: "Pavlo Golub" To: "Guillaume Lelarge" , pgsql-translators@lists.postgresql.org Subject: Re: Is translating server messages really worth it? Date: Tue, 26 Sep 2023 09:28:55 +0000 Message-Id: In-Reply-To: References: Reply-To: "Pavlo Golub" User-Agent: eM_Client/9.2.2093.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MB9D436C87-419A-4E63-B190-12FEFC7A4DF1" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --------=_MB9D436C87-419A-4E63-B190-12FEFC7A4DF1 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hey everbody! >Hi, > >I know that $SUBJECT is a bit curious from someone who's been=20 >translating PostgreSQL server messages for quite some time now (I=20 >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=20 >with their PostgreSQL cluster, I tell them to set lc_messages to C, so=20 >that server messages are in english. It's kind of weird or funny to do=20 >the translation, and tell people not to use it. But, yeah, I don't know=20 >if it's a good thing or not, but when someone tries to search if=20 >someone else already met some weird server messages, this someone has=20 >more chances to get a hit with an english message than with a french=20 >message (though I guess it's the same for other non-english languages).=20 >If you have to use a tool such as pgbadger, this kind of tool only=20 >knows English messages. > >So, yeah, I'm kinda wondering if it makes sense to translate server=20 >messages. For client tools, such as psql or pg_dump or vacuumdb, it=20 >definitely makes sense. But the server logs? I pretty much don't know.=20 >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=20 describe the i18n process. We are all biased as consultants. We know how to solve problems=20 efficiently. We know where to search for solutions (usually the source=20 code). That's why we set C-style messages, run our standard procedures,=20 follow our methods, apply our own monitoring, etc. That's just a part of=20 our professional workflow, but it doesn't mean people shouldn't use=20 localized messages. Maintaining a glossary Want it or not, many areas use localized terms and words in everyday=20 life, e.g., education, medicine, military, etc. We might lose a lot if=20 we translate only the user interface part, omitting server messages. Satisfying requirements It sounds bureaucratic; nevertheless, we need a fully translated product=20 to pass some government, military, and education requirements. I've met=20 a situation when a product lost tender only because it wasn't localized.=20 And I don't need to remind which products are always localized and in=20 good shape: mssql, oracle, etc. Feedback You said already that some messages are nearly impossible to translate.=20 However, that mainly indicates the low quality of a source message, not=20 the absence of linguistic tools to express that message. Giving feedback=20 to developers increases source code quality. Error codes If only every single error message had a non-localized error code, we=20 wouldn't have this question at all. You agree that searching for "E0042"=20 is much easier than copy-pasting part of an error message. Even more,=20 having an error code gives you the freedom to change, adapt, and improve=20 error messages. It's not a rare story when messages are pretty different=20 between major server versions. We have SQLSTATE error codes, but AFAIR,=20 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=20 >say psql-fr.po) is not translated at 80%, it's not distributed. But I=20 >was wondering if it was only this file (psql-fr.po) or all the files=20 >for this language? I'm considering leaving the postgres-fr.po file=20 >without any translation, but keep the other files up to date. > >Thank you for your comments. > >Regards. > > >-- >Guillaume. --------=_MB9D436C87-419A-4E63-B190-12FEFC7A4DF1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hey everbody!

Hi,

I know that $SUBJECT i= s a bit curious from someone who's been translating PostgreSQL server messa= ges for quite some time now (I checked, I've been doing it for 20 years...)= . But still, I'm wondering.

Most of the time whe= n I'm at a customer's office trying to help them with their PostgreSQL clus= ter, I tell them to set lc_messages to C, so that server messages are in en= glish. It's kind of weird or funny to do the translation, and tell people n= ot 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 mess= ages, this someone has more chances to get a hit with an english message th= an with a french message (though I guess it's the same for other non-englis= h languages). If you have to use a tool such as pgbadger, this kind of tool = only knows English messages.

So, yeah, I'm kind= a wondering if it makes sense to translate server messages. For client tool= s, 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 cons= ultants. 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 message= s, run our standard procedures, follow our methods, apply our own monitorin= g, etc. That's just a part of our professional workflow, but it doesn't mea= n 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 m= essages.

Satisfying requirements
It sound= s bureaucratic; nevertheless, we need a fully translated product to pass so= me government, military, and education requirements. I've met a situation w= hen a product lost tender only because it wasn't localized. And I don't nee= d to remind which products are always localized and in good shape: mssql, o= racle, etc.

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

Error codes
If only ever= y single error message had a non-localized error code, we wouldn't have thi= s 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 giv= es you the freedom to change, adapt, and improve error messages. It's not a = rare story when messages are pretty different between major server version= s. We have SQLSTATE error codes, but AFAIR, they're not mandatory for loggi= ng 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 p= sql-fr.po) is not translated at 80%, it's not distributed. But I was wonder= ing if it was only this file (psql-fr.po) or all the files for this languag= e? 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.
<= /div>
--------=_MB9D436C87-419A-4E63-B190-12FEFC7A4DF1--