message editor web component

[samuelstroschein]

Must have

• separate <inlang-message-pattern> component #18
• styling mechanism for shared web components monorepo#2250
• SHOULD NOT HAVE BUSINESS LOGIC (DON'T USE SDK QUERIES, EXPOSE CALLBACKS OR BINDINGS. ASK @samuelstroschein)
• show all variants
• selectors
• matcher
• expose filter variants properties
• scope message lint reports to message id (throw if message lint reports contain unrelated reports)
• ability to add expression to pattern
• ability to render slots (custom buttons) in pattern

Maybe

Out of scope

• WYSISYG interface
• split screen variant view or something

[samuelstroschein]

I converted this issue from a draft because of opral/monorepo#2025. Having this web component message/pattern editor before pluralization seems to be a hard requirement to avoid only some apps to support pluralization/matching, or every app to build their own solution (wasted time).

[NiklasBuchfink]

@samuelstroschein Another requirement could be inline highlighting for rules. This could look similar to spelling correction in other editors with underlining, hovering to show warning, and resolving/autofixing if available.

• better UX as we show specific warnings inline (e.g. "InLang" -> "inlang")
• Parrot already supports this feature
• needed to support fixable lint rules in the future

[samuelstroschein]

Given #18, the structure of the rendered component in the DOM seems to go along the lines of:

<inlang-message>
  <-- patterns -->
  <inlang-message-pattern></inlang-message-pattern>
  <inlang-message-pattern></inlang-message-pattern>
  <inlang-message-pattern></inlang-message-pattern>
  <inlang-message-pattern></inlang-message-pattern>
  <inlang-message-pattern></inlang-message-pattern>
</inlang-message>