When the project was still under Bernhard’s rule, he was always going to release only versions that had passed his test plan. I hope to break this tradition soon and release more often and release earlier. My goal is to put all of the code-base under a testing harness that will allow me to verify and validate much of the functionality without too much manual interaction required. This means you will see unstable versions tagged as “alpha”, “beta” or “RC” (release candidate) as well as stable releases. It is on you to decide whether you want to contribute to the development by testing any of the unstable versions, or whether you want to stick with the stable releases only.
Please note that I will follow these guidelines:
- alpha (may become a weekly or nightly build) is a very early version of a future release. Neither is it guaranteed to work properly, nor at all on your machine. Also, new features in such a version may be unstable. As an example, a saved scan may not be loadable in a “beta” or a stable release of this version.
- beta means that the version is reasonably stable. Features available in a beta may disappear in the stable release, or change considerably.
- release candidate (RC) is a version of the software that has the full set of features (”feature-frozen”) of the anticipated next stable release. One of the RCs will eventually become the actual stable release if no bugs/issues have been reported within a certain time frame.
- stable releases are what you already know from WinDirStat.
// Oliver
PS: Once I am done with the migration of the translations to XML (see previous post), I will release a first alpha version that has the multi-selection feature activated. It will also have an optional online update-check. Before a beta I want to include an improved mouse-navigation as well as a save/load feature to save time and not having to re-scan a directory structure every time. I personally also liked the proposed ignore feature.
Hi,
just wanted to let everyone know that I am currently working out a format for what’s now the resource scripts in XML. You can find a first draft version in revision 174 in the Subversion repository. As you can see, you will have the translations “side-by-side”, which should also make the job of translators easier. Since the encoding of the XML files will be UTF-8, all languages should be just fine, as all natural languages and several artificial languages (such as Klingon) are covered by the Unicode standard of which UTF-8 is one incarnation.
If any of you has ideas for how to improve the current XML format (more additions will follow throughout the next few days), please let me know here in the comment section, via our contact form on the website or in a tracker or the discussion forum at SF.net.
Rationale: it has been increasingly difficult to manage the translations (be it new translations, edits of existing ones by native speakers or changes in the GUI by me). Therefore I was for a while now looking into moving to a more manageable solution that will not require the translator to contact the developer, let alone have the developer “compile” the translation. Of course even with the new system it will be necessary that I include a new language in a future release, but there will be more flexible means of updating languages via the internet and translators will be able to contribute in a very flexible fashion as well.
// Oliver
PS: The XML parser (TinyXML with TinyXPath) will also be used to save/load a scan.
The migration to Subversion apparently did have some cost attached to it. Just found out that for whatever reason the resource scripts have been garbled. Hmpf …
Update: Actually the culprit must have been one of the editors used two/three years back, according to the history. It only affected those languages with real diacritic characters (e.g. Polish) and completely different alphabet (Cyrillic/Russian) that could not be fit into the 1252 ANSI code page (the default on my system). This website from Microsoft really helped to find the correct matched for each code page. Hoefully the UTF8 version of the resource scripts is now correct. Parsing the strings inside string tables was pretty straightforward, but the PITA will be the controls in dialogs (which also need to be extracted). Just to explain briefly what I am going to do: all the resource DLLs will be replaced by a text file (most likely XML, as the saving of reports is another good reason to use an XML library already). This will allow anyone with basic understanding of computers to contribute translations (or pieces thereof) without having to know the (slightly convoluted) syntax of resource scripts (.rc files).
// Oliver