Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Home Assistant: Add language translation dict for states that come back from HA #275

Closed
JarvyJ opened this issue Jan 6, 2022 · 7 comments
Milestone

Comments

@JarvyJ
Copy link
Owner

JarvyJ commented Jan 6, 2022

Yeah, this is kinda interesting. Since it affects just Home Assistant, I think I might add a language dictionary that gets auto-loaded based on language settings and provided back in the base constructor for use. English words that need to be translated from Home Assistant could all be defined there with their translations and the code could reference. I'll create a new issue and play around with it a bit to see how it would work.

Originally posted by @JarvyJ in #232 (comment)

@JarvyJ
Copy link
Owner Author

JarvyJ commented Jan 6, 2022

Hello @oerkel47! I think I have a solution for the HA API returning states/attributes in English. Since it only affects the Home Assistant component, I've created an api_translations folder with the languages' translations that come back from the HA API (in a new branch - #279)

The idea being that any English response that comes back from the API indicating a state (like on or off) is defined in the api_translations/[language].json file. This gets autoloaded by the Home Assistant component and is setup in the HomeAssistant component.

In all of the domain-specific controller and their language files it can be accessed with self.ha.api_translation. So in switch/de.py, you could use self.ha.api_translations["on"] and it would return an.

I kinda like the idea of having all the responses from the API translated in the same place. If you want to try out the branch and let me know how it goes that would be great! I tried it out a bit and I hope it'll be useful overall.

@oerkel47
Copy link
Contributor

oerkel47 commented Jan 6, 2022

Thanks @JarvyJ, I will try it out soon.

@JarvyJ JarvyJ added this to the 2022.02 milestone Jan 6, 2022
@oerkel47
Copy link
Contributor

oerkel47 commented Jan 7, 2022

Wouldn't it be a good idea to directly translate the translatable entries inside the response dict inside the base class? Would take the work from the translators while also keeping the language specific code tidy.

response = self._toggle_light(light)
response["state"] = self.ha.api_translation[response["state"]]

This works, but looks ugly.

@JarvyJ
Copy link
Owner Author

JarvyJ commented Jan 8, 2022

Oh, I like that idea! It'll make it a lot nicer for translators. I'll see if I can get it worked in today along with a workaround for #274

@JarvyJ
Copy link
Owner Author

JarvyJ commented Jan 8, 2022

The branch has been updated!

So I ended up doing the translation work in the Home Assistant api code. This way any get_entity call that has a state attribute will get translated with the json file.

I've also made the get_entity to take in the response from call_service and check if it's an empty list, perform the delay, and then return. This should solve the issue in #274.

I'll do a bit more testing on my end, and if it seems good for you, we can merge and go from there!

@oerkel47
Copy link
Contributor

oerkel47 commented Jan 9, 2022

Regarding the translation: my first tests worked without issue, but have not done many. Nice work!

JarvyJ added a commit that referenced this issue Jan 9, 2022
* HA API translation support at API layer

* fix for empty list on call_service with added delay

* removed debugging print statements

* Update README.md

closes #274, #275
@JarvyJ
Copy link
Owner Author

JarvyJ commented Jan 9, 2022

closed with #279

@JarvyJ JarvyJ closed this as completed Jan 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants