Add Resource data model #204
Conversation
|
Updated to match corresponding changes made to PR #195. |
|
|
||
| A Resource is often the data model representation of a single file, | ||
| but may be constructed from any source. | ||
| It is not necessary for an implementation to use Resources to hold messages. |
There was a problem hiding this comment.
Does this mean that Resources are an optional concept and not required to be implemented?
Or that conceptually, you can put all of your messages in a single Resource and avoid the use of multiple resources?
There was a problem hiding this comment.
This should probably be clarified a bit. My intent here was to communicate that it's entirely possible and allowed for a spec-compliant formatter to not have a need for Resources as an intermediate data structure, if it has other means of providing any message-getting functions.
On the other hand, formatters are by no means the only tools that need to work with messages and message resources; for example XLIFF import/export almost certainly will need a Resource to correspond to its <file> element.
| interface Resource { | ||
| id: string | ||
| locale: string | ||
| entries: Record<string, Message | MessageGroup> |
There was a problem hiding this comment.
Since entries here has the same definition as MessageGroup, maybe it would be clear to say that the entries are a MessageGroup?
There was a problem hiding this comment.
| entries: Record<string, Message | MessageGroup> | |
| group: MessageGroup |
Is this what you had in mind? I'm not sure that this additional indirection really helps much. As is, it's possible to think of Resource as an extension of MessageGroup.
Co-authored-by: Dan Minor <dminor@mozilla.com>
|
Closing as out of date after #307 |
This PR adds the data model for message resources and groups, i.e. groupings and hierarchical structures of messages. It refers to the
Messagedata type, which is defined in #195.As requested by @mihnita in the message data model PR, the interfaces' abstract data types are defined separately from their canonical JSON representations, and the metadata is left out. It is my belief that later work with the specification will indicate that it's simpler to merge these definitions, without creating a cost for implementations that choose to use a different internal representation than the canonical JSON.
I am aware of PR #203, and would be happy to work on a design document for this as well as other PRs, once it's defined what that ought to look like and if such a document is desired for this PR.
In my own code, these interfaces are defined here. The generic type parameter is used by the PatternMessage and SelectMessage interfaces to narrow down the pattern element types appropriately. In actual formatting use, these types are used by ResourceReader, which provides a more limited interface; this allows for e.g. non-enumerable message resources to be accessed. The ResourceReader API is in turn used by the
getMessage()method of MessageFormat.In addition to formatting, Resource is also used by @messageformat/compiler when converting MF1 and Fluent messages to MF2, and by @messageformat/xliff during conversion to and from XLIFF 2.