Agent Zuri wrote:
@OneTwoThreeFall: Maybe you could suggest some improvements to the author of the script.
Oh, it's not really a problem with i18n-js (on the contrary, it's quite well written!), it's just the way loading from a separate page like that has to work.
Apart from having translations inline with the script (as most currently do), something like i18n-js is likely the most efficient way to handle this within the current infrastructure. One possible improvement, though, would be for it to cache the i18n content in browser storage, avoiding the need to fetch it with every page load.
OneTwoThreeFall wrote: One possible improvement, though, would be for it to cache the i18n content in browser storage, avoiding the need to fetch it with every page load.
How would it know when to update that i18n data?
There could be a main object storing a mapping to the i18n files and their versions. If a file is modified, you simply have to update the version. The version can be compared with the one stored in local storage.
Agent Zuri wrote: But what if it would be loaded server side?
How do you mean? We can't really modify Wikia's codebase just so it can handle i18n of Dev scripts better.
@OneTwoThreeFall Granted, the extra requests are not an ideal situation, but I question whether quibbling over two requests is all that worthwhile in the grand scheme of things when the average user has dozens of HTTP requests added by advertising. 2 more is a raindrop in an ocean.
Caching would be a nice-to-have, but making it fixed is likely to cause weird issues down the line, especially if you add a new message the script now relies on and the script's cache updates before the messages do. Adding a timestamp parameter to the script seems like an unnecessary burden for an author when it's meant to be as pain-free as possible. For the time being, I don't think it is a particularly pressing issue.