invention

There's been lots of discussion recently about Pootle on the debian lists, the direction it should take, whether to use a database to store translations, etc... It may be a nice idea to add a database as one of the backend options but keeping with handling the complexity of translation files has been important. Seems like a good consensus to this effect is emerging; it's nice to have more interest in the project.

I've tried to keep coding rather than get too drawn into the discussion, and this is what I've been up to the last week:

Pootle: Mostly ongoing architecture work, feels like we're heading towards a good structure...

• Wrote up discussion on putting metadata into a relational database
• Base class migration work on the Pootle-locking-branch: made pootleunit and pootlefile encapsulate a pounit and pofile respectively rather than inheriting from them. This will make it possible to use other storage classes (although there is still more cleaning up needed where we use PO-specific methods).
• Participated (minimally) in the debian discussions on direction of Pootle and using databases
• Fixing some minor bugs in the webserver etc

Translate Toolkit: Focused on escaping being correct and using the base classes

• Sorted out escaping in dtds - it doesn't exist. So we will no longer support \' or \n having a special meaning in dtd files, being translated to \n in a PO file etc
• Fixed various failing tests for 0.9 (including fixing some modifications we were doing to the minidom XML library)
• Added some tests for dtd quoting to HEAD - currently we allow opening a quote again after it is shut (<!ENTITY name "first part""second part">) which is invalid according to the spec - just for correctness, haven't hit any errors here
• Making properties to PO conversion use base class API more, sorting out escaping there
• Discussion with Axel from Mozilla - for 0.9 the Mozilla .properties files will be output in proper UTF-8, not with \uNNNN escaping (although that will still be understood as input. See bug 114
• Made dtd classes inherit from base classes - could be made cleaner, but at least the API is implemented now

Slashdot reported Kaspersky labs discovering the Stardust "nasty macro application" for StarOffice/OpenOffice.org

This is not really a virus, it is a nasty macro application. If you are foolish enough to agree to run it without checking what it does, you will suffer the consequences...

Not many technical details in the above links, but TechWack says the following:

Antivirus firm Kaspersky is calling the virus "Stardust". This virus is basically contained in a StarOffice document that uses macros and then infects a global template, which is used by the application to generate new documents. If a victim opens the file carrying this virus, Stardust copies it into the global template and all contained in a StarOffice document that uses macros and then infects a global template gets infected by it used by that copy of the software.

Of course (as paveljanik pointed out I hadn't said in the original version of this entry), this is all nothing to be afraid of. I only linked the above information because there are no actual details about this perceived problem, but I'm not saying it's actually a serious problem!