[BUG] Localized scripts not showing up correctly on website

[asherber]

When scripts take advantage of the new localization features, the metadata extractor is not able to grab things correctly for use on the website.

Although #689 refers specifically to the bundler, it may be that solving this current issue requires rewriting the metadata extractor in Lua, since it's no longer a matter of simply parsing out strings from the .lua file.

cc: @rpatters1

[rpatters1]

Oof. Not an easy fix I can think of. If we let our meta-data extraction dictate what scripts can do, it feels a bit like tail wagging dog.

The safest and most future-proof solution would probably be to do what RGP Lua and (seemingly) JW Lua do. That is, extract the plugindef from the script and execute it in a minimal Lua environment, then extract the results. That way there would be no need to parse it directly.

I can tell you that embedding Lua in a program is trivially simple. If need be I could write a standalone program to do it. But it may be possible to simply run Lua from the command line and get what we need.

[asherber]

Yes, I think I can configure our action runner with Lua and execute plugindef(). This will take some experimentation and probably won't happen in the next couple of days, but hopefully within the week.

[asherber]

MinJWLuaVersion and MaxJWLuaVersion are defined as numbers. The current get-metadata action reads these as strings, but the new Lua-based one sees it, correctly, as a number -- but turns it into a string for compatibility with what the website expects.

This means that finaleplugin.MinJWLuaVersion = 0.70 will result in a string value of 0.7.

I can think of three ways to handle this:

1. Leave it as-is.
2. After Lua returns all the finaleplugin values to JS, use JS to override this property by grabbing the string out of the original plugindef() text.
3. Change these properties to strings in plugindef().

I'm hoping that if we do 3, JW/RGPLua will still be able to use the value correctly. I imagine that this is fine, since Lua will coerce strings to numbers when doing arithmetic or mathematical comparisions. @rpatters1 Can you confirm?

I'd really rather not do # 2, because it would be the only value that JS reads directly from the code, and I'm concerned that # 1 would look strange on the website. It feels like version numbers should be strings anyway, for reasons like this.

[asherber]

I suppose there's a fourth approach, which is for JS to look at the returned string (e.g., 0.7) and work magic on it to make sure there are at least 2 decimal places. Conceptually, this is okay with me because I'm already doing some manipulation of returned values in JS, but it doesn't feel great. Better than # 2, perhaps, but still not as clean as # 4.

[rpatters1]

Could you use string.format to guarantee 2 decimal places?

[rpatters1]

To answer your question, I don't know what either plugin would do with it. It might work, but I'd rather not do it if there's another way.

This Lua code should produde "0.70":

local formattedString = string.format("%.2f", 0.7)

[asherber]

Sure, I can get 2 decimals in Lua or JS. But then what about version 0.100? Or 1.2?

I'll play with some options, see if I can get consistent results.

[rpatters1]

I don't know what JW Lua does, but RGP Lua takes those numbers and multiplies them by 1000 and then converts them to integers. So 0.70 becomes 700. Then it does numerical comparisons.

As long as I'm working on RGP Lua, I will commit to the minor version number never being fewer than 2 digits or more than 3.

[rpatters1]

Actually I realize my approach really doesn't work with 3 digits, so if we ever get to v0.99, it may be time to take the plunge to 1.00.

[asherber]

(I think it should be v1 already--hard to call this still a beta!)

If RGP multiplies by 1000, then it would actually be fine with a string value, because the multiplication coerces it to a number. But if we don't know what JW does....

The problem, of course, is that version numbers really are strings, not numbers.

[rpatters1]

I would have to debug into the bowels of LuaBridge to find out if it would automatically convert a string to a float on the c++ side. It might or it might not.

My recommendation is for now to assume 2 decimal places and if the day ever comes when that's not the case, we'll cross the bridge then.