Internationalization support for services

[bell...@gmail.com]

I’ve got several services that ‘publish’ data. Is there a way that they could leverage the getText internationalization functionality that is available to skins? Or at the very least look up ‘default’ labels for WeeWX observations/fields?

Thanks. rich

[Tom Keffer]

I'm not sure what you mean by "publish". Using Cheetah? Or, MQTT?

If Cheetah, that's discussed in the section How to internationalize a skin. 

If MQTT, it would not be simple. The $gettext() implementation is fairly tightly integrated with the Cheetah generator.

On Fri, May 29, 2026 at 1:46 PM bell...@gmail.com <bell...@gmail.com> wrote:

I’ve got several services that ‘publish’ data. Is there a way that they could leverage the getText internationalization functionality that is available to skins? Or at the very least look up ‘default’ labels for WeeWX observations/fields?

Thanks. rich

--
You received this message because you are subscribed to the Google Groups "weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to weewx-developm...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/weewx-development/516a1de7-aba7-4ba3-80ee-820884d9ee37n%40googlegroups.com.

[Greg Troxel]

Tom Keffer <tke...@gmail.com> writes:

> If MQTT, it would not be simple. The $gettext() implementation is fairly
> tightly integrated with the Cheetah generator.

MQTT avoids defining semantics for topic names or contents. I
personally view it as akin to RPC or some other network protocol, and
would expect tokens rather than names in a natural language -- and hence
no i18n.

As an example with Home Assistant, there might be a topic ending in
/pressure_hPa with a number in it. The receiver would match on that in
a configured MQTT entity, and it would be up to Home Assistant to
translate pressure or units.

[bell...@gmail.com]

Tom,

Thanks. That is what I thought .

I have services (bound to  new loop packet and/or new archive record events) that ‘publish’ (via MQTT and other  protocols) to various external systems. I guess for now I will continue to have a configuration option for a ‘human readable name’ for each of these.

Thanks  for your great support and for WeeWX proper.

rich

[bell...@gmail.com]

Hmm… Interesting. I am just beginning to  experiment with Home Assistant and its “MQTT auto discovery”. So for example I am publishing extraTemp1 and I want to name it something like ‘shed temperature’ in Home Assistant (and other ‘places’ , like pushover).  Both seem to expect the ‘publisher’ to ‘translate’ the token to a human readable name ….

rich

[Greg Troxel]

"bell...@gmail.com" <bell...@gmail.com> writes:

> Hmm… Interesting. I am just beginning to experiment with Home Assistant
> and its “MQTT auto discovery”. So for example I am publishing extraTemp1
> and I want to name it something like ‘shed temperature’ in Home Assistant
> (and other ‘places’ , like pushover). Both seem to expect the ‘publisher’
> to ‘translate’ the token to a human readable name ….

Probably you are right about what HA is doing. I'm not using
autodiscovery for weewx output and I have manual sensor definitions. I
see my topic names as like variables in a programming language.

I guess the real point is that MQTT is just a way to pass key/value
pairs, and that anyone using MQTT has to write (or pretend they wrote) a
protocol spec that says what the words mean.

While my preference is to treat MQTT like RPC with variable names, I
guess I'd have to look into the rest of home assistant to see how i18n
of automatic entities is handled, including zwave2js.

With autodiscovery, I don't think you have to translate the topics, but
to provide entity names to go along with them. Autodiscovery is really
pushing parts of HA config out to the mqtt publisher, but it's still
semantically HA config.

With any luck we have someone who is not a native en_US speaker who uses
HA to tell us how i18n works or doesn't work in practice. The trouble
with en_US is that good i18n and bad i18n look the same...

[bell...@gmail.com]

I don’t think it is unreasonable to expect Home Assistant and PushOver to receive the human readable text. If I was designing an UI, I would have it ask for data and the language for the human readable text. But I am pushing data to these services, so they really can’t ask for a language....

What ‘bothers me’ is that each WeeWX extension replicates the data that extraTemp1 maps to ‘shed temperature’ (never mind translation). I’ll probably end up with another configuration section, [bellrichm-labels] that all my extensions can use....

[Greg Troxel]

"bell...@gmail.com" <bell...@gmail.com> writes:

> I don’t think it is unreasonable to expect Home Assistant and PushOver to
> receive the human readable text. If I was designing an UI, I would have it
> ask for data and the language for the human readable text. But I am pushing
> data to these services, so they really can’t ask for a language....

Except that with HA, there could be multiple users who have different
language settings.

> What ‘bothers me’ is that each WeeWX extension replicates the data that
> extraTemp1 maps to ‘shed temperature’ (never mind translation). I’ll
> probably end up with another configuration section, [bellrichm-labels] that
> all my extensions can use....

I think you are arriving at needing a translation layer from extraTemp1
to something meaningful, sort of after coming out of the db and before
being seen by the data consumers. Either that or mapping it on write to
the db and changing the column name.

[bell...@gmail.com]

Silly me. It’s already there in defaults.py and [StdReport][[Defaults]]. I just need to look in a different configuration section than my own section.

[bell...@gmail.com]

I’ve only been experimenting with HA for about a week (and that time has been spent developing a MQTT proof of concept), so my knowledge is essentially zero.

Does HA even support: for a given sensor, setting its ‘name’ to different values for multiple languages?

I’m ok with only publishing a single language to HA. Unlike a public website, how many HA instances support multiple languages? My other extensions primarily send out notifications, which I am also ok with only supporting one language...

[Greg Troxel]

"bell...@gmail.com" <bell...@gmail.com> writes:

> I’ve only been experimenting with HA for about a week (and that time has
> been spent developing a MQTT proof of concept), so my knowledge is
> essentially zero.
>
> Does HA even support: for a given sensor, setting its ‘name’ to different
> values for multiple languages?

I really don't know. I speak en_US so I have not really learned that
much about i18n. I was just commenting from an architectural viewpoint,
that i18n belongs in presentation to humans, where weewx sending data to
HA is machine-to-machine. I realize the world is messy and don't mean
to suggest/demand you push wet noodles uphill.

> I’m ok with only publishing a single language to HA. Unlike a public
> website, how many HA instances support multiple languages? My other
> extensions primarily send out notifications, which I am also ok with only
> supporting one language...

I looked at mine, and apparently you can change the locale for the
instance, vs per user. I switched mine to Francais, but didn't see
anything change. So my comments about HA are off.


But I still think it's a not-yet-feature for it to be per user. Just
like multiple users on a computer can have different LANG settings.

I can totally understand how you want to send presentation names in mqtt
to deal with the real world, as it exists today. I just wanted to
express that I see MQTT as machine-to-machine, vs system-to-human. I
expect it will take a long time for this to settle out.

[bell...@gmail.com]

I agree with what you are saying. I appreciate the dialog.

My background comes from where the UI asks the ‘backend’ for data for a certain locale. What is interesting is that with MQTT we are pushing the information... Yeah, we really are mucking with a machine-to-machine protocol. Probably trying to force fit something that doesn’t fit. But, yeah, I am just trying to ‘fit into the existing world’.

If I got to the point where I needed to support multiple locales, I could ‘fish around” in the WeeWX lang dirs. I already have a skin that does that to support multiple locales.

[John Smith]

I just did a quick search for "home assistant custom integration localisation" and got this link back

https://mantikor.github.io/developers/internationalization/custom_component_localization/

I agree with Greg, this belongs in HA, not MQTT, and it looks like it can easily be done in HA

--
You received this message because you are subscribed to the Google Groups "weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to weewx-developm...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/weewx-development/111b931c-79f2-4ecf-b6cd-fd2de55c4ee5n%40googlegroups.com.

[bell...@gmail.com]

Good information. Thanks.  

I do see the benefit (convenience) of pushing a human readable name when pushing configuration information from a device to HA.

[John Smith]

SQL is only English like and that would be analogous to M2M protocols like MQTT.

To view this discussion visit https://groups.google.com/d/msgid/weewx-development/4271a924-b350-403e-bfd4-bf46b54568b1n%40googlegroups.com.

[bell...@gmail.com]

We will just disagree on this. For me, if server-1 has information that server-2 needs, and the only automated way to get the data from server-1 to server-2 is via MQTT; I will use MQTT.

[John Smith]

Yes, SQL is the same, but SQL doesn't usually contain the variable names in a plain English or any other language for the end user, the website presenting the data does that.

To view this discussion visit https://groups.google.com/d/msgid/weewx-development/f5c597d0-e883-46cb-b929-01efb7bd69f0n%40googlegroups.com.