Topic on Talk:Requests for comment/Localisation format

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):

1. [MessageCache] Entire languages of database message overrides are stored in serialized PHP files
2. [MessageCache] Entire languages of database message overrides are stored in Memcached
3. [MessageCache] Entire languages of database overrides are loaded manually from the database
4. [MessageCache] Individual message overrides are stored in Memcached
5. [MessageCache] Individual message overrides are loaded manually from the database
6. [LocalisationCache] Entire languages of messages (with extension overrides) are stored in CDB files (or the database or cache, depending on config)
7. [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.

There's one thing I'd like to hopefully clarify on this: how will this be affecting message caching?

Immediately, it won't; the intent of this RfC is to change the file format, and nothing more, to lay the groundwork for future changes like better cacheing, client-side soft loading of messages, etc..

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?

Yes, this is a possibility, but not in this RfC; this just makes it possible.

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.

Yes, we were thinking automatic prefixing, but not in this RfC; this just makes it possible.

Going to correct James here a bit :).

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?

Maybe. The current cache format is very fast and efficient. We've not discussed this. In any case, it's out of scope of this RfC.

Ha. I removed a stress of "possible" too much to make it sound like we wanted to definitely change CDB files; fixed.

I'm beginning to think the point of separating messages into groups is solely to make development easier, which makes sense

As is written in the rationale, that is not solely the point. If it's the only point you see, that's great, because it's well within the scope of the RfC that developers don't hate it. So thanks for your feedback :).