The purpose of this effort is to develop a standard for Unicode MessageFormat 2 resources, which may be used as a file format or otherwise.
In this context, a "resource" is a collection of related messages that may need to be stored, transmitted and/or handled together. A resource may classify its messages into groupings, and it may include additional data or metadata relating to them. It should be possible to represent a resource in a text-based human-friendly manner.
main
branch.
Text content should use semantic line breaks.
A PR may close one or more issues, but this is not required.We welcome your participation and interest!
As currently specified, a message resource looks like this (syntax highlighting only approximate):
@locale en-US
---
one = A message with no properties
@version 3
@since 2023-11-30
two = A message with some properties
# Freeform comments must come before properties
@param $foobar - An input argument
with a multiline value
three = Some {$foobar} message
with a multiline value
# Properties also attach to section-heads
@deprecated
[section]
four = Foo
This represents four en-US
messages with keys one
, two
, three
, and section.four
.
The comments and @properties
each attach to the next
section header, message entry, or resource frontmatter separator (not separated by whitespace).
Properties and message values may be multiline, provided that each of the following lines is indented by some whitespace.
All leading whitespace is trimmed from each line, unless it's \
escaped.
The exact syntax for properties and
message values
is defined separately.
The canonical definition of the resource syntax is found in resource.abnf
.
A message resource data model corresponding to the syntax definition
is included as resource.d.ts
,
an extensively commented TypeScript definition.
To enable interchange, a JSON Schema definition of the data model
is also provided in resource.json
.
This corresponds to Resource<Message, false>
in the parametric TypeScript definition,
where Message
is a MessageFormat 2 Message.
As with the MessageFormat 2 data model, the message resource JSON Schema relaxes some aspects of the data model, allowing comment and metadata values to be optional rather than required properties.