Collaborative Editing with Google Docs

The Visual Editor in WordPress is great, but often, when we need to do some group-thinking, we turn to Google Docs. Wouldn’t it be great if these two got connected?

Large sites have teams of writers and editors. When these sites are multilingual, they also have translators and proofreaders.

Right now, WordPress has no real tool for collaborative writing. You know, adding comments, discussing issues, showing each-other what we mean and, generally, collaborating.

Google Docs, on the other hand, excels at this. It lets us share documents, allows others to read, edit and make comments (inline with the text), receive email notifications and view what others are doing – all in real-time.

More and more, we start something in Google Docs, work there and paste the result into WordPress.

For multilingual sites, collaborative writing becomes critical. Proofreaders need to receive notifications about new translated documents. They need to access the ones assigned to them, ask questions, make suggestions, edit and agree with the translators.

When they’re done, the corrected document should fly back to WordPress. It must be more than easy – it has to be trivial.

We’re thinking about building all of this functionality for collaborative editing as a WordPress plugin. Would you find it useful? What would you do with it?

Here’s a video that shows how it works:

This is what I’m doing:

1. In Chrome, go to the address bar and type in the site’s URL
2. Add a space
3. Enter a search string. I typed in “wpml.org getting started”
4. Chrome redirects me to the WordPress search URL: http://wpml.org/?s=getting+started&lang=en

From what I can tell, Chrome remembers my surfing history. Once I’ve run a search on a WordPress site, it understands that this is possible. Next time, I can do the search from the address bar, like it shows in that clip.

Tell me, is this working for you too?

The Numbers

We’ll be offering two versions:

• Multilingual Blog – $29 USD
• Multilingual CMS – $79 USD

The blog version will be fine for most blogs. It includes the standard translation controls you’re used to in WPML.

The CMS version includes the Translation Management and Strings Translation packages, which are typically used for larger sites.

Each purchase will come with one year of support and updates. After that one year, you can get additional support and update years for 50%.

The Big Difference

We thought that it would be appropriate to improve WPML, in return to asking for payment.

Instead of one developer, there are now three working on the project – full time.

The results, so far, are:

• 17 critical bugs fixed.
• 3 security holes closed.
• 231 PHP warnings and notices fixed (try running WPML with WP_DEBUG to see for yourself).
• 43 code optimizations, reducing memory consumption by nearly 50%.
• 19 SQL query optimizations, reducing DB access by up to 90%.
• 5 usability improvements, to help site admins find what they’re looking for faster.
• 3 new features that we still managed to slide in.

This is the beginning. Next, we’re planning new features which have been on hold for too long already:

• New (working) version of BuddyPress Multilingual.
• Support for e-commerce plugins like Shopp and WPEC, without waiting for anything from anyone else.
• Better interoperability with major caching and SEO plugins.
• Interface for industry-standard translation software (Trados and the likes).

Premium Support

Just like most of you, we’re developers ourselves and we use tools that others have built. The thing that we suffer from most is slow support for stuff we rely on.

As we turn WPML into a commercial product, we’re bumping up the support. WPML forum is getting a major face-lift. We’ll be answering every thread and making sure that nothing is left to chance.

Some technical improvements to the forum will include the ability to subscribe to threads for email notifications, and an indication for the length of the support queue.

You can Still Use the Free Version

The current free version of WPML, on wp.org, is going to remain there.

If you’re happy with it, you can keep using it for as long as you like. Heck, we’re still running with it on our own sites.

Free For…

All current ICanLocalize translation and support clients don’t need to pay to get WPML. It’s included.

We will also give free access to non profits and theme and plugin developers.

Launch Date

Our new site, with the purchase mechanism will be live shortly. As I’m writing these lines, our folks are checking and double checking everything. We’re down to the very last issues and hope to release in a few days.

All these upgrades and payments and nasty stuff are up to you to choose. If you want to get the newer versions and enjoy premium support, you’re welcome to purchase. Otherwise, what you have is just fine.

BuddyPress sites include many components which are not language aware. This plugin changes it by adding language information to all of them.

So, when you’re using WPMU, BuddyPress and WPML, BuddyPress Multilingual sits in the middle and makes them all play nice.

It adds a language switcher to the BuddyPress banner, and makes sure that wherever you go in the site, you stay in the same language. So, for example, if you’re viewing a member profile, the page will display in the correct language.

Here is how it looks like in action:

What you can see in the movie is how I change the site language. Once changed, everything displays in that language.

How to use

BuddyPress Multilingual has no GUI and no configuration. To use it, you need to enable WPML and BuddyPress. Then, enable BPML.

In order to run correctly WPML needs to be configured to use language directories. This is the only supported language URL configuration. Besides that, there’s nothing else to check.

How is it working for you?

This kind of work isn’t simple. To make an e-commerce plugin multilingual, you need to make products translatable, support multiple currencies, have multilingual shopping carts and a complete multilingual checkout flow.

Running a multilingual web store is probably one of the most lucrative things you can do with WordPress. For a fraction of the cost of other solutions, you can have an online store for any business. It’s a good deal. But, in order to make it happen, someone needs to go first.

The shopping cart guys are not going to pay for it and neither can we. We each have a business to run and this sort of thing will never fit in as free-time-activity.

Sponsoring niche development

The way to get a multilingual e-commerce plugin is to sponsor it. This will allow us to spend the required time implementing a good solution and making it part of WPML. Some of the payment will also go to the e-commerce guys for the support on their side.

Whoever does this will not get an exclusive right for the code. Instead, it will become part of the shopping cart plugin and WPML, meaning it gets supported in the future.

So, if you have a niche need, are running a business which can benefit from it and can sponsor some development, give us a shout. We’re always happy to extend WPML and will be able to devote more resources for niche solutions when it’s sponsored.

Turning themes multilingual is too much work

Premium WordPress themes are complex beasts. When folks purchase them, they’re ready to be used and provide tons of functionality.

This means you can build great sites without burning precious time.

To make the themes multilingual, folks need to follow complicated instructions and edit delicate code. It’s not easy, even for us. Some of the challenges we keep seeing:

• Featured contents on home page.
• Special pages appearing in the home page, sidebar and footer.
• Adding different types of language selectors to match the site’s appearance.

When we do this, we spend anything between several hours to several days – per theme, and we’re pretty experienced at it.

WPML will do it for you

We’re working on making WPML way smarter than it is now. Instead of WPML asking you to edit theme, it will practically do it all for you.

How this works is a bit difficult to explain, but the essence is that every time the theme gets posts, pages, tags or categories from WordPress, WPML will intervene and tell WordPress to return the right stuff according to the display language.

For instance, supposing the ID of your About page in English is 32 and its Spanish translation has an ID of 33. The theme doesn’t know the site is running multilingual, so even when displayed in Spanish, it still asks WP for the contents of page 32.

WPML sees that. It knows that the page is in Spanish, so it tells WP to return page 33 – the Spanish translation.

The theme doesn’t know that anything happened. It asked for the About page and it got it, just in the right language.

WPML already has functions for converting between IDs in different languages. The big difference is that now it will call these functions for you, without having to edit anything in the theme.

When already?

All this new theme magic is going into WPML 1.7.0. We’re skipping the small bugfix release in favor of adding this new major functionality.

If you’re using complex premium themes, we’d love it if you can test this new stuff before it’s released.

We’re testing it on great themes from WooThemes, VivaThemes and free themes from the WordPress theme repository, but the more testing, the better.

To help, leave a comment here or post in the forum.

The idea is you can add new languages to your site, but everything in those languages stays invisible (to visitors) until you’re done with the translations.

So, you can translate peacefully, without things looking half done or half-broken and then, when you’re 100% happy, release that new language.

Hiding languages

Go to WPML->Languages and scroll down to More options where you’ll see a new section called Hide languages.

Hide languages feature in WPML 1.6.1

Once a language is hidden, visitors (not logged in) cannot see any contents in it, but you can.

Click on your profile page to set the option for yourself. This way, you can see how the site will look like once that language is enabled.

This feature, along with several bug fixes is available in the current development version – wpml_1.6.1.A1.zip. You can try it on development sites to see how it works.

I hope that this would make it easier for you to add new languages to existing sites. We could sure have used it when we added Japanese and Chinese to wpml.org.

If you have other killer ideas or spot something that looks like a bug, remember to post about it in the forum.

Have a good weekend!

Mike wrote the following post, which makes for great reading for anyone building full sites with WordPress and WPML.

The following is a brief summary of my experience with the WPML plugin.

Primary Navigation

The primary navigation of this site is image based, so instead of using do_action(’icl_navigation_menu’), and being forced to either disable or overwrite the CSS they produce, I instead went the faster route by using the icl_link_to_element() function, like so:

<ul id="primary">
  <li class="bg link1"><?php icl_link_to_element(22); ?></li>
  <li class="bg link2"><?php icl_link_to_element(24); ?></li>
  <li class="bg link3"><?php icl_link_to_element(37); ?></li>
  <li class="bg link4"><?php icl_link_to_element(27); ?></li>
</ul>

The down side of going this route is if the page ID changes (which it shouldn’t) the link will be dead. However, the up side is that it took no time at all to implement and I didn’t have to worry about overriding the default styling that WPML applies to its “menuing” functions.

NOTE:

The WPML plugin is shipped with a style sheet that automatically styles the various navigation types that it renders. The only way to completely avoid this is to delete the styles sheets that come with WMPL. However, the do re-appear when you update the product.

In my opinion, there should be a feature built-in to WPML that allows the user to enable/disable the style sheets.

Amir: As of WPML 1.3.3, it’s possible to disable loading any of WPML’s CSS and JS files. Use one of the constants described in the coding API page.

Breadcrumb Navigation

To implement the breadcrumb trail that is shown on all pages (with the exception of the home page), I used the following function:

<?php do_action('icl_navigation_breadcrumb'); ?>

Easy to implement and did what I needed “out of the box”. However, I believe some customization should be available – namely having the ability to choose what the separator between each link should be. Granted, this is pretty minor stuff, but still, having the option would be nice.

Sidebar Navigation

Only one section of the site has sub/secondary navigation, and again I was able to use one of WPML’s built-in functions to create this:

<?php do_action('icl_navigation_sidebar'); ?>

This function has an interesting way of rendering the navigation. It first echos the parent page as a header (<h4>) and then renders the links (children) that belong to it. Again, like the other functions I’ve discussed, there is not a whole lot of customization that is available. In this case, I didn’t need any – but what if I wanted the page name (currently as an <h4> element) to be a link instead?

Amir: Good point. Just like for the top navigation, we’re going to add hooks to this function so that designers can create custom HTML for elements.

Language Switching

Finally, the language switching was where I had to do the most customization. The default method for displaying the available languages was not going to work – instead I used a nifty little function (icl_get_languages(’skip_missing=N’)) that return an array of all the available languages and a parameter for each (active) which has a value of ‘0’ or ‘1’. The active language will have a value of ‘1’, while all the other languages will have a value of ‘0’.

For this site, all I had to do was run the resulting array through the loop and when I found the active attribute having a value of ‘0’, I would return the language name, like so:

<?php
function wpml_language_switch() {
  $lang = icl_get_languages('skip_missing=N');
  $ret = '';
  if(count($lang) > 0) {
    foreach($lang as $value) {
      $ret .= ($value['active'] == 0) ? '<li><a href="' . $value['url'] . '">' .
               $value['native_name']  . '</a></li>' : '';
    }
  }
  return $ret;
}
?>

Final Notes and Remarks

In conclusion, WPML is a plugin that I intend to on any WordPress-related build that I am a part of. Even for sites that are in one language only, the navigational features that the plugin offers make it a “must have”. Sure, there are things that could be worked on and improved, but all in all it’s a great product that will only get better!

The next step in WPML development is to add a full test suite to it. The plan is to use the Automated Testing framework used by WordPress core itself. This way, we can add new features without running the risk of breaking existing functionality.

Background and some figures

WPML started as a pretty large plugin and over time evolved into a huge project (20,000 lines of code). It provides much of the functionality you can find in other, mature, content management systems.

For instance, in Drupal, the same functionality is achieved by no less than 8 modules – i18n, country flags, translation tables, translation overview, l10n server, potx, ICanLocalize Translator and menus.

Instead of complaining about how complex it is, we better create robust tests that allow us to develop it without having to manually test dozens of scenarios on every release.

We need your help to the test suite complete

By now, you must be wondering why I’m explaining all this.

We’re making a long list of tests, which we hope will cover as much as possible. However, I’m pretty sure that we’re going to miss out on many important things that need to be tested. And here is where you get to help.

Over the next week, we’re going to set up a bug tracking system. In order to report bugs, you will need to:

1. Provide access to a place where the bug can be validated.
2. Supply information about how to duplicate it in our testing environment.

Then, we’ll be able to add this case to the bug-tracking system and track its progress. Every bug will be added to the test suite, making sure that once it’s fixed, it stays fixed and doesn’t surface up again.

Ready to help? We know that reporting bugs this way is going to be harder, but the end results would be much better. By reporting bugs in a way we can track and fix, you’ll help make WPML better.

How WPML’s professional translation works

1. You write contents in your language.
2. WPML sends posts and pages to ICanLocalize for translation.
3. Translators work on ICanLocalize’s translation system.
4. WPML fetches the completed translations and either publishes or holds for review.

When you use this, you can concentrate on the contents in your language and WPML takes care of the rest. For example, it will adjust links to go to other translated pages, creates pages in the correct hierarchy and handle any custom field that you’re using.

Who is doing the translation?

When you set up professional translation, you can choose between two options:

• Using translators from ICanLocalize.
• Using your own translators.

Most people prefer using translators from ICanLocalize, as they’re all excellent at their work and highly trained at using our translation system.

When you choose this option, translators from our pool would apply to work on your site. They’re all very good but each comes from a different background. So, for example, if you’re doing a tourist related site, you would probably prefer a translator who’s already worked on other similar websites.

Setting up and using professional translation

Go to WPML->Pro translation and click to enable it. Next, you need to select which languages to translate between, which translators to use and enter information for an account (just your name and email).

For now, you’re done. Over the next day or two, translators will apply for this work. You can see their resumes and chat with them.

Once you’ve selected translators, you can start sending documents to translation.

Go to Tools->Translation dashboard, select what needs to be translated (you can select everything at once) and click to send to translation. That’s it. Your translator will get it, translate and it appears back in your site.

Want to see it in action? Here’s a live demo (featuring my voice, with a slight cold):

www.youtube.com/watch?v=NnJY5i4p4H0

Handing off translated sites to your clients

Web developers often need to supply sites with initial contents and then hand them off to their clients.

You can use ICanLocalize’s professional translation to build the initial translations for the client site and show off a nice multilingual site with real contents.

Then, when you hand the site over to your client, tell us and we’ll transfer the ownership of the translation to the client as well. This means that the client will be paying for the translations from now on (and of course, manage them).

And, as a sign of gratitude, we will keep you as an affiliate for that site. When we get paid for translation work, you’re credited as well. It’s just fair as you’re the one who got us the job in the first place.

If you’re building multilingual sites for clients, can you help us by participating in this poll?