Ubuntu

Translation: radical dreaming required

I'm working with two different Ubuntu teams right now that translate long documents. We have not found a human-friendly tool chain that allows translators to be language experts without having to also be a command line wizard. Each translator is forced to come up with their own way of doing things. Some are able to cope just fine but others are being cut out of the action because they have no sane way of dealing with the source files.

On the list of doc formats to deal with are book-length XML files (broken down by chapter in most cases) and subtitle files (which are basically plain text with time codes). In the interest of using an integrated system I posted a feature request on Launchpad and asked for a sane way to deal with files that were already stored in the code section of Launchpad. Within a day the feature request was flat out rejected and the bug was closed and tossed.

So here is my challenge to everyone out there...if you dared to dream, just a little bit, if you dared to create a system that was easier to use and took advantage of the power of the intarwebs instead of an individual's ability to bang on command line tools, what would the future of translation look like? How would you create a Web-based (or desktop-based) translation toolkit? What would it look like? How would data be pulled in, be worked on in "draft" format and be saved and pushed back out again?

I know how Drupal does it, I know about the tools I've built, and I know about my future plans for audio translations. Now I want to know your dream for dealing with the translation of long documents. Forget the patches... sketches, screenshots and radical dreaming are all welcome!

There is nothing so naked as Rough Cuts

The stereotype of an author, solitary and banging away at their typewriter, is only a little bit different in the digital age. Although the typewriter has been swapped out for a keyboard and a monitor, the solitary nature of writing for print is still true. Your work is your own and you are responsible for it. Editors give feedback and sometimes they are right and you are wrong, and sometimes they are right and your ego doesn't care. Sulking is (often) inevitable.

Writing for print is not the same as writing in public, on a Web site or a Wiki, where many eyeballs make all bugs shallow. But in the spirit of release early and release often, the first five chapters of Front End Drupal have been put online in the Safari library system. There is nothing so naked as putting up content that has not gone through a copy editor. "Occasionally" is my nemesis and I'm eternally grateful there is no "broccoli" in this book because I typically fail several times before getting the speling of either of them right. If you have a Safari account and have the time to look through the Rough Cut of Front End Drupal, I'd be eternally grateful. I prefer my mistakes to meet their demise at the digital phase of this project and not move forward to print.

It's true that the book I'm working on with Konstantin is not free as in beer or speech, but the process of writing so far has taught me a lot about documentation. The process of this project has taught me a lot about the things I like, and the things I want to change about online documentation. When I first started the book I scoured the Internet to see how content had been structured before me. I wanted to see the popular solutions to common problems. I wanted to see what people needed to know. As time progressed I found myself relying mostly on the API documentation for quick references here and there as the chapters became more my "own." Was it my ego that gave up looking for best practices? Or was it simply information overload that made me stop looking at what others had done?

The book has allowed me the opportunity to think about "good" and "useful." I'm starting to form a vision of how to make the user experience of "help" better. In the past I've focused more on interactions, or documentation, but not how we interact with documentation. Addisun has had some amazing cues for my imagination and I've contributed a few thoughts to the Drupal redesign process. (Iteration #8 is now up, but doesn't have new layout stuff for docs against version 7. You may recognize the pink pen of FAIL from some of my Launchpad bug reports in the version 7 comments for the Drupal.org redesign.) One of the things that my experience this fall has taught is this: good documentation is seriously very hard. It's hard to write as a single author and it's hard to write sanely as a community.

We don't yet have a model of best practices for "help" or "documentation" or whatever you want to call that stuff that users turn to when the system is too complicated, or the UI sucks so badly that it is not "intuitive", or the task is so complex that it requires an unknown workflow that goes beyond the imagination of the user. I have spent my time in the trenches of DocBook. I love me some XML markup and could talk your EAR off about combining it with learning styles (and now my new friend video) to produce sheer, glowing awesomeness that would allow people to practically learn by osmosis...

But DocBook XML with Bazaar repositories is not exactly a friendly place for technical authors. Markup is not something that an author should have to do. Someone who cares about formatting and output? Yes. Someone who is interested in markup for learning styles? Sure. But an author should not have to crack open vim to describe a sequence of steps necessary to accomplish a task. (The fact that I'm writing the draft of my book in vim before copying and pasting the contents into OOo and saving as MS Word is not relevant to this discussion. I do it this way because I find vim less distracting than OpenOffice.org.) An author should not have to be an entire production team. We don't ask our kernel hackers to design desktop GUIs...Aside: the LDP is moving toward a Wiki for rough drafts of content and then spitting out DocBook XML that can be distributed through its network of mirrors. It will be interesting to see if this shift revitalizes interest in the project and attracts new authors.

Working on the book has been an adventure (one that has approximately 20,000 more words to it). It has captured my imagination not in the theming of Drupal (that was already interesting) but it has reminded me of how hard it is to produce good support material for our free software. It has given me the opportunity to look at projects that I've not had time for ("procrastination" is the technical term for this). It has reminded me of the challenges of multi-lingual documentation ... it has consumed me ...

But mostly it has made me wonder: why can I bang out 800+ words for a blog entry about nothing coherent but stare blankly at a page for days trying to come up with a clever introduction on theming Drupal page templates? That's right kids... it's because writing good stuff is hard and blathering on about nothing is easy.

PS For my mother, sister and for Moloney: I promise the next entry will have more crafty (or at least English) content... in the mean time, go watch the fainting goats again.

Screen casts: now with fade transitions

It was inevitable. The second you give someone the ability to make a fade, they have to try it out. It's not really PowerPoint's fault there are so many crappy slide decks out there...it's just...well...totally not really my fault. "Fade transitions?" you ask. Yes. Fade transitions. A sucker for punishment and then some I've actually managed to figure out a work flow for screen casting since my last post. It still takes way too much time (approximately 2 hours for a five minute tutorial ... four hours if you include all the failed attempts to output different formats and writing this blog post), but at least I know I can do it now. I'm slightly saddened that I can't zoom in to my video using my new tools of choice, but with a bit of tinkering and a lot more work I know that I could split the video, insert a zoomed in screenshot and then fade back to the full screen video. Yes. Kdenlive makes it that easy. And I'm not even using the new and improved version yet. (But they're using Drupal. So I was already in heart with them even before I gave the project a whirl.)

I'm using Kdenlive version 0.6 for KDE version 3.5.x (but I'm running gnome). And this is how I made that.

  1. Use gtk-recordmydesktop with the sound turned off to record yourself completing the task you want to screen cast. Don't worry TOO much about timing at the beginning because you can always add a static image in later. Do give yourself plenty of time as you're completing commands though. You can see that I had a hard time keeping up with the voice over in my second screen cast.
  2. Write out what you're going to say. Playback the screen cast to see if you can fit in all the words in time with the screen cast. Yes, I did the writing part second. It should probably come first, but I found it easier to think, and then type and watch. For my screen cast I did all the typing first and then tried to record the video while following the script and I found it to be awkward.
  3. In Audacity read your script with the screen cast running. You may need to play with things a bit. Or you may need to re-record your screen cast if you can't make the words fit in with the video. Or adjust your script to say more or less stuff to make it all work.
  4. Open Kdenlive import your video and audio clips. Drag them into the timeline at the bottom of the window. If you need to, you can "mute" the sound track on the video clip.
  5. Adjust the start of the video so that it matches with the start of the audio (drag the clips so audio beginning matches the video beginning). If you need more space in the audio, or video, to have them sync, break the clips into smaller chunks using the "split clip" tool and re-align the clips by dragging them around.
  6. Insert intro and outro slides (I made PNGs in GiMP, but I think Kdenlive has the option to make text slides from within the program). Slides are imported as clips (the same as audio or video clips). Stretch the slides so they fill the entire block that is missing video.
  7. If you needed to: split your video into smaller components and fill in the gaps with screen captures. There's probably a more elegant way to extend the video output, but I found a screen capture worked just fine (you can see the jump at the end as it jumps from the video version of the terminal to the screen shot version of the same).
  8. Export the "timeline" (aka the movie). I used the following: Medium Quality (second tab) and chose the following output format: Theora/640x480/Low quality. QuickTime and MPEG4 did not work for me. I got only audio with MPEG4 and only video with QuickTime.
  9. Upload the OGG file to your video host of choice.

The only problem left is that the conversion tools on BlipTV are unsyncing my voice and my video. It works perfectly locally, but I'm out of sync when I upload. I think this might be because I recorded the video at 15 frames per second, but Kdenlive has a default setting of 25 frames per second. Maybe the Web-based conversion tool is getting confused? I'm not sure...

Huge shouts out to Kyran and heathenx who gave me useful scripts to make my first screen cast suck a little bit less, and to Cinephiliac for letting me know that improvements are on the way to Kdenlive. I always like to hear about an active project!

Git for Teams

Git For Teams

Best selling title from O'Reilly media. Covers essential skills needed to use Git in a team environment.

Available from O'Reilly media, and better bookstores worldwide.

Collaborating with Git

Collaborating with Git

Practical how-to videos to get you, and your team, up and running with Git. A complementary video series for the book, Git for Teams.

Available from O'Reilly media.

Drupal User's Guide

Drupal User's Guide

Site building for Drupal 7. Includes in-depth information on Drupal's most popular site building modules, SEO and accessibility. Two complete case studies are included in the book along with the tools you'll need to build (almost) any Web site with Drupal.

Available from Amazon.com.

Front End Drupal

Front End Drupal

The industry go-to for learning theming in Drupal 6. A great companion to Lullabot's book, Using Drupal.

Available from Amazon.com.