I am Joannes Vermorel, founder at Lokad. I am also an engineer from the Corps des Mines who initially graduated from the ENS.

I have been passionate about computer science, software matters and data mining for almost two decades. (RSS - ATOM)


Entries in tools (10)


ResxEditor reloaded - version 1.2 released

They were a couple of long standing issues with ResxEditor. Most of them were actually reported as comments on the blog post of the initial ResxEditor release. All of those issues are now fixed. Bug fixes and new features are detailed on the ResxEditor page.

Special thanks to Nick Pasko for carrying most of the work and finding a solution to get rid of the previous cell saving behavior that was driving translators nuts.


Wiki misuses (collaborative tools, part 1)

Great software development requires great tools; but tools do very little in themselves if the craftsman lacks the proper skills. In my (limited) experience, I have noticed that collaborative tools are often extremely useful (i.e. provide strong productivity boosts) while also being quite hard to master.

There are far too many collaborative tools to discuss for a single blog post; I will start with the wikis.

Why do you need a wiki?

There are many other ways to communicate and information within a development team, namely person to person talk, email conversations, source code comments, discussion boards, blogs, instant messengers, phone calls ... and the list goes on. There is no magic in wikis; they won't be a substitute for all that.

Let's start with some wiki misuses, i.e. the kind of things that does not work very well with wikis. I am not saying that it is not possible to use a wiki in the situations listed below (it always "possible"); but I feel that those situations are simply ill-adapted to be handled by wikis.

Wiki-based documentations are poor documentations (probability = high)

A wiki is not a substitute for proper reference documentation. In this domain, two of my poorest user experience while trying to get some reference documentation were the WordPress wiki and the JotSpot wiki although I am quite a fan of those two products. What's the problem here? Well, quite simply there is simply no reason for the consumer to contribute to the reference documentation (I say "consumer" to refer to whoever is consuming the documentation). Therefore, do not expect any interaction at that such level.

As a secondary point, it can also be argued that a reference documentation requires to be highly structured usually following closely the source code design itself); otherwise it's just a pain to navigate through. Wikis do not encourage (nor provide any automated mechanisms) to support such structures. In this respect, one of best software documentation that I have ever encountered is the ZeroC Ice documentation (but I am moving away from the topic of this post).

Wikis aren't that good for open diffusion (probability = high)

I know that Wikipedia is living counter-example of the title of this section. Yet, wikis are on average quite inappropriate for open diffusion. When I say open, I mean referring to a wiki that is not restricted to the development team.

A primary issue with wiki is that they aren't that much appealing in terms of layout and navigation. Yes, it is possible to customize the appearance and the navigation system of a wiki, but by doing so, you're going back to regular website development. The Math.Net open-source project is quite illustrative in this matter. Have a look at the Math.Net project page vs. the Math.Net wiki. Which one of those two pages looks better in your opinion? OK, I know you're not going to look at those pages, so just trust me.

A second issue with wiki is that the information is usually rougher and less structured compared to classic "static" page. This point is not an issue in itself, enabling some kind of fuzzy teamwork is actually one of the main benefits of the wiki. Yet your wiki is likely to act as information pollution for the occasional visitor.

The last issue with open wikis is that they are putting boldness requirements quite high. Indeed, a main challenge with wikis is to get people involved. This point is true for almost every collaborative tool. Self-confidence is one of the strongest hindering factors when it comes to wiki writing. By opening your wiki, you are putting quite a lot of pressure on your potential contributors compared to the internal wiki situation.

More on Good wiki management soon, stay tuned...


Typo hunting: get some weapons first!

It's just too hard to spell check your text by hand (or it requires an unreasonable amount of time). Before you actually get a spell checker, you might not even realize how many typos you produce. I have just downloaded today the FireFox RC1 that includes a web form spell checker. My first target for typo hunting was an intranet wiki I am working on. I feel that I won't ever go back to a browser that does not provide such a feature natively.

My second target for typo hunting was the source code of a Asp.Net application I am currently developing. Since Visual Studio 2005 does not provide a native spell checker (shame! such feature should have been implemented years ago), I have used the MailFrame CodeSpell product. CodeSpell has a really nice VS 2005 integration. On the minus side, the dictionary is a bit light at the present time (nchar or aspx not being part of the default dictionary for example) and I did experience of a few crashes while playing with the custom user dictionary.

A funny aspect of applying this source code spell-checker was to discover that 3rd party [*] XML documentations present in my .Net solution were no less typo-crippled than my own code. If automated spell-checking is not part of your development process, well, it should.

[*] Elmah and Telerik are both advised to get some spell-checking tools :-)


Resx2Word, when simplistic is not enough

RESX files are great (and simple) containers of textual resources for your .Net/Asp.Net applications. It's especially useful if you're planning to translate your application into multiple languages (PeopleWords has been translated into 13 languages all textual content being put into RESX files). Yet, using Microsoft Visual Studio as a RESX file editor is quite an overkill solution for translators (whoses programming often equate zero since it's not their job anyway). In a previous post, I was discussing ResxEditor, a simplistic and stand-alone RESX file editor.

Où que tu sois je te retrouverai, car si tu ne viens pas à Lagardère, Lagardère ira à toi! (If you do not come to RESX, RESX will come to you)

Yet, I am still not entirely satisfied by ResxEditor. Indeed, during the translation of process of PeopleWords, half of the translators (smart and educated btw) were surprised by the sheer existence of other text editors beyond MS Word. I imagine that this kind of thing can happen if you have been working your entire life with MS Word.

As a result, those translators, no matter how many times you tell them not to use Word, they can't resist the urge and the RESX file gets opened and translated through Word ... and then funny things happen. For example, I have now several translations of the Microsoft RESX instructions Microsoft ResX Schema, Version 2.0, The primary goals of this format is to allow a simple XML format that is mostly human readable. ..., the large XML comment created by VS by default at the beginning of each RESX file. This XML comment is going to one of the most translated piece of MS literature (I do not think that the VS engineers were expecting this when they wrote those RESX instructions).

In order to escape the curse of the RESX instructions translation, I have just released Resx2Word, a RESX to MS Word converter (and vice-versa). Naturally, it's not possible to translate generic MS Word document to RESX, only MS Word document generated by Resx2Word can be converted back into RESX by Word2Resx. Any feedback?


A translator-friendly RESX file editor

A newer version of ResxEditor is now available, see my lastest blog post on this matter.

In a previous post, I was giving some details on the RESX format from a translator-friendly viewpoint. Actually, after proof-testing the XML concept with a few translators, I came up with the conclusion

The most brilliant Uzbek-Azeri translators do not speak XML. Do not seek any explanation, it's just a fact.

XML has a logic which is totally alien to the average translator. The answer to the question Why can't I freely insert < and > characters? simply does not match the average translator skills. Therefore, I have decided to come up with a more simple and elegant solution.

I have published a simple Resx Editor utility that comes as a stand-alone exe file. This application is free (yet not open-source, although I am considering the option) and will remain free.

Available features

The ResxEditor is a simple quasi-wysiwyg editor; at least the raw XML is kept hidden from the translator view. The features are limited to the bare minimum Open, Save and Save As, plus a text size adjustment option.

Features not available (also they should)

I have not included a Print feature (yet). Whether it is a must-have feature will depend on the feedback that I get. Actually, one of my objective is to keep this editor as simple and small as possible.

If there are features that you would really want to see in Resx Editor (or bugs that you really would not), feel free to post a comment.

Page 1 2