There's one thing I'd like to hopefully clarify on this: how will this be affecting message caching?
Right now we have the following caching structure (note that this is the exact order in which they are checked):
- [MessageCache] Entire languages of database message overrides are stored in serialized PHP files
- [MessageCache] Entire languages of database message overrides are stored in Memcached
- [MessageCache] Entire languages of database overrides are loaded manually from the database
- [MessageCache] Individual message overrides are stored in Memcached
- [MessageCache] Individual message overrides are loaded manually from the database
- [LocalisationCache] Entire languages of messages (with extension overrides) are stored in CDB files (or the database or cache, depending on config)
- [LocalisationCache] Entire languages of messages (without extension overrides) are stored in PHP files (the usual MessagesEn.php)
I'm not going to ask wtf is going on in MessageCache because it's out of scope for this RFC, but the real question comes in LocalisationCache. One of the main advantages mentioned by this RFC is that the modular design allows the cache to be expired in portions. This makes a lot of sense since right now LocalisationCache uses the entire extension file as a FileDependency rather than just a single language file. However, how will message groups and sub-groups be accounted for? Since the CDB cache is for an entire language, it still has to be regenerated for any message change. Are we going to split the CDB files by group?
In fact, how are groups working in the first place? How will the software know which message keys are in each group? I looked at the VisualEditor example thinking maybe the message keys would be prefixed with the group name, but that is not the case. I'm beginning to think the point of separating messages into groups is solely to make development easier, which makes sense, but that should be explicitly stated.