From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 42E9D7FA83 for ; Mon, 10 Apr 2017 16:04:56 +0200 (CEST) Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=taostein@gmail.com; spf=Pass smtp.mailfrom=taostein@gmail.com; spf=None smtp.helo=postmaster@mail-qt0-f173.google.com Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of taostein@gmail.com) identity=pra; client-ip=209.85.216.173; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="taostein@gmail.com"; x-sender="taostein@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of taostein@gmail.com designates 209.85.216.173 as permitted sender) identity=mailfrom; client-ip=209.85.216.173; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="taostein@gmail.com"; x-sender="taostein@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-qt0-f173.google.com) identity=helo; client-ip=209.85.216.173; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="taostein@gmail.com"; x-sender="postmaster@mail-qt0-f173.google.com"; x-conformance=sidf_compatible IronPort-PHdr: =?us-ascii?q?9a23=3AdvolgRXG3CSdrads7+kVom8B+JjV8LGtZVwlr6E/?= =?us-ascii?q?grcLSJyIuqrYbBGGt8tkgFKBZ4jH8fUM07OQ6PG8HzRYqb+681k6OKRWUBEEjc?= =?us-ascii?q?hE1ycBO+WiTXPBEfjxciYhF95DXlI2t1uyMExSBdqsLwaK+i764jEdAAjwOhRo?= =?us-ascii?q?LerpBIHSk9631+ev8JHPfglEnjSwbLd9IRmssQndqtQdjJd/JKo21hbHuGZDdf?= =?us-ascii?q?5MxWNvK1KTnhL86dm18ZV+7SleuO8v+tBZX6nicKs2UbJXDDI9M2Ao/8LrrgXM?= =?us-ascii?q?TRGO5nQHTGoblAdDDhXf4xH7WpfxtTb6tvZ41SKHM8D6Uaw4VDK/5KpwVhTmlD?= =?us-ascii?q?kIOCI48GHPi8x/kqRboA66pxdix4LYeZyZOOZicq/Ye94VQndPXttKVyxZHIyz?= =?us-ascii?q?c5cPAeQGPeZdtYb9pl0Opga6CQSjAO7jzzlFjWL006InyeQsCQPJ3AIgEdwAs3?= =?us-ascii?q?rascv7O7sJXO+v0KXF1y/OY+9K1Tr/7oXDbxAvoeuLXbJ1acff11MgFwTYhVuN?= =?us-ascii?q?tYzqITKV1uIQuGWc8+pvT+Wvi3U7qw5vozivwNwhiobMho0Py1DE8T91z5oyJd?= =?us-ascii?q?29UUN2Z8OvHpVXtyGfLYR2Q8UiTnlpuCY80L0GuIS0cDIEyJQ93xLea+aIc4iP?= =?us-ascii?q?4hLkTuqePTB4hHd9dLO/nxa+61Sgyur6W8Kp01hKtjJInsfQun0JzRDe6ciKRu?= =?us-ascii?q?Fj8ku82DuDzR3f5+NKLE0yiKHVMYQuwqQqmZoWqUnDHjH5mEHxjKKOc0Ur4Omo?= =?us-ascii?q?6+D+brX/up+QK5Z4ig/jPqkslMGzG+s4Mg8JX2iU/eSzyqfv8lH+QLVPlvE2k6?= =?us-ascii?q?/Zv47GJckDuKK1HwtY3pwg5hu/FTuqzskUkHgdIF5Yeh+KgZDlO1TUL/D5Cfe/?= =?us-ascii?q?jU6skDBux/3eIr3uGJLNLmPfkLj/fLZ97VVRyAU2zd9F5pJUDqsNL+70Wk/0rN?= =?us-ascii?q?DYFAM2MxSow+b7D9Vwzp8RVniKAq+dKa/StV6I5vkzI+SXf48UuDP9K+A/6PL0?= =?us-ascii?q?jH85n0Udfaiz0pcNZnC4BKcuH0LMTGTjj9EQWV0NowA/SufqlFCDV3YHdXa/Wb?= =?us-ascii?q?M1v2ljV6qpCI7CQsamh7nXjwmhGZgDWmlBQmuQHHbuP9GYUvAXdC+TJOdulzUF?= =?us-ascii?q?Uf6qTIp3hkLmjxPz17cydrmcwSYfr5+2kYUs6g=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ChAADUkOtYhq3YVdFdGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBFQEBAQECAQEBAQgBAQEBhAl5EgeDX5tZgjqTHYIPLIV4AoNVB0AXAQE?= =?us-ascii?q?BAQEBAQEBAQESAQEBCAsLCCgvgjMigkABAQEBAgEjHQEbEgsBAwELBgMCCwMKD?= =?us-ascii?q?R0CAiEBAREBBQEKEgYTCAoMiVgBAw0IDoskkRo/jASCBAUBHIMJBYNRChknAwp?= =?us-ascii?q?VglgBAQEBAQEEAQEBAQEBARkCBhKGPoNngQmCUSWBQwEBSIJZgl8Fh0kMiRWLV?= =?us-ascii?q?juHAIcchD2Bf1WEWYNahjqLAIc4FB+BFQ8RAYE7OyAVQRiECiofgXwzNYcxgi4?= =?us-ascii?q?BAQE?= X-IPAS-Result: =?us-ascii?q?A0ChAADUkOtYhq3YVdFdGgEBAQECAQEBAQgBAQEBFQEBAQE?= =?us-ascii?q?CAQEBAQgBAQEBhAl5EgeDX5tZgjqTHYIPLIV4AoNVB0AXAQEBAQEBAQEBAQESA?= =?us-ascii?q?QEBCAsLCCgvgjMigkABAQEBAgEjHQEbEgsBAwELBgMCCwMKDR0CAiEBAREBBQE?= =?us-ascii?q?KEgYTCAoMiVgBAw0IDoskkRo/jASCBAUBHIMJBYNRChknAwpVglgBAQEBAQEEA?= =?us-ascii?q?QEBAQEBARkCBhKGPoNngQmCUSWBQwEBSIJZgl8Fh0kMiRWLVjuHAIcchD2Bf1W?= =?us-ascii?q?EWYNahjqLAIc4FB+BFQ8RAYE7OyAVQRiECiofgXwzNYcxgi4BAQE?= X-IronPort-AV: E=Sophos;i="5.37,182,1488841200"; d="scan'208,217";a="268501226" Received: from mail-qt0-f173.google.com ([209.85.216.173]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 10 Apr 2017 16:04:47 +0200 Received: by mail-qt0-f173.google.com with SMTP id c45so63540474qtb.1 for ; Mon, 10 Apr 2017 07:04:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8wWZjkSwjocAl2q1FWbu0dbBocCEfJeY79Xcpgq8fIE=; b=M2QCH9IBPA7TwEeWdUboMsxVZzME2oimm2hMEYCh9b1zrEWrZyWMRmR5eQU9gGxFl3 9ZE4Vvd3wW5JgIJxJ2yGJ/Sj2Zhdran1MnndMalWC7wxWc9P82X9if9xNlVHLPlG4JF7 quh2DVC/qai+w21I24VzQVSBAEiKLMivYezXAuQMyoDw2xPEfb5HTF9YWrt3CIOIfVZH CNO9bWcd+qcn6zAT7vHfgJGJIaFWOaR/DW8EKIlTVCaoneWvPopFHWY+kZaoNYJKTC1G OtXdYQdYtY8UAzsGcSpspl2pACmbfznAhyZGmySXCYpPvS5ASqyONA7cDotkqGy90iVL lNYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8wWZjkSwjocAl2q1FWbu0dbBocCEfJeY79Xcpgq8fIE=; b=N0ycL3Kd+6hAh1ywPgC+ejjQSj8h9rjrU8p4KXoY0HmAWiSmo4oIPcOIXGQB1wL2rl u4GP4sjImKV9Cvr2XnkJOmAuBwD1IlHb0p/TIGLhH2MpOBa90lODG4/OkmlNCxDwpZ9Y /34OjlJXgBUIs3AYgyFszhq8781OMiRGH4GFoGbkFdJYy6bF23GWRfBd15lcIGmPJcgX FTWH8zkmCbTQP9g3ujZr5Bl4z8233aTxmochVY86wl36DbIDoHX903E/pzII2PRuHOSa rm3B0S3DXw/WSfZq/6bB1qCMcRNKbYzHQlOOCdnsFI//17BpCw1jIuoLKat/4IdYAJUZ xdzQ== X-Gm-Message-State: AFeK/H0G/MAg+IjcLuCTcidWpnDl4tC1a/lDko38HW3XU6fzy+ebqWFl1Flv9iiiW7YlHoHTeer8xVAViLBTrg== X-Received: by 10.200.44.100 with SMTP id e33mr54235008qta.192.1491833084516; Mon, 10 Apr 2017 07:04:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.150.178 with HTTP; Mon, 10 Apr 2017 07:04:43 -0700 (PDT) In-Reply-To: References: <1715c9d9-04d7-3368-bfbd-3af8aae4698b@inria.fr> <20170408165106.55n6zfwd3tsdxxgw@pema> <8261755f-fb74-c363-a764-08623c06ce3a@inria.fr> <20170409195059.GA3385@notk.org> <20170410060741.10271.10E692AB@matica.foolinux.mooo.com> From: Tao Stein Date: Mon, 10 Apr 2017 22:04:43 +0800 Message-ID: To: Evgeny Roubinchtein Cc: OCaml Mailing List Content-Type: multipart/alternative; boundary=001a1147e5aa111c82054cd0755d Subject: Re: [Caml-list] error messages in multiple languages ? --001a1147e5aa111c82054cd0755d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'm not sure one would have to be able to read all the languages for there to be some win. There may be some similarity between subsets of the languages -- within the Latin languages, Traditional and Simplified Chinese, for example. If I were putting in Traditional Chinese messages, I'd want them to be consistent with the Simplified Chinese messages, and I need not be able to read Spanish. Anyways, I'm not convinced this is a big win. Maybe just something to think about. Any thoughts on using UTF-8 for the file(s)? And thoughts on the other points? Tao Stein / =E7=9F=B3=E6=B6=9B / =D8=AA=D8=A7=D9=88 =D8=B4=D8=AA=D8=A7=D9= =8A=D9=86 On 10 April 2017 at 21:45, Evgeny Roubinchtein wrote: > > With one file it's easy to see all the translations for a string at > once, to ensure consistency. > > Aren't you making an implicit assumption that a single person is able to > read all the languages? If so, is that a good assumption? I would argue > that it isn't. Besides, bringing together several translations could > conceivably be done with tooling built on top of gettext. One more > observation is that, if all translations are in one file, then there needs > to be a single text encoding that encodes all those languages. Yes, I do > know about Unicode, but I also know that people may still wish to use oth= er > encodings as a matter of habit, local convention, or even perceived > problems with Unicode (Han unification comes to mind, but there may be > other issues, for example different languages being best served by > different normalization forms). > > -- > Best, > Zhenya > > On Mon, Apr 10, 2017 at 9:20 AM, Tao Stein wrote: > >> >> Would people have concerns creating a compiler build dependency on >> libgettext ? >> >> Another concern is that xgettext seems to lack an OCaml back-end. >> >> Also, there may be some advantages to having all the language strings >> together in one file, as in the 1997 Caml Light implementation Xavier >> shared. As opposed to the many .po files of a typical gettext workflow. >> With one file it's easy to see all the translations for a string at once, >> to ensure consistency. The gettext workflow, though somewhat complex, may >> be more scalable. Though it's not clear to me paying for the scalability >> with the additional complexity is worth it in this case. I'm undecided. >> >> In terms of gettext versus catgets, some more knowledgeable people may >> have better opinions. Searching around a bit, it seems that gettext is u= sed >> more often in open-source projects. >> >> Tao Stein / =E7=9F=B3=E6=B6=9B / =D8=AA=D8=A7=D9=88 =D8=B4=D8=AA=D8=A7= =D9=8A=D9=86 >> >> On 10 April 2017 at 14:14, Ian Zimmerman wrote: >> >>> On 2017-04-09 21:50, Adrien Nader wrote: >>> >>> > Unsurprisingly, pretty much everyone uses gettext rather than catgets. >>> > >>> > Personally I've enjoyed using gettext and I've found that it provided >>> > the features needed for a proper translation in a pretty good way. >>> >>> The one problem with gettext (which catgets lacks) is that it relies on >>> a piece of global data (the "text domain binding"). This makes any way >>> to handle translations in a shared library somewhat distasteful. >>> >>> Admittedly one can wave the problem away by relying on the default >>> binding established when glibc or libintl is installed, and never >>> calling bindtextdomain(). >>> >>> -- >>> Please *no* private Cc: on mailing lists and newsgroups >>> Personal signed mail: please _encrypt_ and sign >>> Don't clear-text sign: http://cr.yp.to/smtp/8bitmime.html >>> >>> -- >>> Caml-list mailing list. Subscription management and archives: >>> https://sympa.inria.fr/sympa/arc/caml-list >>> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners >>> Bug reports: http://caml.inria.fr/bin/caml-bugs >>> >> >> > --001a1147e5aa111c82054cd0755d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I'm not sure one would have to be = able to read all the languages for there to be some win. There may be some = similarity between subsets of the languages -- within the Latin languages, = Traditional and Simplified Chinese, for example. If I were putting in Tradi= tional Chinese messages, I'd want them to be consistent with the Simpli= fied Chinese messages, and I need not be able to read Spanish. Anyways, I&#= 39;m not convinced this is a big win. Maybe just something to think about. = Any thoughts on using UTF-8 for the file(s)?

And t= houghts on the other points?

Tao Stein / =E7=9F=B3= =E6=B6=9B /=C2=A0=D8=AA=D8=A7=D9=88 =D8=B4= =D8=AA=D8=A7=D9=8A=D9=86

On 10 April 2017 at 21:45, Evgeny Roubinchtein <zhen= ya1007@gmail.com> wrote:
> With one file it's easy to se= e all the translations for a string at once, to ensure consistency.

=
Aren't you making an implicit assumption that a singl= e person is able to read all the languages?=C2=A0 If so, is that a good ass= umption?=C2=A0 I would argue that it isn't.=C2=A0 Besides, bringing tog= ether several translations could conceivably be done with tooling built on = top of gettext.=C2=A0 One more observation is that, if all translations are= in one file, then there needs to be a single text encoding that encodes al= l those languages.=C2=A0 Yes, I do know about Unicode, but I also know that= people may still wish to use other encodings as a matter of habit, local c= onvention, or even perceived problems with Unicode (Han unification comes t= o mind, but there may be other issues, for example different languages bein= g best served by different normalization forms).

--
Best,
Zhenya

On Mon, Apr 10, 2017 at 9:2= 0 AM, Tao Stein <taostein@gmail.com> wrote:

Would people have concerns cre= ating a compiler build dependency on libgettext ?

Another concern is that xgettex= t seems to lack an OCaml back-end.

Also, there may be some advantages to having a= ll the language strings together in one file, as in the 1997 Caml Light imp= lementation Xavier shared. As opposed to the many .po files of a typical ge= ttext workflow. With one file it's easy to see all the translations for= a string at once, to ensure consistency. The gettext workflow, though some= what complex, may be more scalable. Though it's not clear to me paying = for the scalability with the additional complexity is worth it in this case= . I'm undecided.

In terms of gettext versus catgets, some more knowledgeabl= e people may have better opinions. Searching around a bit, it seems that ge= ttext is used more often in open-source projects.

Tao Stein / =E7=9F=B3= =E6=B6=9B /=C2=A0=D8=AA=D8=A7=D9=88 =D8=B4= =D8=AA=D8=A7=D9=8A=D9=86

On 10 April 2017 at 14:14, Ian Zimmerman <itz@primate.net> wrote:
On 2017-04-09 21:50, Ad= rien Nader wrote:

> Unsurprisingly, pretty much everyone uses gettext rather than catgets.=
>
> Personally I've enjoyed using gettext and I've found that it p= rovided
> the features needed for a proper translation in a pretty good way.

The one problem with gettext (which catgets lacks) is that it relies= on
a piece of global data (the "text domain binding").=C2=A0 This ma= kes any way
to handle translations in a shared library somewhat distasteful.

Admittedly one can wave the problem away by relying on the default
binding established when glibc or libintl is installed, and never
calling bindtextdomain().

--
Please *no* private Cc: on mailing lists and newsgroups
Personal signed mail: please _encrypt_ and sign
Don't clear-text sign: http://cr.yp.to/smtp/8bitmime.html=

--
Caml-list mailing list.=C2=A0 Subscription management and archives:
https://sympa.inria.fr/sympa/arc/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs



--001a1147e5aa111c82054cd0755d--