How to know localization of archicad through gdl

[Anonymous]

Hi,

I was looking through some objects, where the materials of the geometries were defined using strings, e.g. "Metal - Stainless Steel" instead of using the index 11. The problem I encountered was that for a different localization of archicad, the material had a different name (the index remained the same). This caused the object to be rendered using the default color (green for me), since it couldn't find the specified material.

My question is,
can I somehow obtain the localization and version of the current archicad version using gdl?

I know the solution to the problem I described would simply be to change the material parameter to be of material type instead of string, and use the index of the material. I'm simply curious as to if there is any way to know the localization.

blob

[runxel · Accepted solution]

While you can request the GDL version (which relates to the Archicad version) via

REQ("GDL_Version")

it's not possible to retrieve the current running language afaik.

Archicad is sadly not able to hotswap languages (not even "coldswap" – you have to install a complete new Archicad) that's why I assume requesting the language doesn't make so much sense.
Most vendors including Graphisoft just give you already localized versions of their objects (you can't swap languages, remember? so why give the possibility; the user knows what language he uses), while a few just let the user decide via a drop-down option inside the object (or the MVO, since you can make your own section there).

[Anonymous]

Hi runxel,
thank you for your reply.

I had also found the command you mentioned in the documentation, and I wondered if there was something similar but for the localization. However, if there is none, then that is that. I'll mark your reply as the solution in case anyone in the future wonders about the same thing.

[Piotr Dobrowolski]

Id does make sense - say preparing the multilanguage library for the manufacturer of something.
The library could find out what language is used and select proper language (and give opportunity to select different if needed)

I dod not test - but on some macros for doors/windows in the standard lib - there are put language codes - as not user-visible parameter...maybe calling such file could return the value of the parameter...

Piotr

[runxel]

Piotr wrote:
Id does make sense - say preparing the multilanguage library for the manufacturer of something.

Oh yes, sure! It actually makes a lot of sense nowadays! 🙂
But seemingly not for Graphisoft, otherwise they would have made such a command 😉
(I mean, one library to rule them all is a demand we as community already have for years, if not even decades.)

[runxel]

runxel wrote:
it's not possible to retrieve the current running language

Okay, so listen: Great news! I was wrong.
I think I now found a solution to your enquiry.
Might looking a bit hacky, but it works nonetheless.

This solution is based on the fact that the user most probably will have loaded the default Archicad library.
At the root of the provided library is an XML file called ARCHICAD Library.version

It looks more or less like this:

<productversion>
  <buildnumber>2800</buildnumber>
  <projectbuildnumber>4010</projectbuildnumber>
  <codename>v2019</codename>
  <versionstring>23.0.0</versionstring>
  <shortversionstring>23</shortversionstring>
  <platform>MAC32</platform>
  <gslanguage>GER</gslanguage>
  <gsprodtype>FULL</gsprodtype>
  <prefspostfix>v2019 GER 2800.4010</prefspostfix>
  <guid>{6108D34D-A54F-49CE-A83C-9B805F956D74}</guid>
  <supersedes-lib name="BIBLIOTHEKEN 13" guid="{09C93C26-1CA0-11DF-B83D-B3B556D89593}"/>
  <supersedes-lib name="BIBLIOTHEKEN 14" guid="{988B0D68-1BEC-11DF-BC14-569455D89593}"/>
  <supersedes-lib name="BIBLIOTHEKEN 15" guid="{B559A49C-53AC-11E0-892A-2609DFD72085}"/>
  <supersedes-lib name="BIBLIOTHEKEN 16" guid="{736BF948-34A6-460F-8BE2-80AF101776B5}"/>
  <supersedes-lib name="BIBLIOTHEKEN 17" guid="{2DDCC60A-4E34-4DCC-8A21-C099C89DC870}"/>
  <supersedes-lib name="BIBLIOTHEKEN 18" guid="{BECC7064-F02C-4F35-91D0-613E6BD8D5DA}"/>
  <supersedes-lib name="BIBLIOTHEKEN 19" guid="{882FD682-7057-4C18-A761-40544EB588AD}"/>
  <supersedes-lib name="BIBLIOTHEKEN 20" guid="{FF6B2803-AC38-48C2-ABD6-6D56DD453444}"/>
  <supersedes-lib name="BIBLIOTHEKEN 21" guid="{7A18EB31-3044-4E99-8F54-B6CB16B6CE88}"/>
  <supersedes-lib name="BIBLIOTHEKEN 22" guid="{C46B01B7-097F-4F18-9B3D-71413F211E37}"/>
  <collapse-branches/>
</productversion>

What's interesting here is the 'gslanguage' part: since users can't (and mostly never even attempt) to load a library not in their native language, we can utilize that to see what language the user expects.

GDL has the XML Addon which will help to traverse this XML:
(It took me about an hour to figure out how this is actually supposed to work... – the GDL warnings are useless as always.)

See this for an explanation

In the end it is rather simple: Basically just four SLOC:
(Heavily annotated so you can figure out whats happening)

!  [MASTERSCRIPT]
! declare all the variables we need
_dummy = "" ! only there so it can be ignored…
pos   = ""
nodename  = ""
nodevalue = ""
nodetype  = ""
err   = ""
errex = ""


! first we need to open the file
!< `ch` stands for 'channel'
ch = OPEN ('xml', 'ARCHICAD Library.version', 'rl')
!    |       |     └ the file name             |└ Locally loaded
!    |       └ add-on type                     └ Read-only
!    └ open command: the file we want to read


! returns new position descriptor (i.e. root of the xml)  <= pos
r = INPUT (ch, "NewPositionDesc", _dummy, pos)
!           |   └ command to exec |       └ 'pos' stores the position from which we read
!           |                     └ gets ignored, but must be set
!           └ channel we want to read

! now lets move into the tree
! lets find the "gslanguage" node first
rr = INPUT (ch, "MoveToNode FromFirstChild g* ELEM 1", pos, nodename, nodevalue, nodetype)
!                |                                     |    |         |          └ will be "ELEM"
!                |                                     |    |         └ value will be empty at this time!
!                |                                     |    └ nodename will output "gslanguage"
!                |                                     └ input the position from which we want to start
!                |                                       / BUT also changes/mutates the position of the descriptor!
!                └ This command means:
!                  / Move to a node
!                  / starting at the first child node from the current 'pos'-node
!                  / now get the _first_ "ELEM" (element)
!                  / which starts with "g"

! We still didn't got the actual value
!  ("nodevalue" was empty, because at this point we don't know what's inside, we just moved to the node)
rrr = INPUT (ch, "MoveToNode FromFirstChild * TXT", pos, nodename, nodevalue, nodetype)
! basically the same as above, but this time we want the TXT (text) of the node
! we can omit the "1", because that's the default anyway

! you can use 'GetLastError' after every 'INPUT' command and see, what's wrong
e = INPUT (ch, "GetLastError", _dummy, err, errex)
!                              |       |    └ error message (textual explanation)
!                              |       └ errorcode, =0 if ok
!                              └ gets ignored, but must be set


! close the channel (i.e. the file):
CLOSE ch

All this stuff is needed, because GDL as BASIC based language can't really work well with structured markup like XML. If you would need more data, you would work with loops.
An example of that can be found here.

I hope that helps!

[Anonymous]

Very clever solution Runxel!
That is a real outside the box solution.