Many components have properties that are meant to provide strings that a user either sees or hears and as a result, needs to be translated.
Describe the solution you'd likeI see we have the ability to configure some props via the plugin settings, but is there a pattern to how we choose which are included? Or is it just need-based?
I wonder if there is a way we can make the available settings dynamic so that any prop on any component can be configured application wide without the need to code for it. Add a prop and it becomes available. My use case primarily centers around settings translated strings once for the application, but I feel that if being addressed, there is no reason not to address it for any prop.
Describe alternatives you've consideredIf this is not feasible, are PRs to add more settings typically accepted or are there specific requirements as to which props or types of props would be accepted?
Additional contextNone
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4