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