SUMaterial GetNameLegacyBehavior

This is very needed for Live SketchUp model. I have to use exactly same name of a material as user sees on the screen in SketchUp UI.

Unfortunately none of the C API functions return in localized SU versions a correct display_name of a material, in case of materials coming straight from the SketchUp built-in library.

The whole mess with material.name and material.display_name is just creating more trouble for us developers.

It was really a problem with old C++ SDK and also is with the new C SDK, because they cannot get same translated material name. We are forced to go back then to Ruby model and find that material by .name and then get .display_name from it. It is very slow when a number of materials grow.

I understand that it is easier to supply same mat files for all localized SU versions. Couldn’t SketchUp 2020 just give both name and display name same full unicode name when a built-in material is added to a model, instead of “[Asphalt]” in name and “Something Black in a different language” in display name?

I guess SU Team wanted their models using default materials to “translate” nicely to other languages, but is it really that necessary?

I must say, it looks like even Thomas is not aware what square brackets are for in the material.name :slight_smile:

Even the name of the function is wrong. It should be GetDisplayName() and return a translated name using internal language handler. It is not there just to remove the square brackets.

If SU was to store only one translation in the Live model, it would then need to translate back on every Save…

can you not do a lookup on the Material.strings file for the current language?

john

1 Like

can you not do a lookup on the Material.strings file for the current language?

I was doing it in the past, but I felt it was more like a hack not a real solution.
I guess I will have to do it again.

Could we have GetDisplayName() function at least for the live version? It could return same string as GetNameLegacyBehavior() in the standalone.

For live C API I think that make sense. For non-live it is troublesome, because it’d be used within a different application who’s language we wouldn’t know anything about.

Can you log this in the issue tracker?

I’m not following you here… I’m aware of the [] naming convention.

I got this impression from this post:


which contains an excerpt from your blog. I didn’t notice it was from 2017 though. My bad.
You haven’t explained there that [MyMayerial] can be displayed for example as “MeinMaterial” in German localized version.

Ok. I will.

Ah, yes - that was an omission in the explanation.