Tag: roadmap

As I noted in my first published roadmap for Felix, my plan was to make some minor improvements, then implement networking support for Felix in July, and a translation history feature in August.

I completed the first part of the roadmap with the release of version 1.1, and the second part (network support) with the release of version 1.2. My original plan for this month was to implement translation history support in August, then do minor improvements for a month or two after that.

My queue of “minor improvements,” however, has grown pretty large: there are now 37 enhancements/fixes queued in my issue-tracking system (some of them requested/reported by users). While most of these are fairly minor and won’t even warrant mention in the list of improvements, taken together I think dealing with them has to take priority over a major new feature (translation history).

So I’m going to work on clearing my task list during the month of August, release the improvements in version 1.3 at the end of the month, and then get back to the translation-history feature in September.

Now that my translation memory system has a new start as Felix, I’ve got a lot of plans for its development. In this post I want to lay out my development roadmap for the next three months. In June, I’m going to be working on a minor release with several minor enhancements. After that, I’m going to be working on two new features in July and August: translation history and network support (described below). I haven’t decided which order to implement them, so if you have a preference please let me know!

Translation history

This feature will be somewhat analogous to the Trados “bilingual file” concept, except that the information will be stored in a separate file. For example, if you’re translating a file called “MyFile.doc”, the translation history file would be “MyFile.doc.fth”.

This will make reviewing translations a lot easier. It will also make it possible to get rid of the “translation” and “review” modes (which I think introduce too much complexity) — instead Fellix will automatically know whether the current segment is a source or a translation, and behave accordingly.

Another benefit of the translation history feature is that it will allow integration with Trados-based workflows. I’ve long anguished over what to do about “bilingual” Trados files. There is demand to support these in Felix, but I absolutely didn’t want to do it the same way in Felix. I think embedding hidden text in your translation that later needs to be “cleaned up” is a horrible, horrible idea and one of the main reasons why I developed Felix. With a translation history feature, however, I could create a filter that translated between “bilingual” files and translation history files.

Network support

This feature will allow multiple translators to use the same memory simultaneously over a network, or over the Internet using a VPN. This eliminates the coordination problem, when two or more translators work on the same project simultaneously, and translator A translates sentence X or term Y one way, and translator B another way because they haven’t seen each other’s translations yet.

Further out

I don’t have anything concrete planned beyond August, but there are a number of things coming down the pipe. One is a new and improved Align Assist program (for “aligning” legacy translations to create translation memories). Alignment tools generally don’t work very well and are a hard problem, but there’s demand for them so I plan to brush up Align Assist when I hit a good spot with Felix.

I also want to have a better tool for translating XML files, and maybe some other formats like .NET resource files (for localization).

As always, if you have specific preferences for development, please let me know.