I need to localize my Dynamo graphs so that they will work across multiple languages. I only have the English Revit version installed so its a bit hard for me to test, but what are the issues I need to look out for?
I assume the builtin category enumeration and builtin parameter enumeration is fixed and will work across any language.
So in the case of categories, I assume it is a simple fix like this…
And for an element’s parameter, like this… I’m using Archilab here as the OOTB nodes don’t seem to work with BIP. Is this the only way or are there an OOTB nodes that I’ve missed?
Any other potential issues?
@JacobSmall @solamour any guidance how how to achieve this?
Step 1: install the other language, ideally on a VM so you can test stuff like the paths to localized resources like file templates and number formatting changes as well.
Step 2: Find someone who ideally knows a little bit of Dynamo, but absolutely knows the language you are localizing to and the type of work your graphs are built for. Otherwise you’ll guess at a translation or utilize an online translator and get it wrong. I’ve personally done this well enough that the customer had to ask ‘where did you get that name as it makes no sense’ and my response was ‘a mix of google and friend who speaks Swedish’ to which they replied ‘but they don’t work in AEC huh… we use this phrase for that.’
Step 3: Save time to test everything after localization. Ideally in an automated way. Look into the tools for such automations on the Dynamo GitHub repo.
Step 4; Be prepared to either do a ‘save as’ and ship two versions of the .dyn file, keeping them in separate but mirrored folders, or with a suffix/prefix to the name. Many of the methods that are needed to work in both languages take 4x the work to use and are 1/2 as effective as modifying the graph for the other language. Doubly so when you take Revit version changes into account. You’re either writing a lot of custom code (ie: all UI becomes custom as Dynamo Player doesn’t allow for localization of input names, tooltips, etc.) or just building once and then doing the save as.
Note that when you look at localization of other tools the code base usually grows significantly. For a recent Revit add-in we won’t from one class with 300 lines of code quickly balloons to one class with 500 lines of code and five new support files to add another language. We actually had to more than double the data storage for the project as a result, so if file size is the metric (it isn’t a good one) the localization was more than 1/2 of the effort. The key to simplified automations is standardization, and localization is a surprisingly common part of that.
@jacob.small thanks for this. But I was hoping to keep it simple.
I don’t need everything to be in the localiased language. The main thing is that Dynamo runs successfully on Revit versions other than English. The input titles would still be in English, and most of the parameter values are exposed so they can change if from “Number” to “Numero” or whatever.
But there are few instances where these parameter values and category names are hard coded. Are you saying that Built in parameters/categories in English won’t work on other languages? If they can work, is it as easy as using the Archilab examples above. If not, is it better to use try and use category IDs instead of names for example? Not sure if/how that works for parameters.
Sometimes. Sometimes not. Depending on what you are doing, the results will vary and like Schrödinger’s cat you won’t know until you are in their environment. ‘It works in Spanish Revit if you have US system settings, and EU system settings for English, but fails in Spanish if you have EU system settings’ is a conversation I have had.
In my experience once you make it work in localized version the instant response in the next call is “So why do we type ‘Ceiling Height’ for the parameter name here instead of ‘takhöjd’, I thought we made this work in Swedish too.” Then you get to start fighting a battle you can’t win.
And so the only answer is: set up a VM that matches the customer environment and test there, as you can’t know it works until you try.
1 Like
Hi @Paul_Wintour, some thoughts as follow beyond Jacobs.
From Dynamo 2.18, you can select your language in Dynamo’s Preferences, so pending the version you are in this could help. It’s also testable(ish) in Sandbox if you want to do basic tests without Revit - i.e. not actually running the graph, but seeing how it looks, or utilizing a Remember node.
With regards to this, Jacob has more direct experience than I do. What I can add is how we handle localization inside of Dynamo itself, which is a lot of hidden effort by another team entirely. We essentially have mapping files that showcase what a thing is in English versus what that thing is in Language Two to switch out strings on the fly.
So my question to you would be: Are you trying to make a graph that supports particular languages? Or are you trying to make a graph that works on any language?
If the former, it’s easier to control, and if the latter you need some strong baseline systems to approach it, and as @jacob.small enumerates above you really will need to test this across a smattering of other languages.
Technically, the Revit API is written in English, as is the Dynamo API. The UI get’s localized. The tricky thing is how the UI pipes information into those API’s - so in the case of a Spanish parameter of Mark you’ll be using that Spanish term for Mark. You can get around this with things like BuiltInParameters to a point, but the trick is the actual interfacing of those terms and how to handle that.
To add to this I’ve assisted some firms using more than one language in the past and we just ended up going with 1 script implementation per language, where their BIM team assisted with ironing out/translating the hard coded words/terms needed. Generally teams in multi-lingual scenarios tend to silo off into groups that work together with their own tools/setup in my xp vs mix their tools/templates together.
This is one of the pitfalls of selling scripting as a service I think, you can only support it so far before you build up too much tech debt to support at scale (e.g. scripts per language, so many of them!) or the scripts become jankier than they’re worth as ‘products’. My assumption here is the query stems from language support for scripts as sold products. Not worth it imho if that’s the case.
2 Likes
