Armed to the teeth, translation project team tools.

Last time, while I was discussing the visual novel translation process I mentioned that I was wondering what to write about next. I had some friends who wanted me to write about translation theory, but I didn’t want to do that yet without doing a bunch of background reading. Then, my topic just walks up to me and begs me to write about it today.

Today I’m going to talk about tools in two parts. First, I’ll write out some principles about tool selection from a team management point of view. There’s plenty of good tools out there and plenty of bad ones, the trick is learning to identify what you need really so you can pick the right tool. I’ll include some example tools and such.

Then, I’ll connect it with the rest of the series, about how translation projects are small teams, and only fools would try to manage one as they would a large corporate team. Mostly it’s breaking down a tool I learned about today, ROME that essentially misses every last point. It might not be a very good tool, but it’s a great way to learn what not to use.

What a team needs

In the grand scheme of things, a project team needs only a few things to get to work. In roughly the order of importance.

  1. A way to keep in touch, and have awareness of the group.
  2. A way to pass artefacts (data, files, etc.) back and forth
  3. Tools are simple and take minimal effort to use

Yup, that’s about it. Everything else more or less springs up from those two things. Simple! Just aim to fulfill those three needs, and you can probably do everything you need to do with your group. Remember, we’re just talking about the technology that empowers the group, not management style, procedures or whatever.

Staying in touch and awareness

In the research fields of computer-mediated communication, distributed groups, group dynamics (really, they’re legit research fields, check out CSCW and so on) etc. One thing that’s known to be very important is awareness of what’s going on in the group. They wonder why groups that are spread out geographically often don’t work as well as people all in the same place, even if they have email and phones to communicate with each other if they needed.

One of the things that come up is that there’s value in being in the same place. You’re aware of what other people are doing. You hear them complaining that something isn’t working, and maybe you go over to help. You see someone is working on the same thing you are, so it’d be better if you worked together. All this awareness is helpful in helping people feeling that they are part of the group, and keeps the group moving in the same direction without direct management.

When you can’t be in the same room, you need all sorts of tools to fill the gap, for example:

  1. Wikis, where everyone is supposed to be working on the same thing in public, so you can see it changing in front of you.
  2. Email, the classic communication tool since the dawn of time.
  3. Forums, a cross between email and wikis.
  4. Instant Messaging, now you can talk to people in real time.
  5. IRC, probably the tool of choice for small translation groups for staying in touch. Most of us stay logged in 24/7 and are around at odd hours of the day.

Most of us use more than one of these things, and you should.

However, there’s a very good reason why IRC is the tool of choice for many. It’s real time, meaning you can have changing conversations quickly. Everyone’s roughly in the same place, in the sense that if you’re talking, other members can see —- this isn’t usually the case with IM. It’s pretty low hassle, but so is email and IM, but miles ahead of forums, and even a wiki.

The key here is that you want something people are used to working with, so they don’t have to think to do it. You want them to be able to reach each other without having to go “oh, I should go contact Joe… but after get a drink”. You want to set up the opportunities for people to come together without planning to: “oh, Joe is here, so’s Sally and they’re talking about the script. I had a question about that part!”

Transferring artefacts

Note: And yes I spell artefacts with an ‘e’ out of habit from reading too many papers using it.

Aside from talking to each other, team members are there to create products/outputs/widgets, and then they need to pass them to each other so work can be done. Exactly what tool you pick depends a lot on what you’re dealing with. Script files tend to be small and portable. Scans, slightly bulkier. Video clips take serious space.

There are somethings you want to think about when picking out the right tool.

  1. How easy is it to use/set up?
  2. How reliable is it and the person running the service.
  3. What things can it handle, and what can’t it?
  4. How easy is it to make a horrible mistake?

Typical tools that people use are:

  1. FTP, ancient, does the job, requires a server. Quite popular, especially for groups that need to deal with large files like video.
  2. Email, not exactly the best way. But you can send small bits of things to each other with it in an emergency.
  3. Wiki, sure you can dump files onto a wiki. It’s like an FTP for the most part
  4. Instant messaging systems often have a file transfer component
  5. IRC has a file transfer
  6. Some kind of version control system, such as subversion”:
  7. Full powered content management systems, they’re like FTP with wikis with email, on steroids, for companies.

Artefact management can be difficult. FTP has been around forever, and has its uses. However, FTP, Email, IM, and IRC all have one major flaw that drives me insane. We’re working with living documents. A script file that changes day to day, a graphic that goes through 5 revisions, and so on. Who’s got the latest version? What IS the latest version? What’s going on!!

When it comes to working with plain text, which is 90% of the volume of work us translation teams deal with having a proper version control system makes everyone’s life easier. Sure, it’s harder to use. However, you don’t have to worry about tracking the latest version or passing files back and forth like mad. Even better, you can roll back changes if you need.

FTP and the like work best for things that don’t change quickly, such as a large video dump. There’s only going to be a few versions of it at most. I once saw a project that used FTP for scripts. Everyone had to follow a proceedure of naming files a certain way to keep track of what version everything was. Great. what happens when someone screws up, or hits delete, or renames the wrong file?

If you’re not using some kind of version control like subversion, or even CVS, or bazarr, mercurial, SVK. Do it. Do it now and don’t look back. Pick one that makes sense from a tech point of view and get away from email and the like. All my project work is on a subversion repository, even Narcissu side 2nd. It’s on a separate server, I have local copies of the project files on 3 of my machines. It’d take the destruction of a data center to destroy the project. Do that with any of the other systems? Not easily.

Wikis have a similar history feature, so those can substitute. But I find them to be complicated and annoying to use in terms of work flow.

Bringing things to reality (by bloody example)

What prompted this quick piece on tools was a link someone on my irc channel posted a link on animesuki about a tool that will supposedly revolutionize fansubbing. Right.

This ROME thing made me laugh, since it got just about everything wrong from a usability perspective. First, me and a few friends notice that it looks like a stripped/rebranded/crippled version of trac. Track is a frontend web management/collaboration system for Subversion repositories. I’ve toyed with it a bit, and it’s got bug tracking features, a wiki, roadmaps, and so forth. It’s pretty good at what it does. I know of a few open source projects that make use of it.

Update, it’s a crippled version of the Redmine engine, which is in a nutshell, trac rewritten for ruby on rails, plus support for SCM engines beyond subversion. The comments I’ve written still hold.

Now, the motivation for trac is a good one. In a large software project, or open source project, it’s very hard to generate group awareness. If you have hundreds of users requesting features and reporting bugs, you need something to keep track of them. That’s why there’s a wiki, a roadmap, and a bug tracker. It’s a way for someone to get a glance at the project, even though it’s too big for them to understand what’s going on everywhere.

What ROME apparently did was first strip out the subversion part. Yes, the versioning piece that I said was absolutely critical to life as a translator is gone. What you’re now left with is a framework that’s designed for software projects rebranded to work for fansubs. You can assign tasks (really, it’s the bug tracker) to members, you can post things onto the wiki, you can upload files (but they’re not versioned of course). You can email each other over issues, as if you never had an email account.

But for a small group of people? So, do I mark each script edit as a separate bug, assign them to myself, fix the script, the mark the task finished? Do I have to do it for every edit separately, or can I do it by paragraph? How many clicks is this going to take? Why can’t I just DO it and move on with life?

The tool has caught a good amount of flak from rightly skeptical subbers. IRC is frequently brought up, as well as FTP, with most people going “so, how is this making me do any LESS work?”

From what I’ve described previously, I hope that you’ve gotten a sense of why this tool is an amazing display if naive development on the part of the developers. It’s generating less awareness than existing tools are doing. It’s not part of most people’s accepted workflow. It’s not versioning, so you’re back to the special brand of hell that is file versioning by hand.

Worse, the developer thinks it’s better than sliced bread for fansubbers, because it’ll free everyone from the archaic IRC and FTP technology.

Back in grad school, we read a set of papers on technological determinism, the notion that if you give people a technology, it’d determine what the people did. We mostly discussed what a outdated and patently flawed idea it was.

I feel a similar kind of mocking laughter at groups who adopt full bureacratic/democratic processes, with less than 10 people. I’ve mentioned this previously in the series, but I hope the perspective I’m coming from is clearer now


Commenting is closed for this article.