German vs. Englisch Interface

[Anonymous]

Hi Folks,

Maybe someone can come up with a good explaination for the following question:

What happens if you open the same IFC file with the same Computer, with the same IFC import settings with the same Revit Version but just with another Interface language (german, english)? 

Correct the germans are more efficent in cost optimisation and are more advanced when it comes to inovative construction methodes. So the walls are only half the height and the ceilings are hoovering in the air, held in place with "Siemens Lufthacken!".

Okay seriously can we have an explaination for this?

[jeremytammik]

You may also want to raise this issue in the open source IFC discussion forum:

https://sourceforge.net/p/ifcexporter/discussion/general

That's where the experts in this area tend to congregate...

[RPTHOMAS108]

Probably there are a number of numbers represented in the text with a comma instead of a dot then parsed incorrectly back i.e. culture invariant not used. German's do like to put a comma where a dot should be.

According to the following list there are more countries using comma 76 vs 59. I'm still a large supporter of the dot considering the use of comma as a thousand separator.

https://en.wikipedia.org/wiki/Decimal_separator

[jeremytammik]

The Building Coder recently mentioned this Decimal Point Woe:

https://thebuildingcoder.typepad.com/blog/2020/09/optimising-parameters-and-full-text-search.html#4

[Anonymous]

No I checked:

The line in question would be:
#36491= IFCPROPERTYSINGLEVALUE('Nicht verkn\X2\00FC\X0\pfte H\X2\00F6\X0\he',$,IFCREAL(2.66),$);

Also Units are defined at the beginning:

#12= IFCSIUNIT(*,.LENGTHUNIT.,$,.METRE.);
#13= IFCSIUNIT(*,.LENGTHUNIT.,.MILLI.,.METRE.);
#14= IFCSIUNIT(*,.AREAUNIT.,.MILLI.,.SQUARE_METRE.);
#15= IFCSIUNIT(*,.VOLUMEUNIT.,.MILLI.,.CUBIC_METRE.);
#16= IFCSIUNIT(*,.PLANEANGLEUNIT.,$,.RADIAN.);

[jeremytammik]

Sensible IFC and STEP format to require decimal points.

[RPTHOMAS108]

I'm not an IFC expert but IFC to me is just a model represented in text that needs to be parsed. So it is logical if one culture is used to persist the data as text and the other used to parse it then such issues may arise.

There may also be issues with how parameters and categories are accessed i.e. UI categories/parameters have different names in different cultures whilst their equivalent built-in categories/built-in parameter Enum values are culture invariant.  I think @jeremytammik's answer is the best answer.

Not much to be done apart from report it to those that maintain it.