Crest wrote: ↑May 25th, 2023, 12:38 pm
Putting the globals in the main script (and in my actual scenario getting array values returned via table/key names passed to the script) works, yes. If there's no other way then I'll obviously have to live with it but figured it was worth a shot in case I was missing something.
Crest wrote: ↑May 25th, 2023, 1:34 pm
Okay, so there's a doable workaround.
Yep, as you saw in the linked post, I also had to ask the devs about these things, since I don't know all the ins and outs of Lua's integration with Rainmeter. The workaround you found seems ok in my view, your "giant" table looks fine compared to
mine (that is thousands and thousands of elements corresponding to every "section", "key" and "value" parts, from a several MB savegame JSON style file).
That being said, I was also thinking that you could probably change the structure to suit things, instead of changing the code to suit the structure. If it's about languages, it stands to reason that an user only uses one language at a time in most cases (unless you want to display weather for different timezones and locations, each with its own language, at the same time). So, the actual variables you work with will be just the "current language" ones as a result. By comparison, you could store a virtually unlimited number of such languages on disk, to be used in your skin, e.g. (pardon my French):
WeatherEn.inc:
Code: Select all
Sunny="Sunny"
Cloudy="Cloudy"
Windy="Windy"
Rainy="Rainy"
WeatherFr.inc
Code: Select all
Sunny="Clair"
Cloudy="Nuages"
Windy="Vent"
Rainy="Pluie"
...
You can import whichever of these variables are current in either your dofile or main script and have a Weather = {Sunny=..., Cloudy=..., Windy=..., Rainy=...} and a Language=... for reference, according to the current language being used, and then do your thing with a one-dimensional table. I don't know if this suits your case, of course, but that's how I would imagine stuff for what you're aiming for.