Re: [Caml-list] error messages in multiple languages ?

[Tao Stein <taostein@gmail.com>]

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

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
>>>
>>
>>
>

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