From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Jean-Christophe Helary Newsgroups: gmane.emacs.devel Subject: i18n/l10n summary Date: Sun, 28 May 2017 14:29:01 +0900 Message-ID: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_4670CA99-0D80-435B-9704-36F6256A0D0C" X-Trace: blaine.gmane.org 1495949367 8669 195.159.176.226 (28 May 2017 05:29:27 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 28 May 2017 05:29:27 +0000 (UTC) To: emacs-devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun May 28 07:29:15 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dEqlN-0001vg-CS for ged-emacs-devel@m.gmane.org; Sun, 28 May 2017 07:29:13 +0200 Original-Received: from localhost ([::1]:42808 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dEqlR-0006ze-9T for ged-emacs-devel@m.gmane.org; Sun, 28 May 2017 01:29:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38868) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dEqlJ-0006yz-0A for emacs-devel@gnu.org; Sun, 28 May 2017 01:29:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dEqlF-0005sK-En for emacs-devel@gnu.org; Sun, 28 May 2017 01:29:08 -0400 Original-Received: from mail-pf0-x22f.google.com ([2607:f8b0:400e:c00::22f]:36000) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dEqlF-0005qd-9w for emacs-devel@gnu.org; Sun, 28 May 2017 01:29:05 -0400 Original-Received: by mail-pf0-x22f.google.com with SMTP id m17so34032619pfg.3 for ; Sat, 27 May 2017 22:29:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:to; bh=i2ZKLq7LOG/I+u9GwkY74oS8PVxUI98XiRBlL7XyswA=; b=LuqbZ5UVR424a5k/hofRozHHvIadkx4Jltfmt9wDLuqIbQD898yMXbCzHUbljENj1/ 8ypUnSlXKdaP8TMv9cpqql7PCGRoLCitwonm4tu0zuzYCIFDcLotw7QmmQpi3ljXOIwF ry1/p/efN8RienYvFo/MyoP7HaFTOzOGXN8bcwBDFjJ7ZhrWD5T4kDqoVhL+5om9rIRv VIFGC967L9KrPmuLsI3a+jh5mEFHgh+QCN2R0oc6EsSNKEbxcc5bwJxfJlbHT3ppcJg1 vFhlHDrGDb84tpnMemhOLaXTWWGwNUN3fDI2RvUOAtpgS8TyYBxTceY+E0MMsjsx3+wt Y52w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=i2ZKLq7LOG/I+u9GwkY74oS8PVxUI98XiRBlL7XyswA=; b=nfTE48HuTgLhviRgeWQFAKlnCaZq4QvrhymOmLsNwA2BRn4G1K14PRi285XqkVyBSg t7gFVhelOPQP4UVamdXUKIaFNEJ6Fq/6YKXXFqo/VNkHKcB8Z3dm+vkheiaa4C1Q20Z4 nCohyexeV/pQK7bq22S5eoYvRIbmyqkmTI0yma1VAVuaSsHrLln24+hp8DPyj7dHzU/3 kLzASizdhpfOJfWWY2z0+yjTvYXpWbeOGfGVUL7DfPfiPF/nOvqE1Vgn0gUkrvfriHHI 2Z+N53ZLPzl6DpCFpmLMwOMBRPu+YIfJt3ZMgY1l9IeuAjYeX1IMtuZSJz2b9R3ezrl4 lrDg== X-Gm-Message-State: AODbwcAvg91QH+6gcHbKI4QZLIqxuww2GBy5JUlnVQj5Vzre0zP3+/Ee MEdigp5uOm9kHYRJKpg= X-Received: by 10.98.18.157 with SMTP id 29mr10747791pfs.75.1495949344177; Sat, 27 May 2017 22:29:04 -0700 (PDT) Original-Received: from [192.168.24.63] (pl25298.ag0304.nttpc.ne.jp. [133.232.153.210]) by smtp.gmail.com with ESMTPSA id n24sm11024875pfb.14.2017.05.27.22.29.02 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 27 May 2017 22:29:03 -0700 (PDT) X-Mailer: Apple Mail (2.3273) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:400e:c00::22f X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:215273 Archived-At: --Apple-Mail=_4670CA99-0D80-435B-9704-36F6256A0D0C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The discussion so far seems to point at modifying 'message' and the = likes so that developers don't have to bother with any l10n mechanism on = their part (besides for writing clean strings). =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D On May 27, 2017, at 10:52, Jean-Christophe Helary = wrote: > My very uninformed idea is that we need an independent function that = handles the preferred language check and the catalog parsing based on a = key, and all the string displaying functions (message etc) would be = redefined to call that function when a non default preferred langage = (currently English) is detected. On May 27, 2017, at 16:43, Eli Zaretskii wrote: > Yes but from what I've seen in package/el, a lot of translatable texts = are not displayed with "message". Some > use "error", some use other mechanisms. Internally, they all boil down to a small set of C functions, which is where we should make these changes. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Since it's C, I'm not going to be able to contribute to that before I = understand the language, and the function definitions. I guess it's time = I open that K&R that's been on my shelves forever... Jean-Christophe=20= --Apple-Mail=_4670CA99-0D80-435B-9704-36F6256A0D0C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii The discussion so far = seems to point at modifying 'message' and the likes so that developers = don't have to bother with any l10n mechanism on their part (besides = for writing clean strings).

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
On May 27, 2017, at 10:52, = Jean-Christophe Helary <jean.christophe.helary@gmail.com> wrote:

My very uninformed idea is that we need an = independent function that handles the preferred language check = and the catalog parsing based on a key, and all the = string displaying functions (message etc) would be redefined to = call that function when a non default preferred langage = (currently English) is detected.

On May 27, 2017, at 16:43, Eli Zaretskii = <eliz@gnu.org> = wrote:

Yes but from what I've seen in = package/el, a lot of translatable texts are not displayed with = "message". Some
use "error", some use other mechanisms.

Internally, they all boil down to = a small set of C functions, which is
where we should make = these changes.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D

Since it's C, I'm not = going to be able to contribute to that before I understand the language, = and the function definitions. I guess it's time I open that K&R = that's been on my shelves forever...

Jean-Christophe 
= --Apple-Mail=_4670CA99-0D80-435B-9704-36F6256A0D0C--