English vs localized command line options

Hi All,

I don’t have a way to test it out, but trying to find out if running a rhino command with underscore, to force English command usage, would also display all the options and prompts in english?

–jarek

Hi Jarek,

It doesn’t, unfortunately…

–Mitch

Thanks Mitch for confirming that, and yeah, unfortunately…

What I am trying to do it to read command history to determine/change some settings that are not scriptable right now, but looks like it can’t be made functional everywhere, unless I test for the word “No” in all Rhino localized versions…
(now I am looking at -_GradientView command in particular, but had some more cases in the past as well).
Just trying to determine if it is on or off. Would you have any other ideas how to handle it and make in non-English specific ?

thanks

–jarek

Hey Jarek,

No idea really, and _GradientView does not look like it’s been exposed in rhinoscript syntax or RhinoCommon… :frowning:

GradientView is a weird example. It was added as a test command long ago and was never removed because some people liked it.
Thet est command served it’s purpose and should have been removed, but because so many users screamed, it was left in in the pseudo limbo state.

You can (and should) get the same 2-color gradient effect using a named display mode that is documented and scriptable, but it will be a little more complicated.

Hi @John_Brock

Thank you, yes - I know the GradientView is a bit odd, and actually that’s why I need to test it (I need to know in my script if user has it enabled or not, and the only way I know of to do it was by running -GradientView and reading command line history for Yes or No. I wonder if GradientView has been localized, if it is odd…

But in general I have been using the method of reading command line in the past ( or now with TestToggleSubObjectSelection), and not I realize it will not work well on non-English versions of Rhino…

Test commands will never be localized.
They are not documented or officially supported.
The developers add them to test functionality and concepts.
They can go away without notice.
When we learn what we need to learn, then the test command is abandoned and the feature added to incorporated into a top level, exposed, documented command.

GradientView was the test command that we used to test the concept of added that ability to the named display modes. We did and the tool is there. We just never deleted the old test command.

It should never have been promoted to it’s present state that auto-completes.

Oh, so at least I can assume my ‘workaround’ will work with GradientView command then. good to know-- thanks

Maybe, but I think it’s risky.
GradientView may go away as a command without notice, leaving you high and dry.
It would be more responsible to go the scriptable named view mode or to export a named view INI file with the settings that gave you the same result.

That’s exactly what I am doing; there is just a risk the user has GradientView on, which overrides all other settings, so I am testing for it as in V5 its there to stay. If it goes away, even better, no hard feelings ; )

~j

Ah, yes.
I can’t being to tell you the number of times a user accidentally gets into GradientView and can’t figure out how to toggle it off again.
Total PITA
Shame on us at McNeel for allowing this to happen and then not (still not!) killing it.

Since GradientView isn’t formally a test command (I mean: it doesn’t start with “test” and does autocomplete), it is localized (at least in Polish).

@mikolaj, thanks, good to know (unfortunately!)

~j

I just added it to the development meeting agenda for tomorrow.
We need to either make it a documented, translated, scriptable command or rip it out.
This limbo middle ground is just sand in the bearing grease.