Skip to content

Describe registry use and conformance #563

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

Merged
merged 4 commits into from
Dec 18, 2023
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
42 changes: 39 additions & 3 deletions spec/registry.md
Original file line number Diff line number Diff line change
@@ -1,13 +1,13 @@
# WIP DRAFT MessageFormat 2.0 Registry

_This document is non-normative._

The implementations and tooling can greatly benefit from a
Implementations and tooling can greatly benefit from a
structured definition of formatting and matching functions available to messages at runtime.
The _registry_ is a mechanism for storing such declarations in a portable manner.

## Goals

_This section is non-normative._

The registry provides a machine-readable description of MessageFormat 2 extensions (custom functions),
in order to support the following goals and use-cases:

Expand All @@ -25,8 +25,44 @@ in order to support the following goals and use-cases:
- Display/edit known message metadata.
- Restrict input in GUI by providing a dropdown with all viable option values.

## Conformance and Use

_This section is normative._

To be conformant with MessageFormat 2.0, an implementation MUST implement
all of the formatting and selection _functions_ described in the default registry,
including all of the _options_ and _option_ values, _operands_ and outputs
described by the default registry.

Implementations are not required to provide a registry nor to read or interpret
a copy of this registry in order to be conformant.

The MessageFormat 2.0 Registry was created to describe
the core set of formatting and selection _functions_,
including _operands_, _options_, and _option_ values.
This is the minimum set of functionality needed for conformance.
By using the same names and values, _messages_ can be used interchangeably
by different implementations,
regardless of programming language or runtime environment.
This ensures that developers do not have to relearn core MessageFormat syntax
and functionality when moving between platforms
and that translators do not need to know about the runtime environment for most
selection or formatting operations.

The registry provides a machine-readable description of _functions_
suitable for tools, such as those used in translation automation, so that
variant expansion and information about available _options_ and their effects
are available in the translation ecosystem.
To that end, implementations are strongly encouraged to provide appropriately
tailored versions of the registry for consumption by tools
(even if not included in software distributions)
and to encourage any add-on or plug-in functionality to provide
a registry to support localization tooling.

## Data Model

_This section is non-normative._

The registry contains descriptions of function signatures.
[`registry.dtd`](./registry.dtd) describes its data model.

Expand Down