Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

Minor improvements to service call descriptions. #20733

Merged
merged 2 commits into from
May 8, 2024

Conversation

karwosts
Copy link
Contributor

@karwosts karwosts commented May 5, 2024

Proposed change

Two small changes:

  1. Don't show 'on' when service does not have a target:

image

  1. Allow taking entity/device ids list from data if target is not defined, for services that don't use the target picker.

image

Type of change

  • Dependency upgrade
  • Bugfix (non-breaking change which fixes an issue)
  • New feature (thank you!)
  • Breaking change (fix/feature causing existing functionality to break)
  • Code quality improvements to existing code or addition of tests

Example configuration

Additional information

Checklist

  • The code change is tested and works locally.
  • There is no commented out code in this PR.
  • Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

silamon
silamon previously approved these changes May 6, 2024
Comment on lines 3251 to 3253
"service_based_on_template": "Call a service based on a template{hasTargets, select, \n true { on {targets}} \n other {} \n }",
"service_based_on_name": "Call a service ''{name}''{hasTargets, select, \n true { on {targets}} \n other {} \n }",
"service_name": "{domain} ''{name}''{hasTargets, select, \n true { on {targets}} \n other {} \n }",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we split each translation in two keys to simplify translator work?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We've already got dozens of keys using a similar pattern. Should I consider {select} as always discouraged? Having two translations for the same sentence seems cluttery, and this does not seem exceptionally complex, but I will follow guidance if we have some.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've introduced many of these, and the general feedback from those pull requests was to split the sentence when there were multiple selects, nested selects or it became pretty long in number of characters.
If it's really needed, I would suggest to introduce keys for when no target exists, so the existing translations don't need to be translated.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, agreed, it saves missing translations (old ones would need to get updated) and makes it a bit easier for translators (although I'm surprised how well it goes actually!)

@silamon silamon merged commit 9e9cb15 into home-assistant:dev May 8, 2024
13 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants