L20n/Features/Resource file syntax

goal

Consider potential improvements in the resource file syntax in order to improve working with the source files.

The format is supposed to follow L20n/File_format_principles.

content

Currently we have LOL syntax, and feedback on it from Mozilla French Team the B2G/Gaia and JetPack teams [12].

The counter proposal is revolving around changes to the LOL syntax that would make it less XML'y, and more YAML'y, so to say. The list of proposed changes is the following:

• remove entity delimiters (<>) and replace them with indentation-based entity structure recognition.
• separate entity attributes into separate entities
• C-like comments vs. YAML-like comments
• string delimiters in YAML vs LOL

The B2G/Gaia and JetPack teams are perfectly happy with the following LOL aspects:

• the JSON-like values: strings, arrays, dicts
• the C-style expressions: in strings, identifiers, macros
• the C-style comments

Their counter proposal is to change the way entities are declared[3]:

1. to have a simpler syntax for the basic key/value cases (> 90% of all strings) — it shouldn’t be more complex than the current *.properties file format!
2. to allow grouping/nesting entities
3. to bring a more consistant syntax (syntax highlighting support?)
4. to bring a more generic/extensible syntax, thus easing the handling of unforeseen cases

The choice of a syntax is a matter of taste (XML, JSON, YAML, etc.) and should be discussed. The key point in having a extensible syntax is that it requires expressing element attributes and content in a generic way.

example

LOL:

<brandName "Value"
 accesskey: "c">

Flat YAML-like proposal:

brandName: Value
brandName.accesskey: c

Structured YAML-like proposal:

brandName:
  &text: Value
  .accesskey: c

Structured YAML-like proposal, compact variant:

brandName: Value
  .accesskey: c

See:

• YAML-like demo file
• JSON-like demo file
• online LOL/JSON parser

prefixes

To avoid « namespace » conflicts between element content/attributes and localization properties, a specific prefix should be used.

As the dot is already used as a prefix for attributes in LOL expressions, we suggest keeping it in entity declarations. Element properties could be prefixed with an &, e.g. &textContent/&innerHTML or &text/&html for short (note that this would allow to be sharper, and to use other content syntaxes).

status

We need to investigate how such syntax may work for the localizers, will it indeed make working with files easier, how will it accommodate the grammar that we have for LOL together with the proposed extensions listed on the L20n/Features list.

We should first open the discussion on m.d.l10n and involve more people in the discussion: l10n contributors, developers, format/standard experts.