Topic on Talk:Requests for comment/Localisation format

I could not get sleep yesterday night, so I was thinking about this RFC. Here are my thoughts (after sleeping) I would like to highlight.

It's about time. Migration from non-executable format has come up with various people, so it's not a new idea. This is a step that will allow further improvements to our i18n: LocalisationUpdate v2 could be an example.

Keep it simple, secure. PHP is an executable file format. Loading the messages for translation at translatewiki.net and any other kind of manipulation is icky. Some people choose the easy way and just execute the code, which leads to potential security issues. The other option, parsing the syntax by hand is not fun either. All that complexity drops when we separate messages and use format for which we have parsers.

It could be faster, you know. The biggest i18n files in extensions could be megabytes. While handling JSON can be slower than using PHP (no data), overall this can improve performance by avoiding loading unnecessary data, as each language is split into separate file. For example change in one translation in on extensions would not trigger recaching of all languages anymore, as we can track timestamps per language now. This benefit applies to MediaWiki core as well as to translatewiki.net.

Thanks a lot, Niklas. I used some of this to update the rationale of the RfC.

Tangentially-relevant data: the last time I was asked to benchmark PHP-arrays verses JSON-objects in terms of loading performance (player data fixtures for testing a game server), JSON came out significantly faster, because it's a more limited format - a JSON object is certainly going to just be a data object; an included PHP file could be a class, a load of functions, anything.

Thank you for that background information, Happy-melon.

I guess we could get some benchmarking out of the VE experimenting quite quickly if we wanted to right ? That might be a good ida.