Other times you know just the right thing to do straight away.
A request came in for String Resource Visualizer to add support for a language other than the default.
Here's a screenshot of the current version in action.
This is all good and useful, but the request is to help developers whose first or preferred language isn't the same as the default culture for the app's code.
This is a request I wanted the tool to be able to support so I started to think about the different ways to implement this.
Then I stopped.
There's one key thing to define: the language to use in preference to the default.
Secondarily it might be possible to have rules about which languages to use for which solution, or order of preferred languages, and possibly other configurable options.
Rather than make things unnecessarily complicated I chose to use the existing system for handling settings. I then chose to make the change as simple as possible. Opting to only support a single configurable option with reasonable fallback options as there's no point in creating more complex functionality until it's wanted.
I've been thinking a lot about not just jumping to the first solution that comes to mind and trying to look at multiple possible solutions to find what's best. It's just that this didn't seem like the right opportunity to explore this. Some times the first solution is good enough. Especially, when following existing patterns.
As of the just-released, version 1.5, there's now a way to also see the resources for a language/culture that isn't the default.
This will cause resources in the specified language to be shown when they exist. The default is then used as a fallback.
Hopefully, this image provides a good example of this in action.
The new version is available in the marketplace now.
If you're an existing user and don't need this functionality you may still benefit from updating as there are also performance improvements in this new version.
0 comments:
Post a Comment
I get a lot of comment spam :( - moderation may take a while.