Request myuplink device-points in HA system language

[astrandb]

Breaking change

Proposed change

The myUplink API can deliver lokalized data in more than a dozen languages. Probably for all relevant markets for Nibe/myUplink. This PR will request data in the configured system language in HA. If this language is not supported by myUplink API, English strings will be delivered. By using these built-in translations we can refrain from using HA translations for entity names and text sensors.

This PR needs an updated myuplink lib

Type of change

• [ ] Dependency upgrade
• [ ] Bugfix (non-breaking change which fixes an issue)
• [ ] New integration (thank you!)
• [X] New feature (which adds functionality to an existing integration)
• [ ] Deprecation (breaking change to happen in the future)
• [ ] Breaking change (fix/feature causing existing functionality to break)
• [ ] Code quality improvements to existing code or addition of tests

Additional information

• This PR fixes or closes issue: fixes #
• This PR is related to issue:
• Link to documentation pull request:

Checklist

• [X] The code change is tested and works locally.
• [X] Local tests pass. Your PR cannot be merged unless tests pass
• [X] There is no commented out code in this PR.
• [X] I have followed the development checklist
• [X] I have followed the perfect PR recommendations
• [X] The code has been formatted using Ruff (ruff format homeassistant tests)
• [ ] Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

• [ ] Documentation added/updated for www.home-assistant.io

If the code communicates with devices, web services, or third-party tools:

• [ ] The manifest file has all fields filled out correctly.
  Updated and included derived files by running: python3 -m script.hassfest.
• [ ] New or updated dependencies have been added to requirements_all.txt.
  Updated by running python3 -m script.gen_requirements_all.
• [ ] For the updated dependencies - a link to the changelog, or at minimum a diff between library versions is added to the PR description.
• [ ] Untested files have been added to .coveragerc.

To help with the load of incoming pull requests:

• [X] I have reviewed two other open pull requests in this repository.

[home-assistant[bot]]

Hey there @pajzo, mind taking a look at this pull request as it has been labeled with an integration (myuplink) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of myuplink can trigger bot actions by commenting:

• @home-assistant close Closes the pull request.
• @home-assistant rename Awesome new title Renames the pull request.
• @home-assistant reopen Reopen the pull request.
• @home-assistant unassign myuplink Removes the current integration label and assignees on the pull request, add the integration domain after the command.
• @home-assistant add-label needs-more-information Add a label (needs-more-information, problem in dependency, problem in custom component) to the pull request.
• @home-assistant remove-label needs-more-information Remove a label (needs-more-information, problem in dependency, problem in custom component) on the pull request.

[astrandb]

@MartinHjelmare Any comments on this? I have expanded the proposal above.

[MartinHjelmare]

I'll take this up for discussion with the core team.

[MartinHjelmare]

We've discussed this in the core team. The conclusion is that we don't want to accept 3rd party API translations. The reason is that the frontend language may differ from the core language and then the experience will be inconsistent if API translations would be used. Another reason is that automations using the translated strings will break if the language is changed.

Can you estimate how many translations would be needed and how that would look if we'd use the Home Assistant Lokalise approach for translations?

[astrandb]

That was a very dissapointing message. I don't know if 3rd party translation is the correct term here. We get the language we request from the API.

That said, it is difficult to estimate the number of different entity names. But a qualified guess is somewhere in the range between a few hundred to a couple of thousand. Probably in the lower end of the range. myUplink has no official support channel for the public API and they have not been very helful with feedback so far. So the only practical way to get the strings is to harvest them from diagnostic feature in HA or on Swagger at myUplink developer site. But remember, you need acces to the specific model of heatpump in your personal account. It should be possible to harvest the strings for your own account/appliance in the almost twenty langages that the API supports and then someone with proper access to Lokalise could prepare and upload data to get a starting point for community translations.

However, I see a problem with quality of theese translations, since some data points are named in the API after zone names that the enduser has assigned him/her-self.

If the core team persists in this issue, I see no other solution for foreseeable future than to stick with a one-language (english) integration. The codeowners will be busy developing new functionality so someone else will have to take on this work.

I hope that the core team is willing to reconsider the position.

[MartinHjelmare]

Just a note on my terminology: A 3rd party library is all libraries that is not standard library or Home Assistant.

[MartinHjelmare]

I don't think anything has changed in how we view this issue.

I'll close here for now. Thanks!

[joostlek]

However, I see a problem with quality of theese translations, since some data points are named in the API after zone names that the enduser has assigned him/her-self.

Since 2024.2 we have translation placeholders, this allows developers to put static fields (like zone names, channel numbers, whatever more) in translation keys. https://developers.home-assistant.io/blog/2024/01/19/entity-translations-placeholders

[astrandb]

Since 2024.2 we have translation placeholders

I am well aware of that, but it still means that someone will have to inspect all incoming name strings and insert placeholders in appropriate places.

I accept the ruling and rest my case.

[joostlek]

That's all done by home assistant, you just have to provide a dict with say {"zone": "living room"} and the translation string would be "Heating {zone}".

[astrandb]

I know but you still must create the key with the placeholder in the right place. Since we don't have any control how these primary strings are laid out I doubt that it can be done automatically without human overview.

Well, I won't deal with this in foreseeable future, so i hope that someone else will probably find a reasonable way.