Graphs using Element.GetParameterValueByName break as soon as they run on a Revit in another language, because parameter display names are localized (“Mark” vs “Identifiant” vs “Bezeichnung”…).
I’ve just posted a complete proposal on a long-standing GitHub issue (open since 2014!): a single native node converting a stable BuiltInParameter enum name (e.g. ALL_MODEL_MARK) into the localized display name of the running session, via LabelUtils.GetLabelFor(). Full behavior spec, working PythonNet3/CPython3 reference code and before/after screenshots included:
https://github.com/DynamoDS/DynamoRevit/issues/2188
If you share graphs across languages or offices and want this natively, please add a 
on the GitHub issue — reactions are what the Dynamo team looks at for prioritization.
Background articles (French): [Blog BIP]
Great work and thanks for the detailed description. Not sure the Revit team has bandwidth for new nodes where there are established work-arounds, but I’m sure they’ll take a look even without people voting on it (mostly as I’ve surfaced it accordingly).
One thing to note, is that in a previous engagement with a custom effort for a customer we asked a very talented French speaking Revit user to type what they thought the built in parameter name for 5 parameters was. They went 0/3 before we realized how far off they were and decided that user inputs like this would be rather restrictive to all but multi-lingual API experts which was too narrow a subset of users.
At the time our proposed alternative was to build a custom ‘double dropdown’ node. The first dropdown was the list of localizations Revit provides, and the second was the list of parameter names from the given localization. The output of the node would be the parameter, at which point you’re into an existing Dynamo workflow so no further work would be needed. In a perfect world that first dropdown could even pre-populate with the user’s current localization. Sadly the work was more than I had time for (new nodes wasn’t the purpose of the engagement after all) and we just hard coded accessing the parameters via Python instead.
Thanks a lot Jacob — for the kind words, and I’m impressed by how quickly you picked this up and surfaced it to the team. That 's really appreciated.
Your 0/3 anecdote rings very true: nobody guesses ALL_MODEL_MARK from memory, and I’d never expect users to type BIP names by heart. That’s actually why the article ships with a full lookup table (all BuiltInParameters with their French display names, verified programmatically against the Revit 2027 API via LabelUtils - nearly 4,000 BIPs to go through, thank you Dynamo and AI for the heavy lifting!). The graph author looks the name up once in the file, and the graph then runs on any localization.
On the double-dropdown idea: I really like it for interactive discovery, and I’d see the two approaches as covering different sides of the same problem, with a few nuances. Since a dropdown has no input port, it isn’t meant for data-driven workflows - processing a list of parameters at once, mappings coming from Excel, or graphs whose intent stays readable as plain text when shared across offices. A text-input node covers exactly that side.
Either way, glad the topic is in front of the team.Thanks again for the swift follow-up.
