Request: internationalization support

[metbril]

I'd like to be able to use the component in my native language, Dutch. So it would be much appreciated if the now hardcoded strings are replaced by a way to add translations. I would be happy to contribute one or more translations.

Update: as far as I can see, this only applies to the states of the Sun Phase sensor.

[pnbruckner]

I can look into it. I've only added support for translations to the life360 integration, and then only for the config flow. I'll have to figure out how to do it other strings, assuming it's possible. Probably won't get to it for a while, though.

[metbril]

Never mind. Glad that you'll consider it for now. I can always use one or more template sensors as a workaround.
I'm patient.

template:
  - sensor:
      - name: Sun Phase Translated
        unique_id: sun_phase_translated
        icon: >-
          {{ state_attr('sensor.sun_phase','icon') }}
        state: >-
          {% set val = states('sensor.sun_phase') %}
          {% if (val == "Day") %}
            Dag
          {% elif val == "Night" %}
            Nacht
          {% elif val == "Astronomical Twilight" %}
            Astronomische schemer
          {% elif val == "Civil Twilight" %}
            Civiele schemer 
          {% elif val == "Nautical Twilight" %}
            Nautische schemer 
          {% else %}
            unknown
          {% endif %}

[metbril]

I have since updated my template sensor to this:

{% set state = states('sensor.sun_phase') %}
{% set from = ["Day", "Night", "Astronomical Twilight", "Civil Twilight", "Nautical Twilight"] %}
{% set to = ["Dag", "Nacht", "Astronomische schemer", "Civiele schemer", "Nautische schemer"] %}
{{ to[from.index(state)] if (state in from) else state }}

(and added it as a Template helper as of release 2023.9)

[pnbruckner]

@metbril, I'm giving this a try, but I can't seem to make it work. Do you know of another custom integration that supports internationalization, and if so, can you give me a pointer to it? I'd like to look at a working example so I can maybe figure out what I'm missing.

[pnbruckner]

@metbril I created a branch with the changes I thought were necessary, but they do not seem to work for me. If there's anyway you could give it a try, I'd appreciate it.

[metbril]

What exactly is your request? For me to develop the code? I don't think I have sufficient skills for that. I am prepared to do some testing and help translating. But I'm a novice coder unfortunately.

[pnbruckner]

What exactly is your request? For me to develop the code?

No, I was asking if you could try the change I committed to a branch in the repo. If you don't know how to do that, no problem. I've been asking for help on discord, although I still don't have it working.

[metbril]

If you're asking if I could install the custom component from the branch to try in my installation, that would be possible.

[pnbruckner]

I'm throwing in the towel, at least for now. I can't figure it out, AND I see the following statement in the translations docs:

Translation of entity attribute names and states also requires frontend support, which is currently only available for climate entities.

So, seems like this can't work now. If it does someday, I can try again.

[metbril]

Thanks a lot for taking that challenge. I'll wait patiently.

btw, I noticed some improvements to the internal Sun integration. This makes some of your sensors redundant.

[pnbruckner]

After some help on discord, the current theory is that since the integration does not use config_flow, the translation strings aren't getting sent to the frontend. I've been thinking about adding config_flow (for now, just import from configuration.yaml), so I'll do that, and once that is working, I'll try translations again.

[pnbruckner]

config_flow added in #93 so should be able to try translations again.

[pnbruckner]

@metbril I've got the config_flow branch to the point where I think it works, but not only that, I've included translations, which now work!!! If you'd like to install it and try it out, and especially, if you'd like to add a translation JSON file for another language and see if that works for you, I'd appreciate it. If you do create a translation JSON file for another language, when I'm done with this, merge it, and create a release, I'd appreciate a PR adding that JSON file (or you can just send it to me and I can add it.)

[metbril]

Working on that json atm.

[metbril]

I think it's easiest for me to upload the file to this issue, so you can add it to the branch yourself. See attached file.
Please let me know as soon as the branch is ready for testing.

nl.json

[pnbruckner]

@metbril thanks for the translation file! I'll add it next.

I think I'm ready to create a beta release. I.e., I think I've added all the functionality I wanted, and so far, minimal testing seems to indicate it's working ok. You can either use the branch directly (after I add nl.json), or wait for the beta release.

[pnbruckner]

Oops, didn't mean to close this.

Should "Sun" be "Zon", and "Sun2" be "Zon2"?

[metbril]

You're absolutely right. I changed that at the end but forgot to save. 😮‍💨
I also did a last check and did a consistency update.

dusk = schemer
twilight = schemering

Please find a new file with all changes.

nl.json

[pnbruckner]

@metbril FWIW, it should now be ready for testing (beta version 3.0.0b2.)

[metbril]

I updated from 2.5.x to beta b3 and restarted HA. I don't see the entities and state values localised. It looks like my YAML config is not (yet) migrated to config flow. Should I remove the YAML and re-add through the UI?

[pnbruckner]

Currently the config flow only supports YAML import. You need to move your config from:

sensor:
  - platform: sun2
    ...

to:

sun:
  - unique_id: home
    ...

per the warning message and docs. Let me know if you have any questions.

Fair warning, the entity names and IDs will be different than they were, but they're more in line with how I think the core team wants things to work. And besides, to do it differently (more like before) would require working around things in the code which I'd rather not do. That would make it too fragile.

BTW, I'm working on more translations (e.g., "Above minus N" -> "Boven min N", which is just my Google guess as to the translation. Lol!) Once I have that checked in, I wouldn't mind you looking over nl.json. And, if you don't want any of the sensors that require more options (such as time_at_elevation, etc.), once I check in the changes you can have a simple config of:

sun2:

Currently, the minimum is:

sun2:
  - unique_id: home

[metbril]

I did a minimal configuration (your last example) and now see this:

The entity names are in Dutch, too. Not just the friendly names.
There is 1 untranslated binary sensor "Above Horizon'.
Just fine for a start, but not yet equal to the release version.
Keep up the good work. I'll do some more testing.

[pnbruckner]

Just released 3.0.0b4 which should translate the names of those "non-simple" entity types (i.e., the ones whose name depends on its parameters/options.) As always, I'd appreciate any feedback on the contents of nl.json.

Thanks for testing!

Oh, and now the following is supported:

sun2:

which, as mentioned, is equivalent to:

sun2:
  - unique_id: home

[pnbruckner]

Just fine for a start, but not yet equal to the release version.

Can you elaborate on that? What do you think I'm still missing?

FWIW, I tried to translate attribute names & states as well, but when I tried, it didn't seem to completely work, so I kind of gave up. But I just recently discovered that there are TWO language settings: the system one, and the one in the user's profile page. Who knew?! 😆 I think I'll give translating the attributes a try again.

[metbril]

Can you elaborate on that? What do you think I'm still missing?

Well, at first sight I only have half of the entities compared to the release version. And I have not yet had the time to discover all options (optional config, monitored conditions etc).

Additionally, I really miss the Device config, "Thuis Zon" in my case or "Home Sun" more generally. Usually I use this to bulk rename friendly names and entity names of the child entities.

I've discovered that opening an entity > related > device info will lead the the device page which is not in de devices tab yet. That also has hidden entities that probably are those that I was missing. Nice.

And I've found an error in b4, which is raised after updating through HACS and the a "check config":

Ongeldige configuratie!
 Error importing config platform sun2: cannot import name 'val_bs_cfg' from 'custom_components.sun2.binary_sensor' (/config/custom_components/sun2/binary_sensor.py)

I've rolled back to b3 for now.

[metbril]

Regarding the JSON file. I will get that from the config flow branch and create a PR against that. OK?

[metbril]

@pnbruckner

What does that hms stand for in today_hms? hours/minutes/seconds? Something else?

And 'elevation_at' is that intended to point to a time like "elevation at 12:34" or point to a location "elevation at home"?
The translation of at differs between those.

[pnbruckner]

I'll respond to your questions tomorrow. I've been doing quite a lot of work for the next beta release (which you can see from the recent check-ins) and I have a bit more to do.

[pnbruckner]

Well, at first sight I only have half of the entities compared to the release version. And I have not yet had the time to discover all options (optional config, monitored conditions etc).

As you may already know, all the "simple" entities are created, but most of them are disabled by default. You simply need to go to Settings -> Devices & services -> Entities and enable and/or disable the sun2 entities as you prefer.

I've discovered that opening an entity > related > device info will lead the the device page which is not in de devices tab yet.

sun2 should definitely be on the Devices page.

And I've found an error in b4, which is raised after updating through HACS and the a "check config"

That is due to a flaw in the check config implementation. It seems to be partially using modules that have already been loaded (b3) and modules that have not been loaded (b4 after updating with HACS, but before restarting.) Not much I can do about that. You can work around that issue by removing sun2 from your config after updating via HACS, then checking and/or restarting. Once restarted (with b4) you should be able to re-add sun2 to your config (and, of course, restart again.) There should be no reason you can't use b4.

Regarding the JSON file. I will get that from the config flow branch and create a PR against that. OK?

Sure, but you might want to wait until I'm done implementing. There is a significant change coming in b5 which hopefully I'll release in a few days or so. It's kind of a big change. If you have suggestions in the meantime, feel free to tell me and I can modify the files on my end.

What does that hms stand for in today_hms? hours/minutes/seconds? Something else?

Yes. And in b5 it will be umt (which, I think, is the first letters to the translated words.)

And 'elevation_at' is that intended to point to a time like "elevation at 12:34" or point to a location "elevation at home"?
The translation of at differs between those.

A time.

[pnbruckner]

Released 3.0.0b5.

[pnbruckner]

Released 3.0.0b7. I think I'm done adding and adjusting how translations work. I'd appreciate your feedback.

[pnbruckner]

Just released 3.0.0b8. I decided to add UI based config flow. It really caused the translation files to get quite large. I'd really appreciate any feedback for corrections of nl.json.

[metbril]

I have not yet been able to completely check your translation but still intend to. So I'll check it one it's less busy at work and submit a PR if needed. Again thanks a lot for your effort. It was no minor effort.