warning: Creating default object from empty value in /home/amir/websites/drupal-translation/drupal-latest/sites/all/modules/i18n/i18ntaxonomy/i18ntaxonomy.pages.inc on line 40.


Is it Evil to Ask For Payment?

$First, remember that we're all friends and we all share the same goal. What I'm going to ask is how to best get there. If you think I'm flat-out wrong, please say so.

Drupal core is extremely powerful, but without all those contributed modules, it wouldn't be as successful as it is today.

Our problem is "how to make module development sustainable?"

Most contributed modules were created because someone needed something that wasn't there. Then, they added the module to Drupal's repository, so that others can use it and improve it.

However, the heavy lifting remains the responsibility of the author. While community members help enormously with bug reports, patches and ideas, most of the work remains with the author. As modules mature and become more popular, ongoing support and maintenance becomes a significant task.

And now that Drupal 7 is out, this work basically doubles, as D6 and D7 are very different beasts.

My Theory - Paying for Modules will Drastically Improve Them

For the last year, we've been working on the Translation Management module. It's a complex project that powers some of the larger multilingual Drupal sites around. The folks using it save thousands of dollars every month on management of translation work.

Our little dilemma is how much time we allocate to handling user issues and how much time we dedicate to building our own translation system.

Right now, all of our Drupal translation clients are running smooth without any technical or workflow problems. It's taken months to get there. However, there are quite a few others who are using our module without our translation service.

We do our best to support everyone and make our TM module play nice with every possible Drupal configuration and with other major modules. The problem is time. When we debug complex problems for others, we practically neglect our paying clients - the ones who make all this work possible for us.

Asking money per support issues is a bit like running a beg-ware business. You find yourself in endless negotiations whether someone found a bug and you should be paying them or whether they should be paying you for support. It doesn't work.

If we could charge a small fee from everyone using out module, we would be able to spend far more time into making it more robust, perform faster and more compatible with other modules.

GPL Means Free as in Freedom, but not Free as in Beer

Just because modules come with a GPL license it doesn't mean payment is a bad idea. You can think about it anyway you like and give it any name. The end result is the same - you're sponsoring the tools that you use for your business and help them get better.

When you pay for something, you also get something in return. The promise of a for-pay module is support. If you could pay for a module, you would deserve reliable support.

This means that when you run into a problem or you need help, there's an address and there's commitment. When you create an issue, you know that there's a maximal time until it's handled and that time is measured in hours, not in weeks.

What do you think? Would you be willing to pay for using modules that you depend on?

Translation Management for D7

We're happy to release the first beta of Translation Management for D7.

What's working:

  • Translation Dashboard
  • Translation Jobs
  • Translation Editor
  • Translation Service from ICanLocalize
  • Translator Management
  • Node translation
  • Menu translation

What's not working:

  • Block translation (requires i18n support)
  • Taxonomy translation (new field translation not included yet)

D7 Translation Management screehshots

D7 translation dashboard

Translation Dashboard on Drupal 7

D7 translation dashboard

Translators management on Drupal 7

The module is ready for beta testing but not for any production sites.

Where next?

In order to provide a fully working multilingual Drupal 7 environment, we'll also need to complete the i18n module. We are working together with Jose Reyero and hope to have it all working by the next DrupalCon in Chicago.

i18n development is now running on Github:

You can see the project progress and who's doing what here:

More Compatibility, Better Performance and New Features for Translation Management

Translation Management 6.x-1.21 is out with some long awaited bug fixes and improvements.

First, a very big thanks to everyone who reposted issues and contributed patches. Most of this update is due to you!

List of changes in this release

  1. Add compatibility with the nodecomment module.
  2. Add check_plain when showing title link after translations. This means the module will correctly encode the title when using non English characters.
  3. Fix fatal error OHT module. People who want to get translation services from OneHourTranslation can do that without suffering from bugs on the way.
  4. Fix Arabic flag. Arabic and Argentina are different things ;-)
  5. Added indexes to the translation tables. This will dramatically speed up page loading and translation update for large sites.
  6. Fix PHP warning on cron job. Even though these were warnings, they could have hidden other serious problems.
  7. Added a quote wizard that allows calculating the cost for translation by ICanLocalize.
  8. Delete relavent job data when deleting nodes. This makes sure that there are no left-overs in the DB when content is deleted.

Quote wizard - 3 clicks for an instant quote

The most frequent question we hear is "how much is translation going to cost?".

The good news is that now it takes just a few clicks to get an answer.

Go to Admin->Translation Management->Translation Dashboard.

Under Translation Services, find ICanLocalize and under that, click on Get Quote.

get quote button

Next, choose which languages to translate between.

quote wizard step 1

Then, choose which content types to include in the quote.

quote wizard step 2

The summary screen shows you what you've selected and prepares the quote.

quote wizard step 3

When you click on produce quote you get to ICanLocalize, where we check the rates between the languages you've selected and produce your quote.

quote wizard step 4

If you're taking translation services from ICanLocalize, that's great. However, you can still work out the cost of translation with any other translation service using this wizard and a calculator.

Drupal 7 teaser

We're almost ready with a Beta version for Translation Management for D7. We hope to release it next week.

Are you interested in testing that together with us?

Together with Gábor on Multilingual D7

Session proposals for DrupalCon Chicago are open. We've submitted a session, together with Gábor Hojtsy on multilingual Drupal 7.

Sessions will be accepted based on the decision of the organizing committee and votes. So, if you want to hear about running multilingual D7 sites, remember to vote for this session.

Our plan (and commitment) is to have everything running by February, so that folks can start build multilingual D7 sites before the next DrupalCon.

Right now, the i18select module is already complete. Next, we're starting on the i18n core. The D7 port for Translation Management is also coming along nicely.

Like we wrote before, a major focus in the D7 multilingual system goes for ease of usability. Instead of balancing between the preferences of developers, admins and translators, we're separating their admin pages. Well, you'll see much more of that when you come to the session ;-)

Syndicate content