I wanted to add something to an external integration that should be based on the language configured in Gladys to create the features in the right language, but Claude returned this to me:
Now I have what I need. The host API gives an integration no way to read the user’s language (only linkContact/getContacts carry one, and that’s messaging-only)
Is it possible to expose the user’s language so that the features are created in the right language?
Thanks for the suggestion, I understand the need, but I’m reserved about the idea of exposing the user’s language globally.
The issue is that in Gladys, the language is not a property of the instance, it’s a property of each user. On a single instance, you can very well have a household with users who speak different languages. An API that returns a single language would have to choose one arbitrarily, and it would inevitably be wrong for some users.
In practice, depending on the use case, everything is already covered today:
If your integration sends a message to a user, their language is already available via GET /contact and linkContact. There, we know exactly who we’re addressing, so it’s the right place.
If it’s interface content (labels, config), the manifest already handles multilingualism: the labels and descriptions of fields are multilingual texts, and it’s the front end that displays the correct version according to the connected user.
And for your pollen case, where you generate text without a specific recipient, you can simply add a select field « Language » in the config_schema of your manifest, with a default value. The user chooses their language during installation, and your integration reads this value in its config. In my opinion, this is more accurate than a language imposed by the core: it’s an integration setting, explicitly chosen by the person who configures it.
So no need for evolution on the Gladys side for your need, you can already do everything with the existing features.
Don’t hesitate if you need a hand with the manifest
