Group Comments

[stasm]

Is your feature request related to a problem? Please describe.
In a resource-file approach, it's common to group messages and give them a single comment which contains metadata about all the messages in a group.

Describe the solution you'd like
Define the data model for comments which are not attached to any single message and instead describe bigger groups of messages. For example, in the resource format's data model, a message might be one type of datum, and a comment might be another.

Describe why your solution should shape the standard
CAT tools can choose to present groups of messages in a special way, as they all likely relate to the same UI or problem. The group's comment can be displayed next to each message, to help translators understand the context and the purpose of the translations.

Additional context or examples
While #39 is about comments pertaining to a single message, this issue is about group comments. Fluent has group comments (describing a group of related messages), resource comments (describing the current resource), as well as standalone regular comments, which are handy for commenting things out temporarily. See https://projectfluent.org/fluent/guide/comments.html

[Fleker]

Would this support arbitrary levels of nesting?

[stasm]

So far, we've mostly seen use-cases for only one level of nesting, i.e. groups of messages. E.g. https://hg.mozilla.org/l10n/gecko-strings/file/0e4b8c9c2467d917bdeeaabab3a292d620ec78bb/browser/browser/browser.ftl#l156 has:

## Identity Panel

identity-connection-not-secure = Connection not secure
identity-connection-secure = Connection secure
identity-connection-internal = This is a secure {-brand-short-name} page.
identity-connection-file = This page is stored on your computer.
identity-extension-page = This page is loaded from an extension.
...

We haven't seen reasons to consider adding groups of groups, etc.

[nbouvrette]

It's a nice feature and also requires TMSes to support it correctly - but this seems more like a file format discussion than a Message Format discussion? Unless we are thinking that we will absolutely need a new file format, I think that being file format agnostic will increase adoption. I think I will start threads about both simplicity of the syntax and file format to help clarify those points.

[aphillips]

I think this pertains the resource file formats and thus is now out-of-scope for MFv2 (but in scope for the other work)

[aphillips]

Closing resolve-candidates per discussion in 2023-07-24 call