l10n data: *.intl

The *.intl format we propose is an extensible variant of the Mozilla l20n 'LOL' format. An *.intl file contains three kinds of statements:

• entities: identifier: value where “value” is a string, an array or a list;
• C-style macros / logical expressions;
• C-style comments.

The only difference with a 'LOL' files is that entities are expressed as identifier: value instead of identifier: (value)? (attributes)?, in order to be nestable and to keep a more extensible syntax. This identifier: value approach allows two consistent variants of the 'LOL' format:

• JSON-like entities, keeping the rest of the l20n format “as is”;
• YAML-like format: the whole l20n data would use an indentation-based structure.

JSON-like Variant

Example: test.json

The simplest possible change would be to replace 'LOL' entities by ID: value assignments, to become consistent with the JSON syntax applied to 'LOL' values.

The resulting format looks like JSON but is NOT JSON-compliant: the whole data is not enclosed in a main {…} block, identifiers aren’t inclosed in strings, comments are allowed. Besides, we suggest the comma separator should be optional at EOL (required otherwise).

Key benefits:

• overall consistency;
• a JavaScript / JSON syntax highlighter can be used;
• allows to group entities, and have an entity tree instead of a flat list;
• very close to the 'LOL' format: the 'LOL' parser we propose required very little effort to support this JSON-like variant.

Of course, this formats supports all LOL features.

YAML-like Variant

Example: test.yaml

The JSON-like format could also be written with a YAML syntax: structure blocks are replaced by indentation rules, and strings don’t have to be enclosed in quote marks. YAML makes a lot of sense to handle wrapped text of multiline text, with the > and | operators respectively.

Compared to the JSON-like variant:

• pro: no structure delimiters! no weird characters required!
• pro: much simpler to handle text in general;
• pro: format errors are easier to detect;
• con: some people don’t like to deal with indentation;
• con: requires a more specific parser.

This format looks like YAML, it can be syntax-highlighted as YAML, but is NOT strictly YAML-compliant. Again, all LOL features are supported.

Current State

Both variants have their pros and cons; as the JSON-like one is very close to the current LOL syntax, we’ve implemented it in our l20n parser: http://kazhack.org/webL10n/LOL/

We’ve stopped working on this at the moment, as we still hope to work together with the Mozilla l20n team on this. Until then, we’re using the good old *.properties format for l10n.js.