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