[bug-gettext] [bug #53071] JSON as alternative to (G)MO

[Guido Flohr]

URL:
  <http://savannah.gnu.org/bugs/?53071>

                 Summary: JSON as alternative to (G)MO
                 Project: GNU gettext
            Submitted by: gflohr
            Submitted on: 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
         Discussion Lock: Any

    _______________________________________________________

Details:

(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.
- JSON parsers are universally available
- JSON is almost as compact as MO.
- It is to a certain extent human-readable.
- It uses Unicode.

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




    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?53071>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/