Modularity concerns regarding message bundles

[sffc]

My overarching concern with the direction of the EZ proposal is the tight coupling of message bundles with runtime message formatting. I mentioned this today and @eemeli and @zbraniecki wanted to discuss it in more detail, which I will do here.

Applications likely have hundreds or thousands of messages total, but only a fraction of them are used at a particular time. As a user navigates deeper and deeper into an application, they will touch more and more of the messages, but they will rarely touch all of them, and most of the time they will touch some small fraction of them.

Requiring messages to be put in message bundles causes two problems:

1. Data size: More messages are shipped than we need.
2. Runtime performance and memory usage: When formatting a new message, implementations need to either:
   1. Re-parse the whole big message bundle every time
   2. Pre-compute data structures at boot time and store them on the heap
   3. Implement a custom, non-standard zero-copy data structure

@eemeli said that message bundles could be split into smaller pieces and loaded on demand. My response: how granular of pieces, and where do we stop?

Modeling messages as single, self-contained entities lends itself well to modularization and loading only what you need. Putting message bundles at the center of the spec muddies the waters.

Further, the message syntax in EM and SM is simple enough that I expect that the runtime performance is good enough that most implementations won't need to pre-process the messages into another structure.

Further, as far as I can tell, the only technical reason to favor message bundles is that it makes it easier to share common terms across messages. I think this can be solved in a cleaner, more modular way by using a central glossary. Please let me know if there are further technical advantages to message bundles.

[sffc]

(I added a few more thoughts to the OP)

[nbouvrette]

I haven't kept track of the latest proposals but I fail to understand what MessageFormat has to do with bundles? Just like file formats, the way you bundle your messages should be up to the solution implementing the standard in my opinion.

[sffc]

@zbraniecki and @eemeli can explain this better than I can, but the "EZ" proposal contains a novel syntax for bundling messages together in a file, which allows messages to reference each other, with inspiration from how CSS and JS files work.

[zbraniecki]

I recognized a pattern of questions flowing from a paradigm of "single-message at runtime" that I see Shane's comment to be one of the arguments in.
I dumped my thoughts in a more consistent format into a Paradigm Shift Explainer centered around paradigm shift proposals that flow from the UI binding needs. The second paradigm shift is yet to be documented, but I'm sharing it as-is to help inform the discussion on the first already.