Translation for LabelUtils.GetLabelForSpec()

[Aminius]

Hi,

we use LabelUtils.GetLabelForSpec() to translate parameter types. The returned string is always in the current UI language, which is inconvenient for us as we use it (amongst other things) for writing to a config file which should be language-agnostic.

Is there a way to always get the english label?

Thanks

Michael

[jeremy_tammik]

I also highly recommend making your add-in language agnostic. Why do you want to use a language at all? Can't you store the information you require completely without language specific information and labels? What exact information do you need to store?

[Aminius]

Hi Jeremy,

thanks for the answer.

We synchronize Property/Attribute data, and since we don't have the exact same data types as Revit (or the amount), there is a mapping. We allow the user to change the target type if needed, to allow for data conversion. These settings are stored in a config file because, usually, the synchronisation is repeated several times as projects progress, and by storing the config, this has to be set up only once.

Sure, it isn't the most elegant way to store the string representation, but I guess storing actual enum values would be even worse as those are an implementation detail.

Previously, we have used Autodesk.Revit.DB.ParameterType.ToString(), which was always in english.

I guess I could just copy the strings of the relevant data types and put them in our own mapping table, I just thought it might be done more elegantly.

It surprises me a bit that the LabelUtils do not support (manual) locale settings.

[jeremy_tammik]

Thank you for the explanation. Yes, the Revit API frequently surprises me a bit too.

[Aminius]

Good morning,

so, the conclusion is that there is currently no way to get a specific language label via the API?

[jeremy_tammik]

I asked the devteam for you...

[Aminius]

Is there any news on this topic (I can't access the slack channel)?

Otherwise, I will just use my own string list, no big problem...

[jeremy_tammik]

Yes, you cannot access that slack thread, it is internal, for my own reference.

No news yet; I re-prompted the development team for you...

[jeremy_tammik]

The development team answers:

From the customer's post, it seems that they would like to use the label of the spec ID as an identifier in the configuration file. Why not just use the ForgeTypeId.TypeId string, which, as I understand, is the unique string to the Forge Schema ID of the spec?

[Aminius]

Hi Jeremy,

thanks for your troubles!

I have some reservations about using the TypeId, which looks like this:

autodesk.spec.aec:string-2.0.0

It seems to include version information, but even if I'm wrong on that assumption, the way this internal ID looks like is clearly an implementation detail which I wouldn't like to rely on when persisting stuff.

Also, our config file should be compatible with ones written by older versions of the plugins (running on top of older versions of Revit, obviously), where the ForgeTypeId did not exist.

So I would have to do an internal mapping anyway.

The longer I think about it, the more I'm convinced that I should just define my own set of identifiers, named according to the old ParameterType.

It won't be a big problem, I was just thinking that there might be a more elegant way.

So I thank you for your troubles and I accept as a solution that I must build my own solution. 🙂

One final remark: There is another reason why I think you should make auto-translation of labels optional: Our plugin is currently not translated anyway, it's always in english. So translating data types, while a nice idea in theory, actually doesn't match the environment in this case.

Cheers

Aminius

[david_becroft]

Fun fact, just for the record: The default comparison behavior for ForgeTypeId objects ignores the version number at the end of the string. We do consider the difference between e.g. "length-1.0.0" and "length-1.0.1" to be an implementation detail, and we expect Revit customers typically only care about the difference between e.g. "length" and "mass". So a ForgeTypeId containing "length-1.0.0" would compare equally to a ForgeTypeId containing "length-1.0.1", but not to one containing "mass-1.0.0".

Aminius, you mentioned supporting multiple versions of Revit. Yes, that is a challenge, because new versions may introduce new "specs" (i.e. parameter data types). Other friendly folks in the community have given us good feedback about how to make it easier to build addins supporting multiple Revit versions. I want to mention that even update releases, e.g. Revit 2022.1, may introduce new specs. The SpecUtils.GetAllSpecs() method, introduced in Revit 2022, enumerates all the available specs. In Revit 2021, see UnitUtils.GetAllSpecs() for measurable data types only.