Multi-Language Support for Add-Ons - Organization of GDL objects

[kieselotte]

Hi there,

I'm exploring solutions for managing multiple languages in an add-on and would appreciate your insights. Currently, we use separate resource files for each language to handle simple strings, which works well. However, I'm encountering challenges with organizing GDL objects.

In our add-on, GDL scripts are embedded in .xml files. These files define elements whose values change based on the selected language. Each .xml script contains all translations for each term, and these scripts are then processed into .gsm files to form the final GDL objects.

This approach seems inefficient. I would prefer to maintain separate .xml/.gsm files for each language, using a single template .xml to generate all language-specific .xml files. How can I organize the .gsm files so that the correct version is selected based on the user's language preference?

Thank you for your help!

[Jochen Suehlo]

Hi Kiselotte,

This is not an easy topic.
I can share the following experiences regarding the multilingualism of GDL objects:
1. if you work with VALUES lists as strings, you will get problems if you switch to another language "on the fly", because then all (or almost all) string parameters are reset to the default value of the respective language. You are, so to speak, destroying the settings when changing the language.
Solution: Work exclusively with INT parameters and VALUES{2} commands.
2. for all parameters with movable hotspots, you will see the parameter identifiers in the language displayed there when editing in the project; you cannot change these.
Solution: work with 1 separate object per language, in which the parameter names are translated manually. Use a common main macro for all languages.
3. you can change the language when editing, but I think this is neither useful nor practical.
I have done this with some objects, but I am not happy with it.
4. currently I do it as follows. I use a language macro in which all texts to be translated are stored in dictionaries in each language. (This can also be done with one macro per language). The main object calls the macro and only reads the dictionary with the desired language.
5 There are several ways for the object to recognise which language version it has to load. One variant that I use is the use of bitmap files with the name "en.jpg" and "de.jpg" etc. Only one of the JPGs may be in the loaded library at any one time. The object then uses APPLICATION_QUERY to read which image file is available and sets itself to the corresponding language.
Another option is probably to query the Archicad version. And a third possibility is to use a macro object in which the language is defined and passed to the main object via Returned_Parameters.
6) Graphisoft has already implemented a function for future Archicad versions, which is not yet running, but is probably related to the localisation of objects (as far as I remember).

[Peter Baksa · Accepted solution]

Hi,

this technique https://gdl.graphisoft.com/tips-and-tricks/how-to-replace-parameter-values-in-xml-format can be used to set parameter default values during build.

[Piotr Dobrowolski]

Regarding GDL objects, I am doing multilanguage in MVO, You can check how it works in VELUX library avaliable on Bimobject.

The whole magic is in series of csv files, they are loaded to arrays (1 dim) when language is changed in MVO object, then the objects load the parameters via libraryglobal command. There are some safety catches to fill the arrays with ENG strings if error happens. All strings are used then as parts of the array parameters, some for constants in materscript, some in ui script.

[kieselotte]

Thanks a lot!