Complete i18n of reporting templates

[kobuki]

I've just upgraded to WeeWx 3.9.1 from 3.7.1. No problems at all, it picked up the old config and went on running without a hitch. The new default skin is a bit better than the old one, though I'm not using it yet, for reasons outlined below.

So, I was happy to see that many labels and metrics are templated and can be defined in weewx.conf, but unfortunately not all. I would still need to edit the templates by hand to fully translate them to my own language. What is the recommended method for that? Is it possible to just add new labels and their translations and refer to them like the rest of them available in the weewx.conf sample? Like $obs.label.barometer, $obs.label.rain, etc. The section headers on the left side of the web page or the Almanac, for instance, still need translation. What is the current recommended way to translate them? Is it planned to allow a user to define them, or even arbitrary labels for use in templates, inside weewx.conf? It would be great to have something like $custom.label.xxx at least for a centralized definition.

[Thomas Keffer]

See the section Localization in the Customizing Guide.

To answer your specific question, any label that does not use a tag will have to be changed in the template. Other labels that do use a tag, such as $obs.label.barometer, are changed in weewx.conf.

-tk

On Sat, Mar 16, 2019 at 10:34 AM kobuki <nls...@gmail.com> wrote:

I've just upgraded to WeeWx 3.9.1 from 3.7.1. No problems at all, it picked up the old config and went on running without a hitch. The new default skin is a bit better than the old one, though I'm not using it yet, for reasons outlined below.

So, I was happy to see that many labels and metrics are templated and can be defined in weewx.conf, but unfortunately not all. I would still need to edit the templates by hand to fully translate them to my own language. What is the recommended method for that? Is it possible to just add new labels and their translations and refer to them like the rest of them available in the weewx.conf sample? Like $obs.label.barometer, $obs.label.rain, etc. The section headers on the left side of the web page or the Almanac, for instance, still need translation. What is the current recommended way to translate them? Is it planned to allow a user to define them, or even arbitrary labels for use in templates, inside weewx.conf? It would be great to have something like $custom.label.xxx at least for a centralized definition.

--
You received this message because you are subscribed to the Google Groups "weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[kobuki]

Alright, thanks for the answer. This is the current state - is it possible that in the future this might change and we can use custom template variables for i18n for centralized configuration? Changind each and every template by hand is tedious. Though automation is possible...

[Thomas Keffer]

Trust me, "look up" strategies using gettext() are worse. They require you to translate a bunch of labels without the context of where they are going to be used.

-tk

[nls]

Right, I get you. I've done both numerous times but I still like to do the translation in a single place in whatever simple textual format - and code updates require manual merging if that's not possible, so I tend to add my code to a local .git repo and do my stuff using git tools.

You received this message because you are subscribed to a topic in the Google Groups "weewx-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/weewx-user/R0HygGOU5N8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to weewx-user+...@googlegroups.com.

[Thomas Keffer]

Fork weewx, put your changes in a local branch, then do a merge when necessary.

Please note: WeeWX skins have been upwards compatible since their introduction in v1.5.0, now nine years ago. We don't plan anything that would change this.

Now, it's true that if the skin author introduces new features, you would have to somehow port those new features into your skin, or vice-versa.

In any case, the design decision not to use gettext() was made a long time ago, and I still feel good about it!

-tk

[nls]

"Fork weewx, put your changes in a local branch, then do a merge when necessary."

Yeah, that's one way to do that. For me the installer package is simpler, and I usually just let it overwrite my own files which I can merge from the local git repo.