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 / 石涛 / تاو شتاين

On 10 April 2017 at 21:45, Evgeny Roubinchtein <zhenya1007@gmail.com> 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 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