This one is totally my mistake. I own up to it. I released my latest app to a very good beta tester who happens to be German and is, quite frankly, the best beta tester I’ve ever worked with. So he writes to me and says that while the app works great, he’d really like it to be in German. This obviously would have been a lot easier if I had thought about it 6 months ago rather than 6 hours ago. So I started doing some research.
The RS recommended way is to create a dynamic string constant and export it to Lingua so the various languages you want to support are added. Again, this would be fine if I had started with this 6 months ago. Going back and taking all the control captions and making them a constant isn’t hard, just very, very time consuming.
Another big drawback to the RS approach is that you have to have create a separate executable (and subsequent installer packages) for each language. With IDE scripting this isn’t a horrible solution but it’s less than optimal.
An ARBP member uploaded a Dynamic Localization example project to the ARBP source code repository last week that is interesting. It uses a database to store the strings in language pairs so as long as you have your db populated it would allow the user to change the language on the fly. It uses subclassed controls to query the database and replace the strings. This allows the user to switch the language of choice on the fly. I’d make some changes (naturally) to allow users to add their own language if they want and make it cross platform (if I can).
An issue that isn’t addressed in either method is dynamically changing controls widths based on the size of the text. Some of the Northern European languages can be quite long when compared to English and some of the Asian ones can be very short. Apple handles this by having all of the supported languages in separate UI files in the application bundle and the developer can adjust UI dimensions based on the language. For the end user it’s great but for the developer it can be somewhat time consuming (assuming they do it at all). Microsoft handles it similarly (without the bundle obviously).
Assuming I want to do it the RS-preferred way, I’d have to go through the project, control by control, copying and pasting the string into dynamic string constants. Not undoable but it is time consuming. I think this is one of those places where IDE hooks would come in handy.
It would be awesome to have an IDE hook that allowed me to iterate through the project, find strings in control captions, add them into a module (after searching to see if it already existed) as a dynamic string constant and then replace the control caption with the constant. I would also like to do this with strings in code as well and this one’s a bit trickier because of SQL statements and the like. This is just one example of what IDE hooks could do but it would save me a boatload of time.
IDE hooks unleashes the imagination of the community. It can provide solutions to common problems that RS doesn’t necessarily think are problems, or are so far down on their priority list that it would be years before they get to it. I first started thinking about this problem was years ago before exception handling was added to RB and the only way to add error handling at the method level was to add it yourself. At the time I was relatively familiar with VB6 and a couple of utilities that added error handling to every method in every object with a click of a button. The only solution then (and now sadly) is to use the XML format and create an app to do it for you, or to break the RB EULA and use some of Thomas Templemann’s projtools code.
RS’ argument for not having IDE hooks is simple. They feel that they’d be held responsible for IDE hooks gone awry. Despite what I think, a vast majority of RB users wouldn’t understand the difference between RB code and the hooks – if it runs in RB it’s RS’ responsibility. For an example, all you have to do is look at the complaints about RB that are really a plugin problem.
An example solution already exists. Look at Apple and duplicate what they did with the iPhone. If you want to play in the RS’ sandbox (the IDE) the IDE hook has to be approved by them and distributed by them. The trick is determining how IDE hooks get tested and approved and what happens in every new release of RB.
Personally I think this approach could unleash the power of RB in ways that RS could never imagine or do on their own. It instantly creates a third-party market for developers and could (potentially) be an additional revenue stream to RS (probably not a big one in my opinion).
So what say you on IDE hooks? Am I missing a solution for my localization problem?