GNU gettext - Bugs: bug #53071, JSON as alternative to (G)MO
You are not allowed to post comments on this tracker with your current authentication level.
bug #53071: JSON as alternative to (G)MO
Submitter: | Guido Flohr <gflohr> | ||
Submitted: | Mon 05 Feb 2018 04:11:45 PM UTC | ||
Category: | JavaScript | Severity: | 1 - Wish |
Item Group: | None | Status: | None |
Privacy: | Public | Assigned to: | None |
Open/Closed: | Open |
Tue 06 Feb 2018 09:58:21 PM UTC, comment #5: |
Bruno Haible <haible>![]() |
Tue 06 Feb 2018 08:57:12 PM UTC, comment #4: I did rewrote msgunfmt a year ago to achieve this together with JED.js and called it mo2json. Lemme check if I can find a patch tomorrow. |
Markus Gothe <nihilus> |
Tue 06 Feb 2018 12:41:56 AM UTC, comment #3:
|
Bruno Haible <haible>![]() |
Mon 05 Feb 2018 10:41:18 PM UTC, comment #2:
{"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.
|
Guido Flohr <gflohr>![]() |
Mon 05 Feb 2018 09:51:32 PM UTC, comment #1: This is a very good proposal. Yes, I agree that JSON is the de-facto standard for server->client communication of data to JavaScript programs running in a browser.
|
Bruno Haible <haible>![]() |
Mon 05 Feb 2018 04:11:45 PM UTC, original submission:
(G)MO files contain all information needed for message translation at runtime in a very compact form.
Today, the JavaScript Object Notation JSON could be used as an alternative format. Benefits would be:
- It is not binary.
The last feature could also be considered a problem but I think for practical purposes, limiting the encoding to UTF-* is rather an advantage today.
The "schema" would be straightforward. JSON translation catalogs should probably have this form:
{"Hello, world!":["Bonjour le monde!"]}
The values should be arrays, so that plural forms can be represented. While parsing binary data in JavaScript is cumbersome, splitting a key at a possible EOT into a context and a message id is simple:
var parts = key.split("\004", 2);
These JSON files could be easily converted into just about any other format with a similar notion of a translation database.
But especially for JavaScript, this improvement would be very helpful. At the moment, there is a large variety of translation frameworks based on PO files for JavaScript. They are based on PO files because the binary MO format is hard to parse.
These frameworks almost exclusively use either PO files directly, or parse the PO files and convert them to JSON. This is inefficient, error-prone, and you lose important msgfmt features like '--check' and '--statistics'. An new msgfmt option '--json' would make these hacks unnecessary.
Writing JSON is very simple in this case because we only deal with strings that are trivial to encode. That means, it would not pull in any external dependencies.
Parsing and validating JSON as input for msgunfmt is, of course, harder but also less important.
Just in case: this feature request has nothing to do with https://savannah.gnu.org/bugs/?48903 |
Guido Flohr <gflohr>![]() |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Yes, you started a discussion about it in sr #109175 .