A Micro-ISV diversion

While I continue developing my other major software product I have after a few hours of pondering decided to start developing another one concurrently. This one will be purely open-book development: I will blog about the whole process, gather feedback and ideas from others all the time, and hope to attract a small number of people interested in the tool and test-driving it for their own needs.

I want to develop the ultimate localization tool for .NET software developers and the translators they work with.

That's right. Am I serious? you wonder. I am. There are a few buts I'm ready to address right now, however I'm soo looking forward to hearing more: yours (before it's too late)!

But there are already existing mature packages on the market!

Yes, and they serve everyone and their dog, supporting .NET among 20 other technologies. Consequently, these products are priced between $ 500 and $ 5000 per seat, whether you need the full-blown suite including Delphi and Java and MFC support—or not.

But the .NET Framework and all IDEs already support us with basic localization tools!

While the .NET Framework comes with the basic technological foundation for localizing an application easily (namely the RESX file formats and editors readily integrated in the major .NET IDEs), there are a few points that I think are worth addressing:

• Ever localized forms or controls using the Visual Studio .NET designers? It is a messy process, particularly when you change sizes or other properties for controls in another language, intending to apply your change across all cultures, later realization you were accidentally working within a certain culture. Change your forms or controls substantially, delete or add controls, after already having localized parts of it and everything becomes a nightmare. It happened to me repeatedly that the designer fails to display the control and/or form again, or lost track of some binary property values (such as images) that just got lost in the ether. Attach a couple of cultures to a form or control and the designer gets slower, too. There has to be a better way.
• Ever localized forms or controls using the WinRes tool? (This is what you give translators who do not have Visual Studio and/or who you don't want to entrust with your entire projects with all other files etc.) The point is that this is only a very basic resource editor but it does not support the process as a whole. A translator might simply forget to check whether there are sub-menus in sub-menus of an item on a ToolStrip. Or think of localizable properties of items that are not directly clickable on a designer surface, such as ListViewItems.

I think that, just as documentation, localization should be somewhat separated from development, whether the person doing the stuff is the same as the developer or not. The whole "integrated" part of integrated development environments is a bit overdone, I think. It results in hacky tools that are fine for three-line demo applications but fail to provide streamlined support for the actual process and its many requirements. I don't want localization to interfere with my development, whether by having to switch between coding mode and translation mode or by having the inadequate, "resource"-centred rather than really localization-centred integrated tools destroy my forms/controls etc.

But the developer market is unthankful and you will have to face the not-invented-here syndrome!

One is typically advised against the market for developer tools along these lines, but I do not really buy into it. Sure, selling to developers may be tough, but selling to any particular market or segment has its own intricacies, I believe. Selling to consumers must be tough! Developers are used to, and keen on, trying new tools and interested in improving their processes using software. You do not have to first sell them on the idea that software can improve and streamline their work, something that many other industries still have to do. There is no, or much less of a to cross.

Any more Buts?

So these are the three most obvious issues I have considered, apart from keeping at bay the burning vision of a fantastic product that I have in mind. It may soon take over, but first I'd like to hear your take on this.