#Translation stuff
green schooner
Hmm
So you said it found a translation for the name
that sounds strange since the code you just showed doesn't have a name
lime meadow
When I added _attr_has_entity_name = True I also added the name key to en.json. I didn't check in those changes because they didn't help with what I wanted, which was translations of the entity states.
In fact, even after I removed _attr_has_entity_name = True, it was still translating the name until I removed the name key from en.json.
green schooner
Hmm
lime meadow
The name translation gets done in the backend. There's specific code for that in the Entity class. But I don't see any code in the backend for translating entity states. That must be happening in the frontend somehow??? I have never looked at frontend code, which is a complete mystery to me.
green schooner
Hmm, where do you see the translated names?
lime meadow
In the UI, the friendly_name attribute, in the entity registry (or, at least, as best I can remember.)
lime meadow
Oh, ok. When I look in the States tab, the state isn't translated. When I look at the entity on the home page, the state isn't translated. When I look at the state history, it isn't translated. I don't see the translation anywhere, only the newer, shortened values (day, civ_twi, etc.)
lime meadow
I mean, accorind to the docs, it should be very easy. Just add the translation_key property (which I did via entity_description), and then add the translations in translations/xx.json.
green schooner
I mean that should be the case yes
hence why nobody really has an answer to your problem haha
lime meadow
Per your pictures, I see the first, but not the second. In the second it still says day, civ_twi, etc.
Could it be my browser? I'm using MS Edge. Then again, I see the same thing on my mobile on which I'm using Google Chrome.
green schooner
what does debug say?
lime meadow
debug on what?
green schooner
lime meadow
Oh, that shows what I expected.
The translation_key also shows up in core.entity_registry.
I'm not running it right now, but I can get the output if you think that would help.
green schooner
Hmm
lime meadow
Could it be a conflict somehow with the sensor component? I used "sun_phase" for the translation key.
green schooner
I mean everything is under its own domain
lime meadow
Ok, I didn't think it would be a problem, and it did seem to find the name translation (when I had that), so that seemed to indicate it wasn't a conflict.
green schooner
Like the fact that it can fetch those values
like
its strange
what is the options list?
lime meadow
The untranslated values.
green schooner
with or without None
lime meadow
Let me get it running so I can more accurately answer your questions. It will just take a sec...
green schooner
And I do have to say, my general view of this integration is that it's (too) complex
lime meadow
options:
- night
- astro_twi
- naut_twi
- civ_twi
- day
blue_hour: false
golden_hour: false
rising: true
next_change: "2023-11-07T11:36:24-06:00"
device_class: enum
icon: mdi:weather-sunny
friendly_name: sun2 Sun Phase
whats the state atm
lime meadow
day
lime meadow
Debug output:
2023-11-07 08:57:49.019 DEBUG (MainThread) [custom_components.sun2] sun2 Sun Phase: entity_description: SensorEntityDescription(key='sun_phase', device_class=<SensorDeviceClass.ENUM: 'enum'>, entity_category=None, entity_registry_enabled_default=True, entity_registry_visible_default=True, force_update=False, icon=None, has_entity_name=False, name='sun2 Sun Phase', translation_key='sun_phase', unit_of_measurement=None, last_reset=None, native_unit_of_measurement=None, options=['night', 'astro_twi', 'naut_twi', 'civ_twi', 'day'], state_class=None, suggested_display_precision=None, suggested_unit_of_measurement=None)
2023-11-07 08:57:49.019 DEBUG (MainThread) [custom_components.sun2] sun2 Sun Phase: translation_key: sun_phase
And, FWIW, the core.entity_registry entry:
{
"aliases": [],
"area_id": null,
"capabilities": {
"options": [
"night",
"astro_twi",
"naut_twi",
"civ_twi",
"day"
]
},
"config_entry_id": null,
"device_class": null,
"device_id": null,
"disabled_by": null,
"entity_category": null,
"entity_id": "sensor.sun2_sun_phase",
"hidden_by": null,
"icon": null,
"id": "6cf7dec7420edd5acef52ede382ab80f",
"has_entity_name": false,
"name": null,
"options": {
"conversation": {
"should_expose": false
}
},
"original_device_class": "enum",
"original_icon": "mdi:weather-sunny",
"original_name": "sun2 Sun Phase",
"platform": "sun2",
"supported_features": 0,
"translation_key": "sun_phase",
"unique_id": "sun2 Sun Phase",
"previous_unique_id": null,
"unit_of_measurement": null
},
FWIW, this integration has been around for a long time, and has had to cope with constant reorganization, re-architecting & re-implementation in the core, at the same time trying to maintain backwards compatibility so that the users aren't required to update HA every time I add a feature or fix a bug. And the class hierarchy is designed to minimize duplication, etc. It has a lot of features, so...
Not getting defensive, just explaining. lol
green schooner
I am really trying to figure out why this happens
and I can't really place it
wait
I think I might know why
lime meadow
I appreciate the help. I'll try creating an extremely simple custom integration as a test case and see how that goes.
lime meadow
I seem to recall the docs said the only requirement was that the entity has a unique ID (and hence is in the entity registry.)
green schooner
To give a guess at a logical explanation
YAML based integrations don't have their strings sent to the frontend
lime meadow
Well, like I said, the frontend is a complete mystery to me.
green schooner
Like, YAML based integrations never have any frontend strings since they dont have a config flow
So there probably wasn't a reason to send the translation strings for them to the frontend
lime meadow
But config flow isn't the only reason for translations. Seems like a bug/deficiency/bad assumption.
green schooner
the only other reason I can think of is state translations
And then we come to the point of HA architecture decision, we may not add new features to YAML based integrations unless they are migrated to a config flow
lime meadow
Probably one of those things that has been overlooked, probably because most (if not all) integrations that provide translations also implement a config flow.
green schooner
So a change to try to get state translations to YAML based intergation probably won't make it
lime meadow
Or, what you said.
green schooner
Probably one of those things that has been overlooked, probably because most (if...
also true
lime meadow
I've already started thinking about how to add config flow to this, at a minimum with import only. Adding UI based configuration could get tricky given all the features. Anyway, once I do that, I can see if entity state translations start working.
Thanks for the help!
green schooner
No problem, I also learned stuff today
lime meadow
@green schooner Just to update in case you're interested, I implemented config flow (only for import for now), but that did allow translations to work! Well, mostly. I can translate the title of the integration, entity names and entity states, which is great. But state attribute translations don't seem to work completely. The interesting thing is, I can translate the name of an attribute to English (en.json), but not to "Netherlands" (nl.json), BUT I can still translate the name of the entity via nl.json. So, it seems to find the state_attributes part in en.json, but although it finds other things in nl.json, it uses the state_attributes part from en.json. Very strange. But, still, I got the main part working. Thanks for the suggestion that it was the lack of config flow that prevented it from working!