I’m running into a dead-end with my custom integration development with regards to how to do proper localization for entity friendly names.
I have integration which is thin layer over a package which has the full implementation (According to HA guidelines). The package itself can create lot of different entities and we keep extending it to expose more. This does not require any change with the custom integration.
The package can provide nice English name for each of the enitities it exposes. Still, it will be nice that in different languages, the entity name will be localized. I can also expose good _attr_translation_key for each of those entities.
To the best of my understanding, the package can not expose the localizied text so people need to submit PRs to the custom integration repository directly if they want to add localized strings.
What I want to achive is that if someone add new capability to the package it will use the built-in nice English name till someone else decide to localize that entity in the custom integration. I didnt manage to achieve that.
What I did manage to achieve is:
Use the English names all the time and not support localization at all. This is done if I set the _attr_name of the entity.
Never use the English name and get really ugly ids or device classes (which are really not useful, I have tons of entities with the same device class so they get the same friendly name) if I set the _attr_has_entity_name=True till someone create localization (even for English)
Is there some middle ground which will allow me to specify nice names till there is actual transaltion for the _attr_translation_key? I dont know in runtime if _attr_translation_key actually point to valid string in the language which is currently used.
Thanks @Bieniu for trying to help me. I appreciate it!
Can you explain “set name for entity in en.json file”. Do you mean I should parse the en.json file myself and look for specific keys? Is it a common practice? Is there any examples for that?
Also, wont it make it that the English name will be the one which is always used if I will load the content of the en.json into the name property?
I’m familiar with the translation folder and the en.json file. But it is not solving my problem. Entities keeps being added to the package my integration depends on. And if I don’t have the new entities which are added also submitted to the localization folder than I don’t have a way to make it presenting the localized version to the one which do have localization and the English name for the new ones which don’t.
Unless, I’m still not fully understand the situation you describe.
I don’t fully understand your approach. The integration code is the place where you manage a set of entities available to the user. And also in the integration you manage the properties of these entities, name, unit, device class etc. When a new entity appears in the backend library, you still need to add support for it in the integration code.
So, no I dont need to add support in the integration everytime someone / me is adding new mqtt mapping to the package. This is why I’m running into issues.
From what I know, it is not possible to implement entity name translation without a static en.json file. So it seems to me that the only sensible solution, apart from manually creating this file, is to write some script that will generate an en.json file based on the backend library.
Actually this is not bad idea at all of there is no more elegant solution. It is real pity I can’t supply the en values in runtime and let the other languages files to suppress it.
I think you gave me valid direction even if not ideal.