(Re: latest rev -- should it be notewarn for new PMs..? IIRC I set the semantics to use notenice because a PM isn't usually a 'warning' but something neutral or maybe even 'good news'... Or maybe I was just a bit too thorough with these three notice states..?)
I count 9 JS files at present: admin, captcha, editor, mediadmin, register, script, script-sha1, suggest, topic. That's not necessarily definitive, but what I've encountered so far in general use.
If you wander into the media area, you'll also get media and zoom files.
add_js_file would load the file, you'd be calling loadLanguage or loadPluginLanguage anyway from there.
Hmm it's called in wedge_cache_js, only at the time of caching, otherwise it'd defeat the purpose of it all... add_js_file doesn't call wedge_cache_js, unless the file isn't found.
That means, basically, you'll still fall into the process I'm talking about. There's no reason why the same process couldn't also contain the JS language file, though if I understand you correctly, you're almost talking about having multiple language JS files too...
script-123.js -> script.js with English strings (or whatever the default language is)
script-french-123.js -> script.js with French strings (or whatever the alternative language is)
Either way, I see no reason why an editor couldn't cope with being able to edit either and load from the DB, caching the results. It only has to worry about caching if people are daft enough to edit files directly, but then all bets are off anyway.
I'm not sure we're on the same line here..?
Anyway, to make things short:
We need to determine whether a language file has been modified. The easiest/quickest is to do it at loadLanguage time, because it's rather likely that PHP internally loads file data when including it (i.e. it knows the file modification date and doesn't waste time retrieving it again). If a language file is found to be updated, then we can do a simple call to clean_cache('js') to empty the JS folder. This means all JS files will have to be regenerated, even for a language file that never gets used in them -- but it's acceptable since (1) it's unlikely an admin is going to update their language files a lot...?, (2) these files only get generated when needed, thus they won't be regenerated all at the same time, and the extra CPU time is split over several minutes or hours.
Now, there are some potential problems once again...
- Imagine that script.js uses @language ManageTopics, and the admin never actually visits the admin area... It means the script file never gets updated, even if the corresponding language file is updated. It's unlikely, but still...?
- I still can't think of a 'correct' way to cache file dates. I'm thinking of something like this... Please give me your opinion?
A $settings['lang_dates'] array that contains keys like 'Admin_french' (as indicated in my previous post), and a value representing the modified date. The array is only filled with entries that are found in the JS scripts (@language entries), in the language requested. At compile time, the current language files and user language are used to store this data in the array, then submit it via updateSettings(). When it comes to doing loadLanguage(), the language and filename are determined, and if (isset($settings['lang_dates'][$filename . '_' . $lang]), then compare the actual filedate with that value... This would ensure that only the files actually cached in JS scripts will be tested for modifications. (Of course, if a plugin/feature is removed that used to include a certain language file, that entry will be wasting space in the database for nothing... But I don't have a solution for this, either.)