The evolution skin would previously provide a .po file. DirectAdmin would parse it into json, and send it to the skin. In the future, .json file will be used, to save the need for parsing. This feature auto-converts and saves .po files into .json files, so they don't need to be parsed again. Assuming both files are more than 0 bytes, the newer timestamp wins. If the .po file is newer than the .json, it's parsed, and the .json is overwritten. If the .json is newer, then .json is used, and .po file not touched. If there is no .json, one will be created from the .po. If there is no .po but there is a .json, the .json is sent, no parsing, no timestamp checks. Beyond that, you may want to have a custom translation. We'll use nl.po as an example. The priority order will be: lang/nl/custom/lang.po lang/custom/nl.po lang/nl/lang.po lang/nl.po For each of those paths, the related lang.json or nl.json file is also used. They're checked in pairs, so for example if lang/custom/nl.po is used, then lang/custom/nl.json created. Either file can exist for the priority match to trigger. As well, the login files nl/login.po, nl/login.json, login-nl.po, login-nl.json, can be used for all 4 of those aboves paths, custom or not. ============== PERFORMANCE Using Chrome's load time, and smashing F5 on: CMD_JSON_LANG?json=yes&lang=nl the presence of both files, where the json is used and not parsed, yielded anywhere from 75ms - 80ms. The presence of just the .po file, where the json needed to be created, took about 600ms, which includes the creation of the json file. Just to compare, I disabled the write of the json file, to see how fast just the parsing is, and it was about the same at 595ms.. so the write is neglibile. The parsing is the pig. Optimized the code to only sort the assembled data *after* it was all loaded into the container, and it dropped to 147ms for the parse, BUT this means it does not check for duplicates. So the code now requires that your .po files not contain duplicates.. and if they do, they'll both be shown... so best to avoid this. The gain is significant enough that we'll keep this optimization of near 0.5s. Of course, once the json is saved, the typical 75ms would resume for *all* subsequent requests, until a newer .po file comes along.