It seems that after Roberto Romero abandoned the maintenance of the Wesnoth Spanish Translation team in 2007, it’s all gone downhill.

(Fun fact: it was under his leadership that I contributed my first translations for mainline Wesnoth — my first involvement with a FOSS project ever.)

Some time after he left the team (apparently without previous notice to Ivanovic or Torangan), the translation was taken over by a significantly less competent group that did a very lousy job (read: no quality control) before abandoning it again. Around the end of 2008, I took it over and quickly, with the help of an Argentinian guy who joined me later, brought it to completion in time for the first release of the 1.6 series.

In the process I realized how hard it really is to maintain a complete translation of a large game like Wesnoth.

Due to a series of RL complications, I had to abandon the Spanish translation shortly after Wesnoth 1.6 was released (March 2009). The translation was not taken over by anyone in time for Wesnoth 1.8 (April 2010). Much later in November, though, a new fellow became maintainer and got some work done along with other new collaborators.

Things were starting to look unusually bright because, for the first time in years there was more than one active translator. However, this world full of rainbows and pink unicorns did not last, and it ultimately fell into oblivion following the departure of this last maintainer from the community. No-one took over the team afterwards, and now the Spanish translation is in its natural state once again. The last update in mainline trunk took place in January 2011.

You can have a look at the current situation in gettext.wesnoth.org, our translations statistics website.

It seems that Battle for Wesnoth just doesn’t manage to appeal to many Spanish-speaking people from the FOSS users community to attract new individuals with the knowledge, patience and time required to resurrect an abandoned translation, and the sense of leadership required to coordinate work and keep certain quality standards to attract and, most importantly, keep new translators.

Of course, Wesnoth is a huge undertaking of its own with over one dozen of thousands of strings in mainline and its distinctive approach to storytelling — I know for sure I do not want to work on translating campaigns again, at least, not alone. Still, there are people far more capable than I am for this kind of work, and I do believe our game could really use more publicity among Spanish and Latinamerican players and their contacts.

All the technical fluff relevant for starting to work on an existing or new translation can be found in the wiki, after all.

Today, May 26th, a few minutes past 06:00 AM UTC, after 6 or 7 years of history, the Wesnoth.org favicon has finally been replaced by command of the Art Director on the live website and in SVN trunk, revision 49655, meaning this change is also effective in mainline starting with version 1.9.7 (not yet released).

The differences between both versions are far from subtle, as you can see to the right.

I for one mourn the loss of this significant piece of history that reflects an older, more cartoony art style that was slowly abandoned towards Wesnoth 1.0 and beyond. Until now, this icon also accompanied the owned village counter in the game’s top bar, and served as an indicator overlay for moves affecting village ownership since version 1.4 onwards. Finally, it served for a long time as the village terrain category icon in the Map Editor.

In case anyone requires the old icon for the sake of nostalgia, it’ll be preserved here for your own use under the conditions of the GNU General Public License version 2.

• PNG format (468 bytes)

Whatever rules Mozilla Firefox follows to determine the user’s default email client don’t seem to work properly on Debian, at least not when GNOME is not the desktop environment originally installed. For whatever reason, what Firefox tries to do with mailto links and the Send Link context menu option is to open the Evolution mail client, which is not installed with the KDE or LXDE desktop environments.

Fixing this is supposed to be trivial, and it is, but the relevant option is hidden in the worst possible place in Preferences.

Chromium/Google Chrome does not have a user-accessible setting for this, but somehow still appears to get the right idea from the desktop environment.

If you are running Google Chrome 11 or Firefox 4 or later and you know how to find your way through a Unix console OS, here’s something you might want to check out: it’s a Javascript PC emulator running a custom (patched) build of the Linux kernel 2.6.20. Directly. On. Your browser. With Javascript.

And it’s made by the same guy who wrote QEMU!

Javascript.

Despite Bluecore being back home, I have decided to continue using Reicore as my primary working laptop for all purposes, as it is in much better condition, uses a more Linux-compatible IGP, and doesn’t suffer from uncannily low I/O throughput like Bluecore does.

The ATI mayhem isn’t over, after all.

Reicore’s CPU (an Intel Pentium T4300) does not have hardware-assisted virtualization capabilities, but it seems to compensate what it lacks in technology advances with raw power — surprisingly enough, with little to no increase in heat.

Just now I have finished migrating my Windows XP SP3 virtual machine from the latest Bluecore backup snapshot — something that should have been done the week before the big crash. Windows still runs lightning-fast on VirtualBox 4.0.8 using software virtualization, with low idle CPU usage ranging between 4% and 20%.

An idle Windows session is certainly not the best benchmark, yet compiling Wesnoth RCX in it doesn’t seem to take any additional time in comparison to the Bluecore configuration, the impact on the host’s CPU usage is not significant, and the guest’s responsiveness is unaffected. Then again, at the time Bluecore died, I was not using Linux 2.6.38 and the automatic process group scheduling code (SCHED_AUTOGROUP).

Naturally, the lack of Intel VT-x implies that I won’t be able to virtualize 64-bit operating systems, but for a virtual machine on a host with just 4 GiB of RAM that seems fair enough.

Windows Vista does not seem to represent much of a difference over Windows XP in terms of VM performance.

As for Ubuntu 11.04 “Natty Narwhal”, its performance on VirtualBox is so awful that one would wonder whether VirtualBox’s VM manager code has actually been optimized for Windows guests only.

Since the popularity of DVD rippers appears to be waning as of lately, the Wesnoth.org forums may or may not be about to become prey of a new spam fad. This time it’s “Perfect” Electronic cigarettes.

Thanks to our sophisticated CycholkaSoft Anti-bot Registration™ technology (patent pending), the little critters still need some human assistance to make it to our domain. If I had to guess, their purpose is to have their account settings prepared by a middle-man who enters their credentials into a database so the bot(s) can later log into the board(s) and perform automated posts. Otherwise, it makes no sense that they create a spammy signature to not start posting immediately.

(Notice that the default phpBB 3.0 configuration disallows guests and crawlers to see users’ profiles, which is the only way signatures from non-posting accounts can be seen by anyone.)

The website’s appearance has changed again! Dorset6 (codenamed “Air”) has come to replace Dorset4 and to reduce the site’s data weight by a significant amount, by abandoning the use of bitmap graphics for layout and replacing them with some well-supported rules from the CSS 3 suite.

As a consequence, older browsers will not work with the website very well and might not display some neat details like rounded corners and shadows. Despite this, it’s still readable and mostly functional with Internet Explorer 6 and later. Both Chrome 11 and Firefox 4.0 provide all the required features to make this work properly, but there’s also some degree of compatibility with previous Chrome versions, some other versions of webkit-based browsers, and Firefox 3.5 (found in Debian 6.0) and later.

There were also a few structural changes around the Project section with this revision, making it hopefully more readable and concise.

As for the version number skip, Dorset5 was ultimately scrapped and recycled into Dorset6. Here’s what it looked like before the slaughter.

Sooner than expected, I was notified that Bluecore had been repaired and was awaiting to be retrieved in the support center. Thanks to my never-ending laziness, however, the retrieval did not take place until yesterday.

The verdict was that the screen had to be replaced.

A big problem with this is that I still see the same gray stains beneath the screen’s outer layer that were there back in February the last time I used Bluecore, around the top left corner of the panel, which brings up the question, what did they mean by “screen”?

Whoever did the repairs or testing managed to boot and properly shutdown Linux several times, so my logs indicate that the first successful boot (resuming from hibernation) took place around 15:30 UTC-04:00 (+DST) on April 28th. I’m glad that they figured out how to turn it off from the KDE display manager instead of resorting to wild button pushing.

Since the repairs were effected under an “extended warranty” plan from the store at which Bluecore was purchased, the only mission of the tech support people was to make Bluecore boot again, so everything else (fan, keyboard, etc.) is still in the same crappy conditions, except for the touchpad buttons — oddly enough, the right button is no longer hyper-sensitive to touch and works correctly.

I’d love to know exactly how a screen replacement fixed the laptop or whether it is really possible and valid to replace all display components bar the outer transparent material layers with the aforementioned stains.

For those of us who were wondering whether the Battle for Wesnoth team would release another revision of the latest stable branch, today we have definitive confirmation that version 1.8.6 will, indeed, come to life very soon, as the release manager has just informed us (plus a minor correction) in the developers’ mailing list:

Currently I consider tagging 1.8.6 maybe on Wednesday next week. Please ping me ASAP if you got anything I should be waiting for (and obviously tell me what it is). Yes, I think that 1.8.6 will really be the last 1.8.6 release.

It should be pointed out that the necessity of another stable release was decided back in February during FOSDEM, after evaluating the current status of 1.10’s development.

An incomplete list of changes can be found in /branches/1.8/changelog from the SVN repository. Some noteworthy code changes as of this writing include:

• Fixed transparent portraits not supporting image modifications
• ANL: Awarded correct amount of research to units. (Fix for bug #17406, patch by kernigh.)
• Remove useless debug output introduced in r42226
• Fix loadscreen progressbar "bleeding" on the old MP lobby when running with -s switch
• Fix for bug #17573: wesnoth unusable with certain combinations of glibc and sdl due to changes in memcopy
• Rework MP chat log as a GUI2 dialog with colored display of messages
• Fixed a gcc 4.6 compilation error