L20n/Features/Resource file syntax

From MozillaWiki
< L20n‎ | Features
Jump to: navigation, search


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.


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

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.



<brandName "Value"
 accesskey: "c">

Flat YAML-like proposal:

brandName: Value
brandName.accesskey: c

Structured YAML-like proposal:

  &text: Value
  .accesskey: c

Structured YAML-like proposal, compact variant:

brandName: Value
  .accesskey: c



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).


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.