#Translations

1 messages · Page 1 of 1 (latest)

wintry gull
#

Chill chat about the development of translations across the Home Assistant UI.

Please try to limit legitimate support issues to #1257019582112334014. 🙏

rigid marlin
#

"Unknown" is a string that is used many, many times across HA. There is a common key in config_flow that translates to "Unexpected error" but there is a need for a global translation for "unknown" to "Unknown" also - as a state perhaps.

brave heath
#

There is also a common::state::.....

#

Unknown could be added there

#

however, "unknown" as a state string would be invalid for integrations to provide

#

integration should set their state to a None value in case the state is unknown, the state engine will handle it in that case

#

With that in mind, the suggest common state tranlation string "unknown" would be unused

rigid marlin
#

OK, I will let my integration (Miele) distinguish between "unknown" as None and "unknown" as in "Unknown code" when the API presents a code that is previously unknown to the integration.

brave heath
#

The state string "unknown" should really not be used by integrations

rigid marlin
#

I realize that, and will act accordingly.

jovial haven
#

Do "Unverified" translations not get shipped?

#

e.g. this key here, has had this translation since 2023.

image.png
#

but the english was recently changed to reference a common key.

#

And I see the translation is no longer present in the shipped json, so this has reverted back to English for users of that language.

#

The only thing I see is suspicious is that it highlights the button that says "Mark as verified".

#

(this is Norwegian Bokmal)

wraith breach
#

They no longer get shipped indeed, for core and frontend.

swift dawn
heavy snow
#

Hi there, I'd like to ask for guidance with localizations. I'm reviewing Polish translations on lokalise and would like to know if the state (for example, common::state::open) should be capitalized (as in English) or if it is up to the translator? I'd like to keep things consistent and follow the rules (if there are any). In my opinion, the state should be capitalized.
@hollow harbor, sorry for mentioning you directly, but you did most of the translations, so I'd like to get your opinion about the potential change.

static kindle
hollow harbor
static kindle
#

Btw since we're discussing the Polish translation, then I think we should find a good translation for "Dashboards". It is the only non-translated (or rather monstrously half-translated) term that we have, it would be good to finally fix it.

hollow harbor
#

This one was also discussed on the FB group 😁 There was a vote on this topic. We didn't find a good Polish word for Dashboard

#

But of course we can try once again, good idea most welcome

heavy snow
heavy snow
hollow harbor
#

„Pulpit” is far from perfect IMO. Maybe „Panel”?

static kindle
#

I was also thinking of "Panel", I think it is close enough in meaning.

hollow harbor
#

I think I've migrated all "Dashboard" to "Panel" in Polish

neat moon
#

Hello, I would like to help translate the ‘Victron Remote Monitoring’ component into French. Could you please provide me with a link?
i have fr.json for this component

jovial haven
#

All these links are down, doesn't seem like we can onboard new translators at the moment.

jovial haven
#

@neat moon - seems to be working again now.

neat moon
#

+1 it's ok today 😉 THX

steep gate
#

I've been working on a Matter Semantic Tags to Text conversion helper function and need some assistance with translations. The function is not entity-specific but is intended for use across entity types - i.e., wherever a Matter semantic tag might be found. Its pretty simple - it just does "gets" on numeric Namespace IDs and tag IDs to retrieve a text string. See https://github.com/jvmahon/HomeAssistantCore/blob/27465b89012720c99e28db18e1309dc59d03c25e/homeassistant/components/matter/semantic_tagging.py with the main function at lines 352-365.

Is it possible to use translations with a helper function like this? From what I can see here: here: https://developers.home-assistant.io/docs/internationalization/core/ in order to use translations, they item-to-be-translated must fall within one of the set categories (e.g., a title, config, device, entity, etc.). My function doesn't seem to fall within those categories, so I think the translation service is not available for it. Is that correct? Thanks.

rigid marlin
#

I have found a problem or opportunity for improvement in our use of Lokalise.
A member of the community has changed all 64 occurrences of "Bekräfta" (="Submit") in backend in the Swedish translation to [%key_id:133450972%]. This key refers to a key in frontend. While this works in the Lokalise UI, it does not work when the translation file is exported to HA, [%key_id.... is displayed literally in HA.
I see a couple of solutions:

  1. To create a key in top-level strings.json and update the references in integration's strings.json.
  2. Fix the export that creates xx.json translations files for backend so that it can fetch keys from frontend translations.
  3. Revert the changes in Lokalise.

Ideas are welcome.

image.png image.png
pastel seal
#

Interesting that it just does that cross project lol

#

I did not know that this was a thing

#

In general we disallow substituting strings in core

#

We don't really have a way to disable these though

image.png
#

If this just worked in lokalise that would be fine in a way, but if we actually download the [%key variant, that's problematic

rigid marlin
#

The current Swedish translation is unacceptable though. Do you think these keys should be reverted in Lokalise?

image.png
pastel seal
#

I think we should revert them for now yes

#

But I am more looking for a way we can avoid this altogether

rigid marlin
#

OK, reverted!