caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Evgeny Roubinchtein <zhenya1007@gmail.com>
To: Tao Stein <taostein@gmail.com>
Cc: OCaml Mailing List <caml-list@inria.fr>
Subject: Re: [Caml-list] error messages in multiple languages ?
Date: Mon, 10 Apr 2017 09:45:05 -0400	[thread overview]
Message-ID: <CAGYXaSYZ16P96TVfYJw2ZrM5TrCYic+=VHtCmOcNV9T_RTT3Aw@mail.gmail.com> (raw)
In-Reply-To: <CABs4Tj+=QzrLkQtnpTwaei8iJof-n0Eo6yTmv+GH9ZRJ3Q_wbw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3085 bytes --]

> 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 other
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 <taostein@gmail.com> 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 used
> more often in open-source projects.
>
> Tao Stein / 石涛 / تاو شتاين
>
> On 10 April 2017 at 14:14, Ian Zimmerman <itz@primate.net> 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
>>
>
>

[-- Attachment #2: Type: text/html, Size: 4796 bytes --]

  reply	other threads:[~2017-04-10 13:45 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-08 14:22 Tao Stein
2017-04-08 14:43 ` Gabriel Scherer
2017-04-08 15:03   ` Sébastien Hinderer
2017-04-08 16:38 ` Xavier Leroy
2017-04-08 16:51   ` Sébastien Hinderer
2017-04-08 16:56     ` Xavier Leroy
2017-04-09 19:50       ` Adrien Nader
2017-04-10  6:14         ` Ian Zimmerman
2017-04-10 13:20           ` Tao Stein
2017-04-10 13:45             ` Evgeny Roubinchtein [this message]
2017-04-10 14:04               ` Tao Stein
2017-04-10 18:07                 ` Adrien Nader
2017-04-10 19:45                   ` Hendrik Boom
2017-04-10 19:49                     ` Dušan Kolář
2017-04-11  0:38                       ` Tao Stein
2017-04-11 14:05 ` Richard W.M. Jones
2017-04-11 14:18   ` Gabriel Scherer
2017-04-11 14:59     ` Tao Stein
2017-04-11 17:17       ` Allan Wegan
2017-04-11 19:07         ` Glen Mével
2017-04-11 23:04           ` Allan Wegan
2017-04-12  0:12             ` Tao Stein
2017-04-16 22:37               ` Evgeny Roubinchtein
2017-04-09 17:15 Андрей Бергман

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAGYXaSYZ16P96TVfYJw2ZrM5TrCYic+=VHtCmOcNV9T_RTT3Aw@mail.gmail.com' \
    --to=zhenya1007@gmail.com \
    --cc=caml-list@inria.fr \
    --cc=taostein@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).