devs_translations-archived

[dense garden]

👋 Added a translations channel, as we had no place to get help with that.

Home Assistant is translated into many languages by our community 🏆

Want to help out translating Home Assistant? It is really easy to jump in and help; join one of the translations teams on Lokalise and start translating from your browser right away!

You can find our translation team join links here: https://developers.home-assistant.io/docs/translations

🇬🇧 🇺🇸 🇩🇰 🇳🇱 🇩🇪 🇫🇷 🇪🇸 🇹🇷 🇮🇹 🇪🇪 🇧🇬 🇨🇿 🇷🇴 🇵🇹 🇷🇺 🇵🇱 🇬🇷 🇫🇮 🇺🇦 🇻🇳 🇹🇭 🇧🇷

[dense garden]

Also working on Dutch translations @frozen orbit ? 😄

[frozen orbit]

Yes, when I have time

[dense garden]

Yeah same, got a tab open, do a couple every spare moment to get it going a bit

[frozen orbit]

Just updated tuya

[dense garden]

Noticed, it has a nasty bugger

[lost solar]

My parents got some rebranded Tuya smart power plugs that aren't entirely translated.

More specifically, the possible states of the backlight modes are in English: https://github.com/home-assistant/core/blob/1e704c4abe0b5c19109ce0fff05a5252dbd91dbd/homeassistant/components/zha/select.py#L284

There's a bunch that are similar to that. How would I go about adding translations to those?

[hybrid granite]

Oh I just created a PR for that (https://github.com/home-assistant/core/pull/96553)

Although I did not do the possible states yet as I need to find out if we can rename the states to a snake case variant

[lost solar]

Wonderful, thank you. I'll happily add German translations once your change is through then!

[lost solar]

Can anyone shed some light on how Lokalize and the github repo actually work together?

The strings.json in the repo has the... default strings - and they get loaded into Lokalize for translation as soon as they are added, and for every new release the latest translations are pulled from Lokalize, or how does it work?

[hybrid granite]

afaik, you explained it correctly

Although the developer docs still say "The translated strings in Lokalise will be periodically pulled in to the core repository.", I don't think that's correct anymore

[lost solar]

And I create a dict in strings.json and reference that in, say, th eentity description as the translation_key?

Also, somewhat related, I suppose API access to Localise is not permitted?

There's like.. 100 different HTML colours in there that need translation

But colour names can be very.. peculiar

I found a website that lists them all and wanted to write a python script to just scrape it and update it that way.

But despite creating an API token, I get a 401

[hybrid granite]

I dont know those specifics

[lost solar]

Oh hey, it's you from the Github! \o/
I did the UV thing for tomorrowio there.

[hybrid granite]

Oh, nice haha

[lost solar]

Seems like there's no way of doing any bulk work on Lokalise. I get that it doesn't work most of the time and is probably to prevent to just have someone feed it through a translation service and call it a day. But for stuff like colors it'd have been nice.

[lost solar]

I don't suppose there's an easy way of telling which integrations still need translations, is there? Since they don't show up in Lokalise unless they already have the strings.json and the keys added in the core files themselves, right?

[hybrid granite]

A month ago I made a script that would categorize all integrations. So I took all config flow integrations and checked every one of them

https://docs.google.com/spreadsheets/d/19RO05KK2uzm6KN6UXiF9lhhEkVelJgsB1CLByU4dngs/edit#gid=1228017269

[lost solar]

🙏

[hybrid granite]

But I practically almost got every one of them haha

Like there still needs to be some work done to get device info in there

[lost solar]

You're doing good work. Thanks in the name of my parents :v

[hybrid granite]

but that requires knowledge of the integration and stuff, and I don't own or use every integration

hahaha

[lost solar]

I'm translating the integration on lokalise sorted by the number of users.

Since there's so much to translate...

[solemn star]

good work 👍

[lost solar]

Okay. I translated like.. 700 keys.

I think I'm done for today

😶

[solemn star]

I wonder if it can be automated with DeepL and then manually checked?

[lost solar]

It could be, but at least for regular schmoes the API doesn't seem to work.

I tried it and got a 401

But I don't know who's in charge of the translation effort to hand out powers like those.

But I agree. A first pass doing DeepL, giving everything an extra tag as in "automatically translated", and then humans can go through those that are tagged like that and modify if necessary.

I was trying to write a script that'd translate the name colours - because those are stupidly specific and don't necessarily coincide with what DeepL and the like spit out.

Because they're official colour names

[dense garden]

Lokalise can do that already, however, from my perspetive, that is often not correct

During translating, DeepL, Google Translate, Microsoft translate, MT & the AI from lokalise are already available options

(I found their own AI to work the best, as it takes our glosarry and rules into account)

[vestal palm]

I've been on vacation for 2 weeks and the number of translation keys in the core repo grew by 50-60%. what happened? was there any major refactoring done?

[covert wigeon]

The quality of MT (Machine Translations) vary by languages. so if this happens, I don't think we can just enable it for all languages and call it a day.

[covert wigeon]

The question is "official" by whom-in what language-for which region?

[hybrid granite]

Service names and descriptions are now translatable

And there have been a lot of integrations who got support for translatable entities

[vestal palm]

thanks!

[lost solar]

https://developers.lokalise.com/reference/list-all-keys Tested for the core project, German language. Get a 401

Please note that you must have an admin role in a project in order to access that project with the supplied API token.

I guess they don't have any limited API access.

It's either all or nothing

[covert wigeon]

The normal translator (like me) in Core doesn't have any admin role. So, yes, no API access.

IMO, Machine Translations works best when the translation project is using translate

...then review phases (2-stages). Something that is not enabled in Home Assistant's Lokalise project.

[deep kestrel]

where in the code is currency determined from the location?

[orchid moth]

Is it determined from the location? I thought it is selected at onboarding, and also in user general settings.

[deep kestrel]

it is selected from onboarding but it gets populated by somewhere and in my case its wrong since january of this year

[orchid moth]

do you mean populated during onboarding? Or where specifically are you seeing the wrong thing?

[dense garden]

You might want to try again in current dev/upcoming beta / next release

that part of onboarding is changing

[inner reef]

Why having two Spanish ?

Spanish
Spanish (Latin American)

[covert wigeon]

Because one Spanish locale is not enough.

[calm mountain]

Hi there. For my custom integration I added translation for services (nightly hassfest was complaining). However the frontend won't show the translations and I cannot figure out what the problem might be. Hassfest shows no problems so it seems structurally okay.
Can anyone spot a mistake in my repo? https://github.com/eifinger/hass-weenect/tree/main/custom_components/weenect

[orchid moth]

don't you need a strings.json file? you can look at an example of how this was done in a core component
https://github.com/home-assistant/core/pull/95984

[calm mountain]

Custom integrations work differently: https://developers.home-assistant.io/docs/internationalization/custom_integration

[calm mountain]

Custom Integrations received support for this in 2023.8. It now works.

[cinder marsh]

Hi is there already a way that allows my to use translations within an automation or script. Like something like:

   {%- set forecast = state_attr(weather_entity, 'forecast')[0] %}\n
   het weer: {{ forecast.condition | translate:NL }} 

[cinder marsh]

thanks for helping out

[woven storm]

You should have asked in #templates-archived , and no, there is no such thing. You have to provide the translations yourself

[latent portal]

Hi all fellows! I started massive translation check of Home Assistant for 🇨🇿. I would like to ask admin, how to be Proofreader to avoid working of more people together. Now, it happened to me, that I adjusted translation to be correct, but after few days, it was re-written by someone else, who don't know correct consequences. Is it possible to make me as Proofreader with higher rights? I spent significant amount of time doing it recently. Now, all, except core is done, but I am working on it too. Thanks!

[lost solar]

We are trying to download the translation files of Home Assistant. More specifically, we would like to import the Catalan translations to automate the generation of quality reports and to help keeping consistency between open-source projects. We do it in https://www.softcatala.org/recursos/memories/ (https://github.com/Softcatala/translation-memory-tools)

Does anybody know if there is a way to download the translation strings for Android and core (backend/frontend)? I've only been able to find the strings for iOS (which may not be 100% up to date, but may be sufficient for our use case):
https://github.com/home-assistant/iOS/tree/master/Sources/App/Resources/ca-ES.lproj

This might be the first time we've come across an open-source project where the translations aren't available for public download. Typically, they're distributed alongside the source code, under the same license.

Thanks in advance

[dense garden]

We've removed them from the sources, as they are extremely active. We merge them into the source @ build now

We don't maintain and track them in git, as we use Lokalise for that

[latent portal]

@lost solar Hi, can I ask you to check my message above?

[lost solar]

Hi @latent portal. Please could you post a link to your message? I'm not sure which one you are referring to, is in this channel?

[lost solar]

As a user, is there an option to download the translations? Otherwise, if these translations aren't included with the source code, does this imply that Home Assistant might not be fully open-source? Shouldn't everyone have the capability to build Home Assistant complete, with all its translations?

[dense garden]

As a user, is there an option to download the translations?
All our translations are available, searchable, with history and available for contributions on Lokalise

it is just as open as anything else.

It just uses something other than git.

[lost solar]

I'm not familiar with Lokalise, but for what I see, most (all?) open-source projects using Weblate, Transifex, Crowdin or similar platforms are also including the translations in git, usually via a pipeline

[dense garden]

Well, we use Lokalise 🤷‍♂️

We used to flow them back into git

we stopped doing that

as it is just too much

and makes for duplicate effort of history tracking

additionally, people would constantly make PRs against the git repos to update translations

which sucked in terms of constantly declining them

so we choose to handle it this way.

for more information on how to use translations, please check out our developer documentation

[lost solar]

but I can't download the translation files, right? what you are doing during build time, this can't be done by unauthorized users. I can only access the translation via the Lokalise UI, if I understand it right

[dense garden]

Not sure, we don't handle them as files

all translations are available when you log in into Lokalise

and you can contribute, view, search, review, look at history and everything else

during build we pack them up in a format Home Assistant understands and ship that with each release

[lost solar]

I already tried with curl and the official Lokalise cli, and I'm afraid I need an admin user for that

[dense garden]

which is available on the usual resources, including GHCR, DockerHub and pypi

[lost solar]

I don't know if Lokalise can be set-up to allow anonymous access to export the translations

[dense garden]

I don't think so, it is quite a heavy process to export

but feel free to extract them from any of the build artifacts we have if you looking for a build result

[lost solar]

hmm, are these build artifacts publically available?

[dense garden]

uh yes, that is what you download if you install HA?

HA is not a compiled piece of software

e.g: https://pypi.org/project/homeassistant/#files

[lost solar]

thanks, I do see the translation files here. Are these from the frontend or backend, as listed in https://developers.home-assistant.io/docs/translations/ ?

[dense garden]

No that is just backend

frontend is a different package

https://pypi.org/project/home-assistant-frontend/

[lost solar]

great! So I'm only missing the Android strings then, as I can already download the iOS ones from git (even if they are not 100% up to date)

thank you very much @dense garden

[manic ermine]

For Android you could also try extracting it from the release artifact/apk (which is minified so you might have to check each xml resource)

[lost solar]

Thanks! I think I'll be able to automate this

[latent portal]

@lost solar sure: #devs_translations-archived message

[lost solar]

@latent portal I don't think I can help, sorry. I'm just a standard user, not really involved in any translation yet

[latent portal]

@lost solar Ah, I didn’t know that. So, I definitely need somebody from developers then. I will try to sesrch more.

[covert wigeon]

I seconded @latent portal here. HA has now a little over 100k words on Lokalise (core+frontend+ios+android). For my language pair, it is about 40> working days of full time translator.
For projects as big as HA, we need the "Reviewing" feature enabled on Lokalise.

The most active contributors can be assigned as initial "contributors with reviewer permissions".

I'm not sure where I should put this policy proposal into. Should I put this on architecture repo? (But I cannot implement it since I don't have any administrative rights to Lokalise HA projects)

[latent portal]

@covert wigeon Exactly! I finished almost all in free time and core translation remains (50 %) and definitely, setting up roles is key to maintain consistency. I also do not know, who to contact.

[runic bolt]

what is a translation fragment in the frontend?

[latent portal]

@runic bolt What do you mean exactly?

[runic bolt]

i figured it out already
(its a way of splitting translations so they arent shipped to the client all the time)

[latent portal]

@runic bolt OK then. Good to know.

[old niche]

Is there a way to return a string that can be translated from the backend? I'm specifically talking about the return "Done" in /usr/src/homeassistant/homeassistant/components/conversation/trigger.py. At the moment, this string is pronounced (badly) in Dutch when I converse with HA...
I wanted to create a PR for this, but I can't find out how to return a "translatable string" from there...

[dense garden]

Currently that is not possible yet. However, we do have plans on making those customizable (the response fully custom)

[cinder marsh]

is there a way to use home-assistant translations in jinja2 templates?

like i want to translate the weather state.state_with_unit to dutch

[latent portal]

@dense garden Hi, looks like you are one of the developers of HA. I asked my question regarding assigning proofreading rights on Lokalise. Can you please check it? Link: #devs_translations-archived message

[dense garden]

We have not had much of such situations as you just described. Sure we have had some cases of differences of opinion. As far as I am aware, we have no processes or procedures for such things in place.

[latent portal]

OK, meantime it seems, that I stayed there alone now. Anyway, as also @covert wigeon stated, it will be very nice to consider some hierarchy rules for managing translations, what is your opinion?

[dense garden]

My opinion is that I think it hasn’t been an issue in general to worry about it 🤷‍♂️

[latent portal]

Hmmm, ok. Anyway, some control over it will be nice, but you are the boss If you change your mind, this will be even better. Thank you go state your opinion.

[old niche]

If you use HACS, there's https://github.com/PiotrMachowski/Home-Assistant-custom-components-Custom-Templates

[cinder marsh]

thanks that is what i was searching for.

[lost solar]

Some glossary words in Lokalise are a bit odd, for example "About" or "Again" in the "Home Assistant Companion for Android"-project. Is there any way to remove those kind of words to declutter the glossary a bit?

[vestal palm]

is there a way to hide languages in the Lokalise interface? I may have been an idiot when I joined the HA project and selected all languages, but I really only want to see 2 - English and Romanian

[covert wigeon]

When I am logging in to the Lokalise, I always have to select the Project, and choose Bilingual view, then select my language. The chosen bilingual view+language is then persistent until logging out from Lokalise.

[vestal palm]

I don't think i've been asked that, but i will try a logout/login

[lost solar]

For the projects Front End, Core and iOS it seems that all languages show up. But in the android project I was made to choose one language when I added it, so there is a much clearer view for that project on the project page for me!

[latent portal]

Same experience. And as stated above by @dense garden as one of the developers, they think, it is ok. So, we need to accept this. Of course, I will rather have permissions managing, languages managing, but it is jow it is…

[lost solar]

Is it possible to see recent changes for translations in Lokalise? Where one can see last edited translations, in par with https://en.wikipedia.org/wiki/Special:RecentChanges

[covert wigeon]

I don't think Lokalise has this kind of sorting. The closest feature I always use is actually "Sort by last updated". But it is actually a mixed between what has been edited (in Lokalise) and what has just come from github.

[lost solar]

That's too bad. Would be a handy feature. 🙂

[rustic stirrup]

Filter out untranslated and sort by last updated?

[lost solar]

As tz pointed out, I don't want the mix from what has been edited in Lokalise and what has come from GitHub. I only want to see latest edits in my language in Lokalise.

[rustic stirrup]

Hmm - which sub project is this for? For core, only English comes from GitHub, so to only see that latest updates in a language, I had to select the same language in both columns (bilangual view). Not sure if this gives you want you want though.

[covert wigeon]

To the core and frontend repository maintainers: is it too much to ask to have a nightly GitHub actions that does download all translated string from Lokalise and push each {language}.json to an read-only repository (for the rest of us), using the same directory structure just like in core and frontend?

This way, the language maintainers can:

• monitor missing strings and decide what to do with them, based on their priorities (e.g., internal integrations have higher priority than platinum)
• using their own tools, conduct concordance against specific HA glossary, or common software/hardware localization glossary/termbase (then correct them in Lokalise as necessary)

I found Lokalise UI is very feature limited for, as I stated before, 100k words project (core+frontend).

[dense garden]

is it too much to ask to have a nightly GitHub actions that does download all translated string
Every nightly build has them attached as a build asset already.

monitor missing strings and decide what to do with them
That is not up to language maintainers, we handle that in code.

using their own tools, conduct concordance against specific HA glossary, or common software/hardware localization glossary/termbase (then correct them in Lokalise as necessary)
That is up to you, we provide Lokalise. If you want to look at stuff differently, feel free to pick up the language sources from our nightly builds or from our source distributions.

[lost solar]

Yes, mainly Core! Hmm, still gives me the (untranslated) updates from GitHub when i choose my language in both views. But it is good enough, that is the way to see the latest changes, just ignore those who are untranslated. Thanks for your suggestion!

[rustic stirrup]

Even if you add a filter «Translation is not empty» (or “none” - only on mobile, and don’t remember exactly)?

[lost solar]

Ah, filter "Translated" did the trick! Thanks!

[covert wigeon]

Thanks Frenck.

What I meant is of course not "monitor missing strings", but "monitor missing translations".

Where should I look these nightly builds/asset?

[dense garden]

but "monitor missing translations".
Those can be queried in Lokalise 🤷‍♂️
Set the filter to "untranslated"

Nightly builds can be found in GitHub (Actions tab)

for example, the frontend one: https://github.com/home-assistant/frontend/actions/workflows/nightly.yaml

[covert wigeon]

Thanks for the links. I presume the core one is
https://github.com/home-assistant/core/actions/workflows/builder.yml

I know it can be queried on Lokalise, but when the result is more than 20K missing translations then I need to know which strings I need to work on for the next hour.
Well, my experience and priority are probably not the same with other locales which has almost up-to-date translations (such as es, de, ja, or kr)...

[dark locust]

i found a very bad translation in german. how to proceed?

[rustic stirrup]

https://developers.home-assistant.io/docs/translations/

Found these new strings - looks like the wrong syntax?

          "on": "[%key:common::state::enabled%",
          "off": "[%key:common::state::disabled%"

https://github.com/home-assistant/core/blob/dev/homeassistant/components/hue/strings.json#L111-L112

[orchid moth]

yeah that looks busted

[rustic stirrup]

I can make a PR

[hybrid granite]

Oh ouch, I made that mistake

[rustic stirrup]

I always blame the reviewer in such cases 😆

[hybrid granite]

Well

I proposed it

and approved it afterwards 😂

So I am both

[rustic stirrup]

Ouch! You can review my PR in a minute then

Actually - this syntax could probably be checked in the pre-commit hook and/or build

[hybrid granite]

We could do that in a separate PR

Curious how we can detect the usage of a key\

[rustic stirrup]

https://github.com/home-assistant/core/pull/101403

[hybrid granite]

Ooh, you're oyvindwe

[rustic stirrup]

Probably requires a custom parser to be written. Read all (changed) strings.json files, parse all values, check that all [%key: is closed by %]. I believe a string may contain more than one key though.

[hybrid granite]

Nope, one string = one key

Also without additions

So no "[%key:...:] something"

[hybrid granite]

But what if someone forgets the first [

Or %

Like I agree that we should fix this, but I'm thinking of a way we can make it completely fool proof

[rustic stirrup]

Could add som typical cases?

Or whip the reviewers that let it pass.

[hybrid granite]

Haha, definitely

But also keep in mind the hassfest scripts are used in custom integrations

And it maybe doesn't have to be in the code, if we can check this in the precommit, the mistake never gets made in the first place

Since it can't be committed (in a perfect world where everyone has their git hooks setup)

[rustic stirrup]

I have a checkbox in my IDE to bypass pre-commit hooks…

[hybrid granite]

Oh right

[rustic stirrup]

I guess translators would catch this quite fast (that's how I found it)

[hybrid granite]

Why don't removed strings from the core get removed from lokalise?

I removed component::withings::config::flow_title from strings.json, but for some reason Lokalise still has this key (and it's being downloaded and used in the releases)

[dense garden]

That is a manual process, I'll make a note to run a cleanup @ next beta cut

[latent portal]

@dense garden Hi, can I ask to update strings from companion apps (both iOS & Android), as I massively updated them and want to check for possible errors. Thanks!

[dense garden]

I can't 🙂

[latent portal]

Really? I thought, that every release automatically grabs latest strings updates, but found, that they are updated within just some releases…

[lost solar]

How often is the Lokalise-translation updated to the Home Assistant-releases?

[lost solar]

Also, where it the best place to report faulty strings? For example component::plugwise::entity::switch:🔒:name in the core module?

Ah, should be : lock : instead of the emoji...

[hybrid granite]

You can wrap them in ` so it doesn't add emoji

I can take a look tomorrow

[dense garden]

Every release

[heady brook]

about to submit my first translations!! (spanish)

uh, so i guess i only have 14 days to do translations or is it a thing like crowdin where its free to submit translations but you have to pay to host

[dense garden]

There is no timelimit on contributing to our translations, nor is there a cost involved

Lokalise provides their services to Home Assistant for free

[hybrid granite]

https://github.com/home-assistant/core/pull/101862

[hybrid granite]

#1163288765142413373 / #devs_voice-archived

[cinder marsh]

kk 😉

[eager loom]

Hello my name is Clive, I am new to open source development, I would love to contribute/help on translate my Language which is Shona, I can’t see it on the languages available. I would love to contribute to this project who should I contact. Your help will greatly appreciated

[orchid moth]

There's a link at the top of this channel for how to request a new language to translate. However it doesn't seem like it always gets accepted quickly, so I can't say how long it would take to be successful.

[eager loom]

Thank you

[latent portal]

@dense garden Hi, I finished huge Czech update. During this work, I found, that all integrations are merged in "core" section of Lokalise. I would like to ask, wether it will be possible to divide each integration to standalone project or some filter. Doing this will allow keep used wording when adding/updating translation for each integration. Sometimes it is needed to translate some words differently based on context. Do you think, it can be possible to make such division? For example: "common::", "component::abode::", "component::accuweather::" and so on. This will really help a lot!

[dense garden]

We can't make that devision

that would create thousands of projects

[latent portal]

Understand, it will allow more covenient work, but if cannot be done, I get it. One more question - is it possible to subscribe to some mail service, which will allow me to receive updates on Lokalise? Without it, I need to check Lokalise day by day for new/updated strings.

[dense garden]

is it possible to subscribe to some mail service, which will allow me to receive updates on Lokalise?
I don't know. That is, I guess a better question to ask Lokalise

[latent portal]

Oh, I thought, as member of programming team, you will know that - if Lokalise is hosting HA strings, then it needs to be created project and somebody should be set as project owner/admin - or am I missing something...?

[hybrid granite]

It's automated

Also good to know if that changes in translations only are put in the application every (sub)release. Every major release is released the first Wednesday day of the month and since recently, sub releases tend to release right before weekend

And since lokalise people are fans of HA, maybe we can create a lokalise integration :p

[latent portal]

Thanks for reply. Also, good to know about release periods. 👍

[supple phoenix]

Is it possible to translate a name that is stored inside a DeviceInfo object? I currently have some hardcoded values like "Power meter" and "Battery" that I want to make translatable, but I don't know how...

[bright mist]

In the integration vicare a field description is wrong in the strings.json, can I simply open a PR to change it in there or do I need to do it in lokalize, or both?

[dark sand]

When the source is wrong (English) you need to open a PR, otherwise simply change it in Lokalize.

[latent portal]

Yes, I am doing it same. When found typo or wrong source text, I am making PR then.

[hybrid granite]

Ah I recognise your picture now, nice catch on those mqtt strings 🙂

[latent portal]

😁thank you, I did it already. As you can see, it is nothing hard and if you will see any typo in strings, you can contribute too. 👍

[hybrid granite]

When I see one I always try to fix it 🙂

[kindred pebble]

Hi, I have an issue with entity name translation which always shows the English translation regardless of the user's profile language. Other translations from the same translation file, like sensor values, work OK, it's only the name translation that is ignored. Any idea how to debug this, or even just where does the code that handles the translation sit would be very helpful.

[hybrid granite]

Can you give a bit more context? What integration are we talking about? What language?

[polar ferry]

@kindred pebble I converted your message into a file since it's above 15 lines :+1:

[kindred pebble]

And this is the relevant section from en.json:

  "entity": {
    "button": {
      "homeconnect_debug":   { "name": "Home Connect Dump Debug Info EN" }
    },

When I edit the same value in de.json or he.json (just two that I tried) I still see the text in the UI with the "EN" string, so I know it's coming from the en.json file.

@hybrid granite As I mentioned other strings from those files are translated so I know it's reading the file. And obviously I've refreshed the browser, deleted the browser cache, flipped back and forth between languages... anything I could think of

[hybrid granite]

do you have this pushed?

[kindred pebble]

not yet but I can push it if that would help.

[hybrid granite]

I think it would give a full picture

[kindred pebble]

https://github.com/ekutner/home-connect-hass/tree/config_flow/custom_components/home_connect_alt

It's a big integration with a lot of dynamically created entities so it's best to focus on these buttons which are created statically. The two button classes at the end of the button.py file are good examples for that.

[kindred pebble]

You can see a screenshot here, while the profile language is German. Notice that the first and last select controls are translated to German, as they should be. The entity names which are expected to be translated but are not are those on the left, two buttons and a sensor, under the "Home Connect Service" group.

https://gist.github.com/ekutner/793d29996574831d0a9c054eaaa418d6

[hybrid granite]

Could it just be that you need to have strings.json as well

[kindred pebble]

My understanding is that string.json isn't really used for custom integrations. That it's just a template for generating the actual translation files for core integration only. But let me give it a try.

[hybrid granite]

I have seen this discussion I think yesterday and I think the conclusion was you need both

Like I also can't imagine why you need both

but this could be a reason haha

[kindred pebble]

nope. I copied /translations/de.json to /strings.json , restarted HA and still seeing the English translation strings

do you know where in the code the translation is taking place? if I could put a breakpoint there I'll be able to figure out what it's doing

[hybrid granite]

wait, where are you checking for the translation?

[kindred pebble]

in the UI... what do you mean?

[hybrid granite]

like, are you looking at

button.something

or at the device

[kindred pebble]

Looking at a dashboard with these entities. See the screenshot here: https://gist.github.com/ekutner/793d29996574831d0a9c054eaaa418d6

It's where I'm seeing the English translation string.

[hybrid granite]

heh

This is strange

I can look more into this tomorrow

[kindred pebble]

Thank you, I'd really appreciate it because I'm totally lost.

[lilac prawn]

Hello,
missing language "Slovak" in Lokalise https://app.lokalise.com/projects/ [Home Assistant Companion for iOS]
Please add add it.
Thank you.

[lilac prawn]

You can set up the E-mail integration to receive notifications once certain events occur in your Lokalise project. You can enable project import and key added events if you want to receive notifications once new files or keys are added to the project (see the screenshot below).

Note that there is no option to send the notifications in summary. You will receive notifications once there are files uploaded or keys added to your project.

[latent portal]

Really? I don’t know, how to setup it. I see no screenshot.

[lilac prawn]

Lokalise contacted. Answer: it is required to install lokalise app "e-mail" (https://docs.lokalise.com/en/articles/1525880-e-mail), but install is blocked due missing admin permission ("You can ask the project manager to grant you the admin permission or ask them to install the E-mail integration on that project and add your email to that integration.") more info here https://docs.lokalise.com/en/articles/1400623-contributors

[dense garden]

Sorry, that is not usable, as it requires a administrator configuration of who is notified

and we cannot maintain such a thing

[lilac prawn]

thank you. Will be check, with lokalise, if is possible something "maintence free". We will see.

[dense garden]

Honestly? If I would be Lokalise

that would be a hard no

And really, I'm not sure if I would be adding such a feature / enabling such a feature, even it was available

[lilac prawn]

You know, sometimes the hardest thing is to ask the right question.

[dense garden]

I'm not sure how that is relevant at all or if that is the case at all

I think sending emails for changes on our translations would be a very dumb thing to do

considering the volume of changes; it would not make much sense.

[lilac prawn]

But you can choice only one language for notification, then it is not so much emails. I think this can help especially for translators. And sometimes exist easy solution. Only thinking.

[dense garden]

That is just as many notifications as any other language. Doesn't matter how many languages

the fact is, we merge 1500 changes a month

And sometimes exist easy solution.
Well apparently not...

[lilac prawn]

One more (other) point: Who can be asked for add language "Slovak" in Lokalise https://app.lokalise.com/projects/ [Home Assistant Companion for iOS]?

[dense garden]

You need to request that in the iOS issue tracker

mostly because I'm not aware if that needs adjustment on their end

[orchid moth]

Note this page directs all new language requests to be filed in the frontend repo... is that correct?
https://developers.home-assistant.io/docs/translations/

If your language is not listed you can request it at GitHub (https://github.com/home-assistant/frontend/discussions/new?category=localization). Please provide both the English name and the native name for your language. For example:

[dense garden]

Seems not correct

well, for everything but not iOS or Android

for Core & Frontend: yes

(as those go hand in hand)

the developer documentation is about os, su, core & frontend; not the apps

so in that context, it fits

[lilac prawn]

Thanks to both of you. I did it on 13th August in https://github.com/home-assistant/iOS/discussions. Now we need only to wait.

[kindred pebble]

Trying to ask this again hoping there will be some here now that knows what's the problem or how to troubleshoot it.

I have an issue with entity name translation which always shows the English translation regardless of the user's profile language. Other translations from the same translation file, like sensor values, work OK, it's only the name translation that is ignored. Any idea how to debug this, or even just where does the code that handles the translation sit would be very helpful.

[autumn cargo]

Entity names are translated based on system language, not user profile language.

[hybrid granite]

Entity_id right

This is about entity names

[kindred pebble]

Wow, you're right, thank you! But that's crazy, I've spent hours trying to understand why everything gets translated except the names. Changed the system language, restarted and now it's translated. Why the hell would it be designed like that? How does that behavior make any sense?

[kindred pebble]

@autumn cargo is right, see above. of course it makes no sense at all but that's how it behaves.

[sly hatch]

https://github.com/home-assistant/core/issues/103467
-> Its normal that the entity_id also gets translated?
And if so, it would be very useful to have something in the core that checks if the non-translated sensor exists and rename it instead of adding a new one ...

[autumn cargo]

Yes, entity_ids are translated as well (unfortunately imho). But they aren't changed if already existing (in entity registry).

[sly hatch]

There is no way to avoid that?

[autumn cargo]

I don't think so. The issue in the PR arises because the integration was removed and re-added.

[kindred pebble]

If you set the entity_id property on your entity yourself and won't get translated. I don't think it's documented but it works. Your entity_id property must have this structure: "{dummy}.{unique_id}" and then the final entity_id will be something like "sensor.your_unique_id". It doesn't matter what you use for the "dummy" as it gets removed. If you do that then you should probably set the unique_id property to the same value although, for whatever reason, it's not actually used to create the entity_id.

[sly hatch]

Imo we should check on re-add if the non-translated sensor exists, and if that's the case keep it or rename it to the translated ones.

This way things can be readded without breaking to much stuff

[autumn cargo]

A removed entity doesn't exist anymore 🤷

[sly hatch]

It's history still exists no? Anyways

[edgy zealot]

Hey my friends.
I figure out a translation issue.
Can someone tell me, how to / where to, tell/write to update this translation?

[orchid moth]

https://developers.home-assistant.io/docs/translations/

[edgy zealot]

To use this, I must login with a payed account which I do not have
Is there a possibility to send somewhere the description of the wrong translation?

[orchid moth]

you don't need a paid account

it's free to register

[edgy zealot]

Thanks. OK that works.
I found the translation, but there it is correct.

OK, got it. The history shows me that there was a very new translation and I think it is because I did not Update HA

[orchid moth]

yes the translations are shipped with each release.

[edgy zealot]

thanks again and have a nice evening!

[rustic stirrup]

The entity registry JSON file has a section with "deleted_entities", so it is (theoretically) possible to restore deleted entities.

[bright mist]

Can I apply some kind of templating to entity translations? I would like to add translation keys to the entities of an integration. But some entities are created multiple time from the same description and a suffix is appended to the name today. How would I usually handle this?

[hybrid granite]

Currently you can't. The only way to make something dynamic is via devices

[formal sequoia]

Let us consider this piece of code:
def event(self) -> CalendarEvent | None: """Return current or next upcoming schedule if any.""" return CalendarEvent ( <...> "summary": "this text for summary should be translated", "description": "this text also should be localised" )
The strings to be translated may not be part of the strings.json file since these are not entities, selectors, config, options, ... How do you suggest to translate them. Should I use gettext, or is strings.json applicable in a way I do not figure out ? other options ?

[hybrid granite]

There is no real way to translate calendar stuff right now

[bright mist]

When testing entities with translation key with the integration loaded as custom_components, the entities get the name UndefinedType._singleton. What am I doing wrong?

[hybrid granite]

Euh, I have seen this but I can't remember what the thing was

Did you generate your translations?

[kindred wyvern]

Need Help to add language "Tamil (தமிழ்)" to voice assitant
ISO 639-1 code - ta

[lilac prawn]

Hello @orchid moth,
for make better translation issue request (on Github) and for understanding of missing translation I have few questions:

1. How may I know find (in Github code) where is located yet non translated word (found on web or android app)? Then I know better where missing word is located, e.g. core or frontend, etc.
2. How may I do test of translation - direct show of web/app for test the output (e.g. when is not so long for visibility or is in the right context, etc.)?
3. Where may I find an tutorial, how to add missing word to lokalise (in Github code)?

Thanks in advance for explanation.

[orchid moth]

Hi. I would suggest if you are looking for the right place to find where a string originates from, you can try github search for the string in various repos to see if you can find it.
For example I remember you recently filed for "Login attempt failed". So if put that string in quotes in github search, for example you might find it in core:
https://github.com/search?q=repo%3Ahome-assistant%2Fcore "Login attempt failed"&type=code

As for the best way to test, I am not sure. I only work in English so I just edit the translations/en.json in my dev instance and rebuild to see the changes. I am not sure how that process might differ for other languages.
Maybe someone else here has better advice.

If you want to try localizing some unlocalized strings yourself via PRs, I'm not sure I know a tutorial for that. You would need to setup a general HA development environment.
https://developers.home-assistant.io/docs/development_environment/

After that it's just coding, perhaps you can review the changes made in some other localization PRs to get a feel for what is required.

Not all strings will necessarily be easily findable by search, as sometimes they may be composed by code, or split into multiple variables, so if you really can't find it anywhere you can ask and we can try to track down where it comes from.

[hybrid granite]

Wasn't there also a language that could help with identifying untranslated bits?

I also appriciate your issues, but I think it would be nice if we could steer you to the right repo before creating

As it probably takes more effort to move issues than to tell you at what repo to create them

[orchid moth]

I see there's a language Test in the language picker, but I just picked it on a lark, and now my whole system is crashed 😂

I think it only appears in dev instances.

not sure how to get back 😕

no pages will load lol

[hybrid granite]

I guess that sounds like a good thing to remove from a prod env 😂

[orchid moth]

I'm not sure what the "Test" was, but I think it's safe to say it failed ;p

ok I fixed my language in .storage and I'm alive again 😌

[hybrid granite]

lolololol

Can we fix this before someone else has this problem too?

[orchid moth]

Don't know about a fix but I at least filed an issue.

[hybrid granite]

But afaik you cant test translations as you cant download them as normal user

I am wondering now, do translations also get updated at nightlies?

[covert wigeon]

I think the core translations is downloaded from Lokalise everytime images are build: https://github.com/home-assistant/core/blob/e83aa864266a08081180edabf24d93c6e8c665d8/.github/workflows/builder.yml#L67
The frontend is specified as dependency, so it is updated when the new frontend version is committed in core repo

[covert wigeon]

For #3: I think in general, you need to code the translation "key" inside the python codes, and write the English string "value" in strings.json. If the changes is approved, it will be pushed to Lokalise automatically.

If you take a look at strings.json, certain parts of commonly used "structure" inside homeassistant is now automagically referenced, such as config flow, entity states, etc. So probably you need to understand first how this is handled/referenced internally.

[pine cradle]

how to translate official integrations?

[dense garden]

Join the backend translation team: https://developers.home-assistant.io/docs/translations

[pine cradle]

on this subject, please check spook translation Urdu needs a review before merging

[dense garden]

I can't

feel free to help out translating that if you'd like

[pine cradle]

it says translation is locked

https://hosted.weblate.org/projects/spook/#languages

The translation was automatically locked due to following alerts: Could not merge the repository.

[dense garden]

Yeah I was updating

should be done now

[pine cradle]

Spook is getting more spooky before 2024?

done

[dense garden]

Dunno, maybe

[pine cradle]

atleast it will be speaking Urdu before 2024

if Urdu translation gets merged

[pine cradle]

some translation ended up really funny, spook is not your husband (in Urdu) 🤣

[dense garden]

@pine cradle

You should not translate placeholders

[pine cradle]

I will fix it

[pine cradle]

this is how it should be https://hosted.weblate.org/translate/spook/integration/ur/?sort_by=source&offset=61 ?

[dense garden]

Yes, stuff between { & } should not be translated

[pine cradle]

fixed all, please check

[orchid moth]

Are integration names never translated into users language? For example I see a localize key for "component.lovelace.title" -> "Dashboards", but it doesn't seem to exist in Lokalise, or at least I can't find it. Is that just always English? I guess that comes from the name key from the manifest.json?

[hybrid granite]

They are, there is a list of them

[orchid moth]

a list of what where?

[hybrid granite]

https://github.com/home-assistant/core/blob/dev/script/hassfest/translations.py#L27-L46

These are the integrations that have a translated name

[orchid moth]

ah ok, that's a pretty short whitelist.

[hybrid granite]

And I now see that some integrations probably shouldn't be there

[orchid moth]

Yeah I feel like somebody messed that up, as half of those in that list are brand names. Maybe it got confused if it was a blacklist or whitelist?

[hybrid granite]

I know for sure its a whitelist

oh, and apparently you may translate the name if the quality scale is internal

[orchid moth]

hmm ok I was looking for "lovelace" which I assume is internal...

so where is it in Lokalise 😕

[hybrid granite]

"Yes"

Will have a look later

[sly hatch]

 Er zijn nog geen automatiseringen toegevoegd voor dit dienst. Je kunt er een toevoegen door op de plusknop hierboven te klikken.```

'dit dienst' 🙂 But I can't find the translation 🤔

[hybrid granite]

have you checked both frontend and core?

probably frontend

[sly hatch]

@hybrid granite: Found it, but its an annoying one 🙂

Because it's also used for devices, where it's Er zijn nog geen automatiseringen toegevoegd voor dit apparaat. which is correct then

String is: Er zijn nog geen {name} toegevoegd voor dit {type}. Je kunt er een toevoegen door op de plusknop hierboven te klikken.

[pine cradle]

https://app.lokalise.com/public/145814835dd655bc5ab0d0.36753359/ no urdu option in android app?

nor in IOS

https://app.lokalise.com/project/834452985a05254348aee2.46389241/?view=multi

[lilac prawn]

You need to request it on Github.
https://developers.home-assistant.io/docs/translations/
Add a new language

[pine cradle]

https://github.com/home-assistant/frontend/discussions/new?category=localization

Urdu is already enabled for frontend. Android and Ios app doesn't have the option in lokalise

[lilac prawn]

You red the shared link? There is description how to ask for add new language (request for each frontend/iOS/Android/core is individualy).

I created request for iOS (for different language, not for urdu) 2 months ago, a now I need to wait for processing.

[jade quail]

@pine cradle what language code do you wnat us to add for Android?

[pine cradle]

First one

@jade quail Urdu without regions

[jade quail]

added and assigned to you

[pine cradle]

Thanks

Can you do IOS too, since I will be translating it too

Currently I am doing frontend but need to cover both apps too. IOS has better/correct urdu font

[jade quail]

i dont have access to that, you should make sure to follow the process for requesting languages so the team members can be notified.....by chance I saw the comments in here but easily couldve bee missed

[pine cradle]

I did made a request on github discussions too. Which was strange since that request was made on frontend github

https://github.com/home-assistant/frontend/discussions/new?category=localization

[jade quail]

thats for the frontend, the apps have separate requet method

[pine cradle]

Any documentation or request link for that?

[jade quail]

for android users have been submitting the request on github, I think iOS is similar

[pine cradle]

https://github.com/home-assistant/companion.home-assistant

This is android app link?

https://github.com/home-assistant/iOS

[hybrid granite]

/android and /ios

[pine cradle]

https://github.com/home-assistant/android

Found

[spiral jay]

Not sure if this is the right place to ask, but I'm making a custom integration using the new event entity.

Is there a way to translate the event types? If so, how do I declare them in the strings.json/en.json?

[hybrid granite]

There is

Checkout the Philips hue integration

[lost solar]

Is it possible to translate sensor names for sensor created by MQTT Discovery?

[pine cradle]

Do these translation appear live or are these pushed via next PR?

Android app Urdu has been done 64% only few lines left, will it be pushed with next release of android app or will it work now?

[hybrid granite]

Next release iirc

[jade quail]

they get pulled in when we cut a release either production or beta...its part of our github actions

[pine cradle]

https://app.lokalise.com/public/145814835dd655bc5ab0d0.36753359/

[pine cradle]

https://i.ibb.co/NV77yvx/image.png

[hybrid granite]

Nice work 🙂

[pine cradle]

it is just one of 4,

IOS, fontend, core are still left

[mystic nimbus]

Is there a way of putting arbitrary translatable content into the localization json files? I have a (very) long list of possible errors from a hardware device that I expose in a few different ways. I'd like to be able to enable localized versions of those error strings. But they aren't published as simple sensor values or extra attributes as there could be several simultaneous error states.

[lilac prawn]

In lokalise (of HA direct integration) can be added attributes translation?

[hybrid granite]

Yes, but a lot of attributes that currently exist should actually turn into separate sensors, so please don't open an issue for every attribute you see 🙂

[hybrid granite]

Since 2023.12 we support raising an error that can be translated

[mystic nimbus]

Can you give me some pointers on how that's done? I haven't found anything yet that describes how to directly load a localized string from integration code.

[hybrid granite]

You can't load a localized string directly

only the translation key, that corresponds to a static value

[bright mist]

Can I make the options for a enum class entity translatable?

[hybrid granite]

yes!

[bright mist]

Do you have an example or know where it‘s used?

[hybrid granite]

https://github.com/home-assistant/core/blob/dev/homeassistant/components/withings/sensor.py#L555-L561

https://github.com/home-assistant/core/blob/dev/homeassistant/components/withings/strings.json#L194-L202

[stoic pilot]

Is there any possibility to translate native_unit_of_measurement?

E.g. https://github.com/home-assistant/core/blob/00c2ba69f7e4749308a4a4d1f59b43b9c44dd0bf/homeassistant/components/jellyfin/sensor.py#L47 - "Watching"

[hybrid granite]

Nope

[stoic pilot]

So maybe it's better to rename the sensor itself to "Watching" or maybe "{hostname} Watching" and remove the native unit?

ATM the sensor is called sensor.{hostname} which is somehow bad anyways, right? Could lead to collisions, so another one could be called sensor.hostname_2…

[hybrid granite]

This entity follows the device name

so if you rename the device, the entity is also renamed

I think this sensor is look after from the Plex integration

[stoic pilot]

Hm, ok, so I'll ignore that for now…

Thanks.

[vapid path]

Hello, I would like to report a Translation error: EXPECT_PLURAL_ARGUMENT_SELECTOR_FRAGMENT. This error appears in automations when I insert a conditional that uses an input_boolen. My Homeassistant's language is Portuguese Brazil. Thank you very much.

[solid creek]

I am developing a custom integration. I am setting a state attribute which contains the names of weekdays. Is there a way I can localize those strings, so when users show them in their dashboards, it will follow the language of their own profile.

[proper agate]

Hi, anyone has a take on this: https://discord.com/channels/330944238910963714/1211767481501351987 ? edit: uhh, looks like the thread has no context / the initial message. But it's about icon translations & icon property of *Description. If you pass the icon, it will override the translations, which is rather unexpected. The question is, what'd be the best way to handle this gracefully.

[keen edge]

Hi, I'm working on a custom component and have a problem with sensor value translation. The sensor value is -1 and I want to translate this to "unknown". The hassfest-github-action is raising an error: Invalid translation key '-1', need to be [a-z0-9-_]+
Is this a hard requirement from HA or a regex-"bug" in Hassfest?

[hybrid granite]

it's not a valid translation key

instead you should make the native_value of that sensor return None instead

since None will be translated to unknown by efault

[keen edge]

Thx understood, (Only for this one sensor out of a long list the unknown value is -1 and I wanted to keep it as simple as possible.)

[arctic flint]

Hi there. I have the following problem. I'm working on a simple integration that allows to choose a location as a part of the config flow. The location is defined by a key that has a translation, so it works perfectly fine in a selector. Now, I'd like to make the location's name a part of the entry title, so it's visually distinguishable. I currently use a key, but it looks ugly. I neither found a way to provide async_create_entry with a translation key nor to access translations from config_flow.py. I feel that I'm missing something obvious, so I'd greatly appreciate advice on how to get a translation from within async_step_user. Thanks in advance!

[simple drum]

Hi, I'm strugling with translations for the custom component I'm writing. I have a folder with translations, en.json nl.json de.json. But in the frontend only displays the text from en.json no matter what frontend language I choose
This is the content of the English language file:

{
  "entity": {
    "sensor": {
      "home_team": {
        "name": "Home team test test"
      }
    }
  }
}

[hybrid granite]

is your integration a config flow integration?

[simple drum]

not yet

[hybrid granite]

there's your answer 🙂

[simple drum]

I see, I prepared config flow, but not implemented it yet

will try and see

thanks

[brazen elm]

I have the same problem, but my config flow is working. Translations under config and services work, but not under entity. I set the translation_key property of the entities to the respective sensor key in the json files. Snippet from en.json:

"entity": {
  "sensor": {
    "default_smart_home_direction": {
      "name": "Default smart home direction",
      "state": {
        "right": "Right",
        "left": "Left"
      }
    }
  }
}

[hybrid granite]

That looks to be correct

Do you have the code on the repo somewhere?

(also, how does a smart home move in a direction?)

[brazen elm]

Sure, this is the repo: https://github.com/r01k/ha_sunsa.
It's a smart blinds integration and "Default smart home direction" is the peculiar way the manufacturer indicates the default direction in which the blinds close )

[hybrid granite]

Maybe remove https://github.com/r01k/ha_sunsa/blob/master/custom_components/sunsa/sensor.py#L58

[brazen elm]

Ok, there's progress. I removed the hard name property and now the entity states do get translated. However, entity names still follow en.json regardless of the profile language.
Latest translation changes are here https://github.com/r01k/ha_sunsa/tree/translations

[hybrid granite]

They follow system language

[brazen elm]

Oh, I see. Good to know. Thanks!

[thick finch]

I would like translate this to german

We have discovered new devices on your network. Check it out.```

but i didn't find it on lokalise.com

[hybrid granite]

Sounds like a frontend string

[thick finch]

I didn't find it

[orchid moth]

Github org-wide search is pretty good for this:
https://github.com/search?q=org%3Ahome-assistant+"We+have+discovered+new+devices+on+your+network"&type=code
||Spoiler: Its Core||

[orchid moth]

So yeah seems not to be in lokalise, so I guess a developer would need to PR a translation key. You can open an issue for it in the core repo.

[hybrid granite]

Guess we should make default persistent notifications translatable

But afaik there are not a lot of places which utilize this

[orchid moth]

utilize what?

[hybrid granite]

a persistent notification which stays the same

As in, config_entries creates a persistent notification to let the user know there is a new device

I know homekit uses it to show the user QR code to connect it with homekit

and there probably are more

[orchid moth]

Of course 😂
https://github.com/home-assistant/core/issues/107821

[hybrid granite]

and there are some which should be deprecated since they're too specific

[hybrid granite]

HAH

[orchid moth]

Here's also a dup you can close:
https://github.com/home-assistant/core/issues/110245

[hybrid granite]

nice

[thick finch]

Damn, I make a new one ...

[hybrid granite]

Do it and it'll be a speedrun closing 😛

[thick finch]

https://github.com/home-assistant/core/issues/113151

[hybrid granite]

Thanks anyway

[simple drum]

Hi, my integration is config flow ready. But I always get the values from nl.json, even if I switch to English in the frontend

Only if I remove the file nl.json, I get the values from en.json

[hybrid granite]

for entities?

[simple drum]

yes, sensor entities

[hybrid granite]

system language

🙂

It doesn't follow frontend language, they follow the system language

otherwise it would get a mess if you have people using different languages at the same time

[simple drum]

okay, got it, but feeling a bit schizophrenic

thanks for your quick reply

[hybrid granite]

It will at least preserve a lot of consistency over your system 🙂

[simple drum]

the config flow followed the frontend language, that was misleading

so for full testing I have to switch both frontend and system language 😄

[hybrid granite]

like we're talking about the sensor.something

[simple drum]

or '''sensor.iets_anders'''

[hybrid granite]

those follow system language

in the frontend they should still follow frontend language

if you check the entitiesin your system for example

[simple drum]

indeed: when I check the core.entity_registry

"entity_id": "sensor.scheidsrechter",

    "original_name": "Referee",

    "translation_key": "referee",

[hybrid granite]

yes

[simple drum]

restart of hass seems to be required after changing system language

[light rivet]

2 quests here, seek some Dutch convo on

the bottom button should be Uitgeschakeld, or maybe even Uit (which would be much better on eg a Glance card..)

is there an agreement requirement before changing that in localise project

another and bigger change would be changing 'gesloten' on doors and windows to 'dicht'. Imho, the latter would be preferable, as its the 'active' version of the verb, and pairs better with 'open'

it would also be much better on cards that have less space, again, see a glance or picture-glance

[torpid crane]

It is an action right, which in English is disarm so uitschakelen is imho the correct translation

[light rivet]

then all others are wrong....

the others reflect a state, not an action

[torpid crane]

The rest are modes

[light rivet]

well there you go, different reflections on identical buttons.... that is ugly in itself

[hybrid granite]

The interesting thing is that the header says "Uitgeschakeld"

[light rivet]

yes, that is what triggered me

[torpid crane]

That's the state right after the selected action/mode

As in English it will also say disarmed IIRC

[light rivet]

the button could simply say 'Uitgeschakeld' and still be very clear: change to the mode 'Uitgeschakeld'

it would align with the header, and make it less 'translated'...

[hybrid granite]

Hmm

what integration is this

[light rivet]

alarm control panel

manual

alarm_control_panel:

  - platform: manual
    name: Ha Main Alarm```

[torpid crane]

The states for the modes have also armed_ infront, so there the buttons do also not align with the state

[light rivet]

this is an example of a picture-glance that would benefit from 'Dicht' in stead of 'Gesloten'

[torpid crane]

https://developers.home-assistant.io/docs/core/entity/alarm-control-panel

[light rivet]

even says 'off' ... 😉 == 'Uit'

[hybrid granite]

Where do these translations come from

[light rivet]

I suppose they are in lokalise?

[hybrid granite]

Can you put your frontend to english for a second? Then I can find them in the codebase

Like the only english strings I can find for the modes are

        "armed_home": "Armed home",
        "armed_away": "Armed away",
        "armed_night": "Armed night",
        "armed_vacation": "Armed vacation",
        "armed_custom_bypass": "Armed custom bypass",

[torpid crane]

That is the state not the action though

[hybrid granite]

and I don't expect that that is the mode name

[light rivet]

thats better

[torpid crane]

Okay then I agree that the translation of the button is not 1 to 1

[light rivet]

the buttn reflects the state it will get after pressing the button

[hybrid granite]

So I have the feeling that this isn't a backend string

[light rivet]

So Uit would be perfect, as Uitgeschakeld would be rather formal?

[hybrid granite]

I have no preference, but we need to find the string in lokalize first haha

[light rivet]

[%key:ui::card::alarm_control_panel::modes::disarmed%]

[hybrid granite]

frontend indeed

[light rivet]

is the url of that link personal, or can we safely paste it here without disclosing personal account things...

[hybrid granite]

not sure

[light rivet]

ok lets try ...

https://app.lokalise.com/project/3420425759f6d6d241f598.13594006/?view=multi&k=410455894&search=key::ui::panel::lovelace::editor::features::types::alarm-modes::modes_list::disarmed

no harm done I guess if you get that as me 😉

[earnest tulip]

I found the translation I was looking for (my previous question from #devs_frontend-archived) - it was called "Summation delivered" in English, and "Zusammenfassung geliefert" in German, which is a wrong translation in the context of power metering imo. Where's the best way to report translation errors? Or can I contribute myself on Lokalise?

It might not even be a translation error, just a weird phrasing. It's not about delivering a summation, it's about summarising what has been delivered.

[lilac prawn]

For contribute, please follow https://developers.home-assistant.io/docs/translations/

[rustic stirrup]

I have fixed https://github.com/home-assistant/core/issues/114819 on Lokalize for all languages, not only es. I don't speak most of the languanges I fixed it for, so I hope it turned out OK.

I see errors in translated strings was discussed in https://github.com/home-assistant/core/pull/104453, but not deliberately changing placeholders in the default strings. Do the nightly build give any warnings for this?

[rustic stirrup]

Btw, Lokalize validates the placeholders, and blocks saving incorrect placeholders with the error message "Inconsistent placeholders (source vs target)"

[hybrid granite]

Did they always do this?

[rustic stirrup]

Not sure. I don't remember if I've seen that error before or not.

[rustic stirrup]

@hybrid granite I think you can close issues #114819 and #114775 (duplicate)

[hybrid granite]

I'll do when I'm on my pc

[rustic stirrup]

There are several related issues reported in GitHub. I think something should be done about this error.

Some ideas from the top of my head:

• Change log level from error to warning (it does not stop HA/integration from working, hope this will generate less error reports in GitHub)
• Include reference to Lokalise in error message
• Check in nightly build, generate report (this requires someone to follow up on those reports)
• Check custom component strings in hassfest

• Warning from hassfest when changing placeholders for existing strings (probably not very helpful)

[hybrid granite]

2. This can also happen in custom components, and they don't have to use lokalise

[covert wigeon]

Yes, the Lokalise user interface rejects target translation without correct placeholders.

The problem is when the source string has been changed without any translation key changes, just like the case above, new placeholders have been introduced.
If this happens, the old target translation will be only marked as "Unverified", but they are still integrated into new builds.

I think the solutions for core can be one of these:

1. Do not throw exception on placeholders mismatch, just use English gracefully, or
2. Remove "Unverified" (or "fuzzy") translation on Lokalise translation download step in build. I think it's called "nonfuzzy" in lokalise2 cli --filter-data argument: https://github.com/lokalise/lokalise-cli-2-go/blob/main/docs/lokalise2_file_download.md.
   (They are outdated and should not be used anyway, because of many reasons - including placeholders mismatch, changes in meaning, etc)

[rustic stirrup]

Custom components can't use Lokalise AFAIK. All translations are bundled in the custom components. hassfest could check that all translations have all placeholders.

[hybrid granite]

They could, but not every custom integration uses hassfest

[rustic stirrup]

Then we can't help the developer…

[hybrid granite]

But I wanted to look into lokalise more, but I haven't found the time yet

[rustic stirrup]

I think I agree with @covert wigeon - don't log it at all - or potentially as debug

[hybrid granite]

I was thinking myself of creating a script that when all translations are downloaded, just knocks out the ones that don't align

[rustic stirrup]

Then @covert wigeon 's option 2 is better.

If an English string is changed, the translation may be misleading as well

Doesn't matter if it contains placeholders or not

[hybrid granite]

I did not know about unverified or fuzzy strings

as in, whenever I looked a lokalise, everything was unverified

[rustic stirrup]

Hmm - let me check Norwegian 🙂

13894 of 44085 translated keys are unverified…

[hybrid granite]

What makes a string unverified?

[rustic stirrup]

We'd loose a lot of translations if we filter out unverified.

I don't know how to verify

https://docs.lokalise.com/en/articles/3684557-translation-statuses-translated-verified-reviewed-and-completed

If we were to filter out unverified, I think we need to call all translators to action to verify!

[hybrid granite]

what's the state of other languages?

[rustic stirrup]

Expand "Home Assitant - Core" on https://app.lokalise.com/projects

[hybrid granite]

oh right, that also shows unverified

[rustic stirrup]

I'd say it's significant.

Even English have 6

Looks like "Unverified" includes "Untranslated" though

[hybrid granite]

but when the placeholders misalign, it will turn into unverified?

[covert wigeon]

Something like https://github.com/home-assistant/core/blob/dev/script/translations/download.py#L32

[rustic stirrup]

Yes, as the base string must be changed to change placeholders

[rustic stirrup]

And you can't edit translation without aligning all placeholders

[hybrid granite]

So if we only downloaded verified translations, we would have no misaligned placeholders anymore?

(In the backend at least)

(Sometimes the frontend has to combine the data, I requested a feature today to also have this logged since this is usually a bug)

[rustic stirrup]

Yes, that's how I understand it

[covert wigeon]

A "translation target" will be marked as "unverified" (or "fuzzy" in localization terminology) if the "original string source" has been changed (from old string into a new string) which belongs to a single translation key.

[hybrid granite]

How many strings are put in but unverified

is there a way to find out

[covert wigeon]

You can click the Filter dropdown in Lokalise UI, and select "Unverified"

[hybrid granite]

I tried downloading with both "--filter-data=nonfuzzy", and without, and both payload seems to be around 200MB

[hybrid granite]

Placeholders

[brazen oxide]

Hi! I'm working on a custom integration and creating entities based on the configuration I read from my device. Some entities have an empty name, while for others the name is set. If the name is empty I would like to use a default name which will be translated to the users local language. If the name is set I like to use this name instead. My sensor also has values which I like to be translated.

If I set a translation_key on the entities that have a name the name is replaced by the translated name, this is also what is documented in the developers documentation "If the entity's translation_key property is not None and the entity object provides a translated name, EntityDescription.name will be ignored."
https://developers.home-assistant.io/docs/internationalization/core/#entities

How can I change this behaviour? I like my EntityDescription.name not to be ignored when it's set to None.

[hybrid granite]

You do use has_entity_name = True right?

[brazen oxide]

Yes I do, it's True for all my entities.

[hybrid granite]

what do you exactly mean with that last sentence?

[brazen oxide]

This on? "How can I change this behaviour? I like my EntityDescription.name not to be ignored when it's set to None."

[hybrid granite]

yes

[brazen oxide]

How can I change the behaviour of ignoring the EntityDescription.name when a translation_key is set

[hybrid granite]

Yes but I am wondering why would you still have a name? if that one is dynamicaly loaded?

[brazen oxide]

Because I like my entity values to be translated

[hybrid granite]

yes, but that doesn't have to do with the name right?

or do you mean, you have name set to None to have the entity take the device name

and that entity needs to have translatable names?

[brazen oxide]

If I have a name I like that to be used, if I don't have a name I like to have default name which is translated

[hybrid granite]

Can you maybe give a bit more context? I think I start to get what you are trying to do, but I think I need a bit more context to give a good suggestion

[brazen oxide]

I'm reading the configuration of my device from the device configuration. It's a number of inputs and these inputs can have a name set, or not. When the name of the input is set I like to use that name, when the name is not set I like to use Input {input_number} where Input is translated to the language of the user

The inputs can have different values ["clear", "alarm", "tamper", "masking", "bypassed"] which I also like to have translated

I'm using a SensorDeviceClass.ENUM for my sensor

[hybrid granite]

Right

[brazen oxide]

I'm setting translation_key="input"

[hybrid granite]

I think what you can do in the translations, is have two keys

input and input_named

both have states set

but only input has a name set

[brazen oxide]

I thought of that, but then I have to duplicate the state translations

That desn't realy feel efficient

[hybrid granite]

Because if a translation key is set, and no name is found, it will treat it as if translation key was never set (for the name then)

[hybrid granite]

I agree, but the other option would probably overwriting the whole name function of the Entity, and since that's an internal, it might change and break in a future version

It would probably work well, but then the question is, for how long

Not that there is a change planned on that area (from looking at PRs), but it certainly has its downsides

[brazen oxide]

I would actually think that it's more logical to have the default behaviour to use the name if not None and fallback to translation when no name is set.

[hybrid granite]

It hasn't been a problem so far since we never had translations with placeholders

so if this was in core, Input: .. would just have been set as name and not using this kind of logic

I don't have time to test this, but in my memory I think name always wins

[brazen oxide]

I see, but changing the behaviour wouldn't brake anything in core?

[hybrid granite]

you mean changing the behaviour in core or overwriting the logic in your component?

[brazen oxide]

I'm thinking of proposing a change request to change the behaviour in core and overwrite name for the time being.

[hybrid granite]

But did you test it already?

[brazen oxide]

But singe it's documented very specifically to ignore name when a translation is available I guess there has been some design desicion behind all of this

[hybrid granite]

Like I've done a lot of name stuff, and if you'd ask me before this conversation I would have said that the order is name > translation key > device class

now I am in doubt

[brazen oxide]

Test if I can overwrite name?

[hybrid granite]

no, setting both name and translation key

[brazen oxide]

Yes, I did, that's why I'm here to find out if I can change the default behaviour. Because currently my set name is ignored and replaced by the translated default name

[hybrid granite]

interesting

[brazen oxide]

My thoughts exactly

This is what the HA documentation says "If the entity's translation_key property is not None and the entity object provides a translated name, EntityDescription.name will be ignored."

So what I'm experiencing is exactly as described

[hybrid granite]

the only downside with changing it, is that it could break stuff in the process probably

[brazen oxide]

It would show the set name instead of the translated generic name for that entity.

[hybrid granite]

yes, but the thing is, this has been introduced a year ago and it never was a problem until now, so everyone using this has been adapted to using this logic. I can see a reason on why not to change it to not break this expectation

not saying it would make no chance, but just trying to set expectations on that there is also a big risk involved which would cause it to stay this way

[brazen oxide]

I understand that, but I think you agree that it makes sense to use name if available and only use the translated generic name for that entity if name is None?
name > translation key > device class

[hybrid granite]

I think it would make sense since otherwise name isn't used at all

another option you could do is just set the right values in the constructor

if name:
    self._attr_name = name
else:
    self._attr_translation_key = "..."
    self._attr_translation_placeholder = {"id": str(id)}

[brazen oxide]

But the the entity values would not be translated when name is set

[hybrid granite]

oh right

yea then you still have that secondary key

[brazen oxide]

@hybrid granite I've been trying some things and am now discovering that setting EntityDescription.has_entity_name=False let's the entity use ``EntityDescription.namewhile setting it toTrue` let's it use the translation.

[hybrid granite]

but that does make the experience a bit worse

[brazen oxide]

            entity_description = SensorEntityDescription(
                key=f"input{input_.number}",
                name=input_.name,
                has_entity_name=input_.name==None,
                translation_key="input",
                translation_placeholders = {
                    "input_number": input_.number
                },
            )

Makes it work in both cases

[hybrid granite]

for example if you rename the device in the UI you get the question if you automatically want to update all entity ids

[brazen oxide]

Haven't tried that yet

[hybrid granite]

I would discourag this way since it makes the user experience more inconsistent

[brazen oxide]

I see

Adding this to my constructor will override the entity name:

        if entity_description.name != UNDEFINED:
            self._attr_name = entity_description.name

has_entity_name will then be True

[hybrid granite]

Oh that could be a thing

right

the shorthand name is different than the entity description name

And now thinking about it, it might have a bit of logic

because custom components don't have the same as core that they work with the latest, they work with a wide variety of versions

so I think they did not make the entity_description name leading to not force custom components to remove the name to use translations

but that would break users before the translation update

[brazen oxide]

So I can use this backwards compatibility in my favour

[brazen oxide]

Iv'e got an other question regarding translations, can I use references to common strings in a custom integration?

Like so:

{
  "config": {
    "abort": {
      "already_configured": "[%key:common::config_flow::abort::already_configured_device%]"
    }
  }
}

Somehow this does not seem to work when I create a strings.json with above contents.

[hybrid granite]

Nope you can't

[brazen oxide]

That's unfortunate

Thanks for your prompt response

[brazen oxide]

Is it possible to translate the title of the config entry?

[hybrid granite]

Nope

but it is possible to translate the name of a device

[brazen oxide]

Yes, I figured that out already

Other one, is it possibel to call the localisation service directly with a translation_key and translation_placeholders

[hybrid granite]

wdym with localisation service

[brazen oxide]

The translation service

[hybrid granite]

I know, but what do you mean with that

you want to add manual strings

[brazen oxide]

Well, I suppose when I set a translation_key and translation_placeholders in my entity or DeviceInfo there is some generic code doing taking the translation_key and translation_placeholders, do some magic and return a translated string

[hybrid granite]

Yep

[brazen oxide]

Can I call that generic code directly

[hybrid granite]

But I am not sure if that is a standardized thing

You should dive in the code for that

[brazen oxide]

Hmm, might do, but if it's not oficially documented I might actually just accept that not everything can be translated, yet

[hybrid granite]

config entry titles most likely won't be translated at all since its userland usually

if that was what you were still chasing

[brazen oxide]

Yes, I was thinking of a workaround

I'm now using {device_name} on {connection}, and it would be nice to have the on part translated. But maybe I'm taking it too far

[hybrid granite]

@

😛

[brazen oxide]

The problem is that {device_name} is not unique, it's basically the model of the device and if you have two of the same models just using the {device_name} is not suficcient to keep them apart

[hybrid granite]

Just put it to something the user can recognize, they have to rename it to something they can remember

[brazen oxide]

Yes, can't have it all

[hybrid granite]

for example when I register my switchbot curtains, they are also called "Curtain A1B2" and "Curtain C3D4"

Yea that requires some FAFO to know which one is which and rename them

[brazen oxide]

I know what you mean. I always rename my device names to something that makes sense, but the config entry names not always

Anyways, thanks again!

[hybrid granite]

if the device name is not set and its a primary device, the device will have the same name of the config entry

so you have to rename one thing

[brazen oxide]

And changing the device name will also change the config entry name, or only the other way arround?

[hybrid granite]

only the other way around iirc

never tried

I know a lot about the naming and translation, but on my instance everything is named like 💩

[brazen oxide]

So it will not rename the entity names when I rename the config entry I suppose

Ok, I will play around a bit and not bother you further. It's not the end of the world if I can't translate everything

[naive reef]

hi,
i'm trying to add a placeholder for an error
in strings.json i added placeholder {error} :

"error": {
  "cannot_connect": "[%key:common::config_flow::error::cannot_connect%]: {error}"
}

pre commit exited with error:

Integration openweathermap:
* [ERROR] [TRANSLATIONS] Invalid strings.json: the string should not contain combined translations for dictionary value @ data['config']['error']['cannot_connect']. Got '[%key:common::config_flow::error::cannot_connect%]: {error}'

I don't very much understand what it wants, does it mean I can't use common key for an error with placeholder or smth else?

[hybrid granite]

You can combine translation references with extra text

[naive reef]

got it, thanks

[polar ferry]

@brazen oxide I converted your message into a file since it's above 15 lines :+1:

[hybrid granite]

Why don't you just revert the state in the integration itself

[brazen oxide]

How?

There is no option in the Cover entity to invert the behaviour

[hybrid granite]

No i mean

When the thing is open, call it open

Like

I dont see the reason why closed should be open

And vice versa

[brazen oxide]

Because the arrows in the UI would the be reversed

So clicking the up arrow would then open the screen

[hybrid granite]

Right

[brazen oxide]

So I'm working around that by using translations for the entity state

[hybrid granite]

Honestly, I'd roll with that, since the other way around also doesn't work well with voice assistants and cards

But you can't translate the state afaik

[brazen oxide]

Best would be if the Cover entity would implement some way to invert the behaviour, but all efforts in that direction lead to nothing

[hybrid granite]

But then again you would have correct arrows, but the naming would be strange

at this point to make it perfect I'd almost advice you to check if you can figure something out in the frontend

[brazen oxide]

Hmm, I'm not very familiar with front end development

[autumn cargo]

This proposal might have something for you. Unfortunately I don't know if it will be implemented https://github.com/home-assistant/architecture/discussions/979

[brazen oxide]

Thanks, will look at it

[brazen oxide]

Hi! Getting back to my earlier question about using translations to work around opposite behaviour of Covers and projector screens

Did I understand correctly that to use voce commands there is not being looked at the translation file?

And that if I translate the closed state of my Cover entity to something else that translation can not be used in a voice command?

I don't use voice commands, so no experience myself

[hybrid granite]

Yes

[ashen sandal]

apologies if this is a FAQ, I tried searching for it, but might not be looking in the right places: for a custom component where do I put strings that need to be localized but are not allowed in translations\[xx].json?
I have built a couple of custom integrations now, which of course I want to have localized. I have, however, misused the translations\[xx].json files a bit and put stuff in there that is not related to services, config flow, options flow, etc.
For example: I have a set of default presets (grouped in the language file under 'defaults') that I ship with the integration and the names of those presets need to have a localizable name.
Of course hassfest now doesn't like this and says extra keys not allowed @ data['defaults'].
However, where am I supposed to put these things? My own language file that is separate from what hassfest looks at? I'd prefer to keep everything in once place.

[hybrid granite]

What do you use it for then?

[ashen sandal]

not sure what you mean, but here's an example file from one of my custom integrations: https://github.com/jeroenterheerdt/grillbuddy/blob/main/custom_components/grill_buddy/translations/en.json.

I did put both things that belong here in the file (config/options flow labels), as well as stuff such as my defaults that hassfest now breaks over (https://github.com/jeroenterheerdt/grillbuddy/blob/3fdae065bce0e4dc9d563cc4ab77ca3685027339/custom_components/grill_buddy/translations/en.json#L31). My question is about where I should put those latter category of labels.

[hybrid granite]

But what are those labels in the first place

[ashen sandal]

they are defaults that my integration ships with. Based on what selections the user makes in my custom panel that my integration ships with I show these values as extra attributes in the sensors my integration provides. So they are not really part of the panel UI (I have a separate language file for that), so I put them in this file.

[hybrid granite]

So they are values of the extra state attributes

[ashen sandal]

yes. I right now moved them all to the front-end language file, so hassfest at least doesn't compain, but since these are used in python I thought it is kind of weird I am not allowed to have them in my translations file

[hybrid granite]

Why not create separate entities out of it

[ashen sandal]

I need a little more help to understand how that is going to help. I still would need to pull the textual descriptions from somewhere even if they were different entities.

[hybrid granite]

Sensors can have a translatable state

[ashen sandal]

I know, but the translation still comes from a file that I need to read.

[hybrid granite]

But it's a file like en.json right

[ashen sandal]

correct - it is in the en.json file right now., so I am not seeing how that is going to help things. It will still be in the file that hassfest checks and doesn't like to have other things in.

[hybrid granite]

It's still in that file, but in a different place

One that hassfest does like, as core integrations also do that

[ashen sandal]

what's the place in that file I can use then?

[hybrid granite]

Use an enum device class and provide the state in lower case

And then you can put the names as entity translations

Withings has one

[ashen sandal]

thanks, I'll take a look at that

[polar ferry]

@supple phoenix I converted your message into a file since it's above 15 lines :+1:

[supple phoenix]

TL,DR: can translation placeholders be updated in functions like _handle_coordinator_update ?

[hybrid granite]

It can only be used for names, not for states

this would best just be 2 states

[tranquil wigeon]

Heya! Ive noticed the German translation for the ZHA > Add Device page seem to not be a good match for what should be said. I lack the experience to figure out what to do with it, maybe some of you could assist with figuring this out.

The first sentence Make sure your devices are in pairing mode. Check the instructions of your device or {documentation_link} on how to do this. wrongly inserts die Dokumentation into {documentation_link} where it should be der Dokumentation instead. Personally I dislike this sentence as the translation for on how to do this. as wie das geht. is pretty blunt even for the informal language style that should be chosen.

The second sentence would be the message that shows up inside the same page when no device has been found. No devices were found, make sure they are in pairing mode and keep them awake while Home Assistant is searching. I removed der from der Home Assistant but the second thing to notice is the translation of pairing mode. While the previous sentence uses Pairing-Modus, this one uses Kopplungsmodus . Neither is wrong but they differ in their style which looks a bit odd. Personally the whole part about make sure they are in pairing mode and keep them awake while Home Assistant is searching is redundant to the previously shown statement of Make sure your devices are in pairing mode. in probably any of the available languages

[autumn cargo]

Hi 👋! Have a look here https://developers.home-assistant.io/docs/translations once you are registered to Lokalise you can search for eg. "zha" and see / fix all translated terms.

[tranquil wigeon]

Its more intended to be a question about what actions should be taken (and maybe some help for the translation placeholder adjustment)

[orchid moth]

that placeholder is a bit of a strange one as it's embedding a second translated string inside the placeholder. I believe it comes from here:
https://app.lokalise.com/project/3420425759f6d6d241f598.13594006/?view=multi&k=437313159&search=key::ui::panel::config::zha::add_device_page::pairing_mode_link

so if you want to change the content of the <a> you can just suggest the replacement there

[tranquil wigeon]

I see! If id encounter such thing somewhere else, how would i figure out those search keys. Or is it just by looking for the literal and then referencing the key from the suggestions

[covert wigeon]

You just need put the English string into the top right search box.

[tranquil wigeon]

i see

[orchid moth]

I just grepped in the source for documentation_link and found it.