Behind the scenes the actual commands will probably be the same, but the issue will be that it cannot find the English version of the parameter which changes dependent on the language used.
Therefore if you look at that python code it will be the parameter names(line 63 in your image) for what is required, EG “Name” will be something different for each language as it is translated for each localized version.
In that case there’d be no solution unless we have something like a “parameter translation” node in dynamo to put in or in advance to the lunchbox custom node.
To leave something for other’s reference, I figured the alternative is to use character-based nodes to select the parameter of the specified category, depending on what you are looking for, and then build the dynamo files in terms of different languages.
as you already found out lunchbox is a set of custom nodes.
if you examine the node - especially the python code implemented - you will find out, that BuiltInParameters are addressed using their localized names.
if you want to adopt these nodes for more generalized usability you just have to exchange those parameternames with the BuiltInNames. they usually start with OST_
after that the code is usable even in non english enviroments.
to find out the real names just install the buildingcoders Lookup tool. with it you easily retrieve the real names for BuiltInParameters.
one thing more to consider in the python code from 2016 : reading / writing parameters uses element.LookupParameter(“string”) as command during BuiltInParameters are addressed with element.get_Parameter(BuiltInParameter)