[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug-gettext] [bug #53071] JSON as alternative to (G)MO
From: |
Guido Flohr |
Subject: |
[bug-gettext] [bug #53071] JSON as alternative to (G)MO |
Date: |
Mon, 5 Feb 2018 17:41:18 -0500 (EST) |
User-agent: |
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:57.0) Gecko/20100101 Firefox/57.0 |
Follow-up Comment #2, bug #53071 (project gettext):
> Plural handling may need a bit more thought: where does the plural formula
come from? How about:
{"disk":{plural:["Platte","Platten"], formula:"n==1?0:1"}}
Why? (g)mo is just a container format. Why should json for translation
catalogs be more?
I think, there is a parser implementation for the "Plural-Forms" header for
all programming languages that support a gettext runtime with ngettext(). For
JavaScript, I have hacked together
https://github.com/gflohr/locale-textdomain/blob/master/src/plural-exp.js some
time ago, which should experience more testing, but basically works as far as
I remember.
I personally wouldn't tie a possible JSON output format too tightly to
JavaScript. JavaScript is just the origin of JSON. Why not leave the
interpretation of a plural form formula to the consumer of the JSON? In MO
files it is also just a string literal.
> Parsing and validating a JSON of a specific schema can be done without an
extra JSON library (see x-rst.c); it's only the parsing of generic JSON that
would require a JSON library. That's what I inferred after looking at a couple
of JSON libraries for C.
Great. I thought it was more difficult.
> Still, we should deal with LINE SEPARATOR and PARAGRAPH SEPARATOR in such a
way that the resulting JSON can be embedded in JavaScript (so that the client
can use eval to parse it)
I didn't understand that, sorry.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?53071>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/