-
Notifications
You must be signed in to change notification settings - Fork 1
Including resource-level metadata in the syntax #14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Thought of another example of related prior art: A number of markdown and other processors such as Pandoc and Jekyll support including a frontmatter section at the top of a document, with YAML contents and separated from the document body by a |
To expand a bit on the previous, YAML seems like the most common but not universal format for frontmatter with the Some systems like Hugo and remark use different indicators for different frontmatter formats. Of these, the only one that appears to have a universal meaning is Others (e.g. 11ty, VuePress) use a keyword after the start indicator for the format, like The origin of the |
In conversation with @zbraniecki elsewhere, he highlighted projectfluent/fluent#139:
And then regarding the scope of the problem we ought to be looking at here:
To which I replied:
|
The result of formatting a message depends on the environment in which that's done. With MF2, at least the following are relevant:
As these attributes are likely to be common to all messages in a single resource, it would probably make sense to include syntax or conventions for their declaration. These might not necessarily be used during the formatting runtime as then their values would be implicit, but would at least prove invaluable to translators and automated tools processing messages.
I'm aware of at least the following prior art that may be relevant to consider here:
Language
andPlural-Forms
that apply to the entire resource. The header entry usesmsgid ""
to identify itself.messages.json
files rely on being placed in a well-defined directory structure to identify the locale for their contents.Resource.properties
would useResource_de_CH.properties
for itsde-CH
locale.<file>
element includes at least thesource-language
attribute, and its other attributes and<header>
element may provide significantly more context about the resource.%YAML
directive, which defines the YAML version that's used by the document, e.g.%YAML 1.2
.Of the above, browser extensions and ResourceBundles stand out by incorporating their locale information within their file or directory name. I don't think this approach would work well for our purposes, given that not all of the relevant information is easily expressible via a locale identifier.
I think we should instead do something similar to the other formats, and incorporate metadata into the file using a syntax that's easy to parse (in particular for runtimes that don't care about the metadata), sufficiently expressive, but also extensible for later use cases that are not yet identifiable.
Of the fields I list above, I think the available functions and private-use annotations could be identified together via some "schema", for which we could use an identifier that references an external definition. With that we're left with key-value pairs that ought to each fit into a single line:
locale
, obviously using a BCP47 identifierschema
, defined via URL or some other structured string identifierversion
, with a numerical string like'2.0'
identifying the spec versionThis leaves a couple of open questions that ought to be answered:
Sidenote: One interesting possibility would be to use something like
format
instead ofversion
, and to incorporate the content format in the value, via e.g.'messageformat-2.0'
. This would potentially allow for the resource format to also support other message formats.The text was updated successfully, but these errors were encountered: