Hey folks,

Here’s what I’ll be working on in the coming weeks, and why it may look like not much is happening Form Tools-wise… All the following features relate to Open Translate, Form Tools’ translation management script.

1. Google Translate

In the last couple of years Google has come out a number of extremely cool stuff relating for translation, including the Google Translate API which allows developers to translate content via their own scripts. For the foreseeable future, automated translation of text is never going to be as solid as that done by a real translator, but it’s a good start. My plan is integrate Google Translate API with Open Translate to provide a base translation of all languages that they offer. These translations will then be open for other translators to review and improve.

Depending on the quality of the translations, this should significantly reduce the amount of work for translators as well as provide an initial - albeit bug-laden - translation file for many languages that haven’t been tackled yet. These languages will then be bundled with the main download file so that people can choose their language right in the installation script. To encourage better translations for all of us, I’ll be storing the Reliability Percentage (see: translations.formtools.org) of each translation in the corresponding translation file. Until that percentage is > 90% (or something), I’ll include a link in the admin UI to encourage non-English speaking users to help translate their language.

2. Data Versioning

So… this is a fun one! A little backstory first. I wrote Open Translate (opentranslate.org) a couple of years ago to properly handle community translations, and up until now it’s held up pretty well. But now that Form Tools 2 is out of Beta, I need to complete a feature that I spec’d out but never completed: versioning. The text that needs to be translated for Form Tools 2.0.0 is now FIXED, I won’t be modifying it. This is going to be the case for all “final” releases from now on. You’ll be able to download a translation file for whatever version you’re using. [I HATE Wordpress’s annoying “You’re version is out of date! Upgrade now!” line that appears at the top of the screen every few weeks to persuade people to upgrade. I won’t ever do that. You can stay on v2.0.0 for years to come if you want, and I won’t bug you. Promise. :) ]

So anyway, the goal is to allow translators to be able to pick a version that they want to translate - whatever version of the script is relevant for them.

Now here’s the catch: I don’t want to duplicate any text + translations for each version (2.0.1, 2.0.2 etc). I want all of them to share the same text + translations as much as possible to minimize the amount of work done (one of the golden rules of software development is duplication == bad!) Also, if a user is running 2.1.8 and translates some text that’s been unchanged & untranslated since 2.0.0, I want that translation to be automatically added to ALL versions from 2.0.0 onwards.

As you can imagine, this is getting complicated! Neat problem, huh?

My original plan was to base Open Translate entirely on SVN (Subversion), which so that all translations and data were versioned. Subversion is just that: it’s a versioning tool that keeps a repository of all data and offers ways to slice and dice the information depending on what you need. In fact, this is the script that powers the Form Tools upgrade mechanism and helps generate the custom zipfiles containing whatever files have changed since your last version. It’s used on this site to keeps a giant database of all Form Tools files: themes, modules, API and Core.

Despite its many virtues, after much hemming and hawing I decided against using it for Open Translate. Partly for technical reasons that I won’t go into, but also partly because Open Translate would still have needed a duplicate database of the data and translations o allow for quick searching and access of the data via a web-based UI.

So…. long story is that I’ll now be adding in versioning support to Open Translate. I have it all sketched out and it’s a thing of beauty.

3. Module Translations

This is something I’ve been hopelessly delinquent about. Once the above two are complete I’ll be adding the option for modules to be translated as well. Right now all of them have a single, English language file. Weak!

And that’s all folks.

- Ben

Yowzers.

http://news.bbc.co.uk/2/hi/technology/8488751.stm

Hey folks,

I’ve been receiving a number of questions about why Form Tools 2 is still in beta and when a final, stable release will be out. Many people are clearly concerned about getting on board with a script that isn’t polished - a very understandable concern! Well, I’ve been rethinking my position these last couple of days and thought I’d write a post about what’s going to change.

As it stands today

The “beta” label has nothing to do with the stability of the script - in fact, I’d regard it as having been stable for many, many months now. Actually, my original plan was to leave Form Tools 2 in beta indefinitely. I like the term “beta” for a number of reasons and thought that Google’s model of leaving scripts in perpetual beta fit well for what I was trying to do.

Consider this: no software is every truly complete or perfected; all non-trivial scripts have bugs. This is just the nature of the beast. In light of this, it seemed dishonest NOT to label Form Tools 2 as a beta! Scripts that proudly proclaim “v1.0″ imply a polished, bug-free product. That’s never the case - I didn’t want to give a false sense of the state of the script.

But the way I’ve implemented it is problematic. Unlike other scripts, Form Tools versions are released in a single thread: everyone get the same code, like it or lump it - and they’re all labeled “beta”.

Problems with this approach

1. People think “beta” means unfinished and shy away from using the script.
2. Adding in new features adds it directly to the trunk. This is great because it ensures everyone’s up to date, but it’s also problematic because some changes have higher impact and risk. Generally people favour stability over new features.
3. Component dependencies. There are increasing more modules, all of which rely on the Core. As the core changes, the modules can be affected. Up to this point, the dependencies have been few and far between, but it’s going to escalate. Mapping a particular dependency for module A to beta “2.0.0-beta-20090116″ makes less sense than mapping it to “2.0.1″.

What’s going to change

Basically I’m going to be moving to a more typical release model - retaining the agile approach, just tweaking it a bit. There will still be a single branch of the code (the trunk), but the main download files will ALWAYS be “standard release” snapshots - 2.0.0, 2.0.1 etc. You won’t see any more numbering schemes like “2.0.0-beta-20090116″ from the standard download files - this will be both for the core, modules and API. Upgrading *will* provide you with the option of downloading beta as well as standard releases, but they’ll be hidden by default.

For people interested in the latest cool stuff coming out of beta, they can go to the Custom Build page. That script will list all beta versions as well as the standard release.

The “beta” term will now be more intuitive to a lot of people, I think. It will contain newer, less tested code - for most people, they won’t care: they’ll just get the standard release and be done with it.

Also, I’ll be updating the custom build and upgrade scripts to visually display dependencies. Now THAT’s going to be fun! :-)

Coming soon

In the short term, I’ll be releasing one more update to Form Tools tomorrow or the day after: it will contain a new feature to allow you to pinpoint multiple email fields in your forms for use in the email templates. This will be the final “beta”. I’ll then make that release the final 2.0.0 release.

That’s pretty much it. Part of what prompted this whole thing was that I want to add two new larger features to the core: a scheduler and an error logging system, and didn’t want to create a new branch… but that’s another story. More on that later… :)

- Ben

Apparently Firefox 3.7 will be providing a substantially better way to attach code to key events in an extension's life (like installation, uninstallation, update etc), but in the meantime we're stuck with manually attaching our code to observers that detect those events. A little cumbersome, but workable.

Anyway, this is taken from this page on songbirdnest.com. I just made a couple of minor tweaks needed to their code: it looks like they just copied and pasted it from elsewhere, so a couple of vars - Ci and Cc - weren't defined. The following code works as a standalone component.

Read their page for some caveats and other comments.

Just got my ticket for this year's Google I/O conference in San Francisco. Can't wait!

And in Google-related news, check out the following post on their relationship with China, having discovered sophisticated attacks on their company to extract information about Chinese human rights activists. Heavy stuff.

"These attacks and the surveillance they have uncovered--combined with the attempts over the past year to further limit free speech on the web--have led us to conclude that we should review the feasibility of our business operations in China. We have decided we are no longer willing to continue censoring our results on Google.cn, and so over the next few weeks we will be discussing with the Chinese government the basis on which we could operate an unfiltered search engine within the law, if at all. We recognize that this may well mean having to shut down Google.cn, and potentially our offices in China."

http://googleblog.blogspot.com/2010/01/new-approach-to-china.html

A year ago today I released the first beta of Form Tools 2, so after a years worth of testing, I figured today would be a good day to make it the standard version for download. So now when you visit formtools.org, you'll find Form Tools 2. The Form Tools 1.x site has been archived here.

Nice.