Skip to content

Conversation

@Nis-Knowit
Copy link
Contributor

Description
This PR introduces two improvements to the Translations Dashboard:

Search by Translation Value
Previously, the search functionality only supported searching by translation keys. With this update, users can now search within translation values as well, making it easier to locate specific translations based on their content.

Show Translation Values in List View
Instead of displaying only a checkmark to indicate the presence of a translation, the list view now shows the actual translation value. This provides better visibility and context when managing translations.

These changes have been requested by multiple clients and represent a valuable quality-of-life enhancement for editors and developers working with multilingual content.

How to Test
Navigate to Settings → Translations in the Umbraco backoffice.
Use the search bar:

Enter a key → confirm results match existing behavior.
Enter a value → confirm results now include matches based on translation values.

Check the list view:

Verify that translation values are displayed instead of just a checkmark.
Confirm that the layout remains clear and usable.

Why This Change?
Managing translations often involves finding specific phrases or words rather than just keys. By enabling value-based search and displaying values in the list view, this update streamlines workflows and improves usability.

@github-actions
Copy link

Hi there @Nis-Knowit, thank you for this contribution! 👍

While we wait for one of the Core Collaborators team to have a look at your work, we wanted to let you know about that we have a checklist for some of the things we will consider during review:

  • It's clear what problem this is solving, there's a connected issue or a description of what the changes do and how to test them
  • The automated tests all pass (see "Checks" tab on this PR)
  • The level of security for this contribution is the same or improved
  • The level of performance for this contribution is the same or improved
  • Avoids creating breaking changes; note that behavioral changes might also be perceived as breaking
  • If this is a new feature, Umbraco HQ provided guidance on the implementation beforehand
  • 💡 The contribution looks original and the contributor is presumably allowed to share it

Don't worry if you got something wrong. We like to think of a pull request as the start of a conversation, we're happy to provide guidance on improving your contribution.

If you realize that you might want to make some changes then you can do that by adding new commits to the branch you created for this work and pushing new commits. They should then automatically show up as updates to this pull request.

Thanks, from your friendly Umbraco GitHub bot 🤖 🙂

Copy link
Contributor

@AndyButland AndyButland left a comment

Choose a reason for hiding this comment

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

Looks good @Nis-Knowit and I've tested it out and can confirm all works as you describe. I left a couple of minor inline comments about updates that aren't strictly needed for this PR.

I'm not sure though that this is going to be appropriate for all sites. Whilst I can see it may work nicely for smaller sites with only 2 or 3 languages, not too many keys and translations and each translation being quite short - I fear if any of those things aren't correct it may not work too well.

Specifically:

  • The database query is less performant now. The previous filter on "starts with" for the key could use an existing index, but the new one can't. There's also now an EXISTS subquery on every row, which will be slower on sites with a lot dictionary items and translations.
  • The JSON payload has increased with all the translation being passed - with lots of languages, translations and long phrases, that could be a concern.
  • The table UI isn't really designed to display many columns (if lots of languages) with a lot of text (with long phrases used in translations).

Let me know what you think, but I feel this maybe something that would work well on a specific project - or as a package someone could install - but may not be a suitable default for everyone.

@Nis-Knowit
Copy link
Contributor Author

@AndyButland I'm thinking about making it a configuration parameter, which can be enabled to allow search in values, and then remove the frontend changes, the value search is really what i've been missing on almost all of the projects i've been working on through the years, and i know that clients are missing that feature aswell. I will make a new PR and reference it here when ready :)

@AndyButland
Copy link
Contributor

Yes, I was wondering if that might be an idea too - so we don't overwhelm projects that will not suit having the values presented and incur a slower rendering or searching experience; but for projects with a smaller set of languages and items, they can take advantage of it.

@Nis-Knowit
Copy link
Contributor Author

@AndyButland I've made a new PR here #21200 and will close this one :)

@Nis-Knowit Nis-Knowit closed this Dec 18, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants