SUMaterial GetNameLegacyBehavior

[Tomasz]

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

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.

[john_drivenupthewall]

@Tomasz

just give both name and display name same full unicode name

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

[Tomasz]

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.

[tt_su]

@Tomasz

Could we have GetDisplayName() function at least for the live version?

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?

Issues · SketchUp/api-issue-tracker

[tt_su]

@Tomasz

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

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

[Tomasz]

I got this impression from this post:

Material name vs display_name

ThomThom said Speaking of Names… The Material class has two seemingly similar methods, #name and #display_name. The documentation says that #display_name is preferred, but doesn’t explain why. The difference is that if a material name is wrapped in square brackets, like “[MyMayerial]”, then #name will return “[MyMayerial]” and display_name will return “MyMayerial”. The latter is how SketchUp will display the material name in the UI, while #name returns the real name. If you refer to a mater…

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.

@tt_su

Can you log this in the issue tracker?

Ok. I will.

SUMaterialGetDisplayName()

[tt_su]

@Tomasz

You haven’t explained there that [MyMayerial] can be displayed for example as “MeinMaterial” in German localized version.

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