Waiter, there's a wiki in my translation!

Wiki this, wiki that, it’s all the rage when it comes to ‘community efforts’ and VN translation is no different. But is it really the “next big thing”? If it is, I’d like someone to enlighten me, because I’m only seeing it as a relatively new competitor in a crowded marketplace of tools.

So let’s make a deal, in this article, I’m going to lay out what stand out in my mind as some major points that I think stand in the way of wiki-based translation from being successful. I’ll lay out my underlying assumptions, and my reasoning, so you can pick them apart as much as you want. In exchange, if you’ve got a problem with something, you lay out your arguments on the table in a similar way.

Oh, and to save time, I’m not debating about whether wikis are useful, or “can work” in general. I’ll leave that flamebait to wikipedia and other places. I’m talking only about their use in translation projects and the issues unique to that situation. Also, I’m talking about things in general, over time, across projects. The fact that any one project might have worked is, in my opinion, because the project survived despite these problems, not because the problems don’t exist.

Oh, and if you want to play the “if you’re so hot, why aren’t you contributing” card, save it for an upcoming article. That one is worth dealing with on its own so you’ll get your chance soon enough.

So let’s start.

Someday a savior will come

Every time I have a debate about wiki over… almost anything… this one gets trotted out. “Who does the translation?” “Who does the editing?” “What if it’s wrong and needs correcting?” “How will style be handled?” “Who’s doing the release?” “Who decides if things are ready to go?”

The answer, invariably, is “eventually, someone who is able do it will come and do it”.

Well that’s just great for the people maintaining the wiki. But when is that exactly? As a user, I’d want the translation done yesterday, so that’s not very satisfying for them, but who cares about users.

As an aside, for the most part, many of us translators, private projects or not, don’t particularly “care” about users, not in the sense that I care about the welfare of my friends — how much can you care about a generalized mass of entities? Some are simply out for the glory and ego from making a release. Others just want to share the story, and are satisfied once it’s “out”. Others are doing it for language practice and really don’t care if a release happens or not. The list goes on forever, but “because users deserve it” don’t enter the picture too often.

But still, the whole point of having a project is to complete it, right? While there might be fun in creating a hundred open projects, the plight of the world hasn’t changed if you just start things and never finish them.

Taking a glance at the TLwiki’s VN section today, I’ve counted 10 projects that have “Translators” in their “Wanted” list, out of 26 projects that aren’t colored red. That’s a lot of saviors needed, and if you want any of those projects to finish, they’ll have to appear somehow.

So then, how do saviors appear? There’s two ways I can think of offhand. Since it’s a public web site, there’s always the chance that some guy out there who’s bored will stumble over and do a piece of work. If you had a hugely popular site with lots of visitors, the chances of this happening increases, but who knows what the percentage is besides “low”. Since translation is a specialized skill, non-translators outnumber translators.

The other way would be to go out, and convince someone skilled to come work on the project. But attracting someone skilled however, to me, seems to become more difficult with a wiki.

The mediocrity attractor

It’s obvious that in the wide world of the Internet, you (potentially) have access to every sort of translator that exists. It should also be pretty obvious that you can rank translators on some measure of skill (take your pick) and that as you go down from “very very good” to “almost clueless” the number of people in each category goes up, (probably exponentially if I had to guess).

If we assume that anyone of any skill level has the same chance of deciding “oh hey, I want to work on this project”, you’re going to have more people closer to “clueless” join than “very very good” ones. And if you’re thinking that the clueless people would self-regulate themselves, and not post translations, I submit this history item where someone is openly saying they are using software translation.

A main philosophy point of wiki is that it is easy for people to make a mess on a wiki (e.g. vandalism, wrong material), but easy for people to clean it up (e.g. reverts, counter edits). But in this case, is it all that easy? Checking a translation is not something everyone can do, and takes a certain amount of time since you need to come up with an approximate translation in your head to check against what’s there. If it’s wrong, a new translation has to be provided.

What does this look like from the perspective of a translator? The more skilled they are, the more work they tend to see that needs to be done. If you know nothing about the language, all you see is that “out of 1000 lines in stuff I can’t read, 500 have English next to them”.

For someone who’s okay, but not awesome, they’d see 500 lines that need doing, 150 done by that software translator and need redoing, and 350 that are done by other humans.

For someone who really knows what they’re doing, they see 500 need doing, 150 are done by that guy who’s using software and needs complete redoing, 100 by someone who knows what they’re doing so I can leave it alone, 250 by 10 other people. Those 250 will probably need checking over, but hopefully they’re okay.

Hell, the Saya no Uta project’s original set of scripts were supposedly so bad that subsequent translators that picked it up eventually decided to throw the entire thing out in favor of doing it from scratch.

Oh, and while we’re at it, I’ve yet to find a wiki equivalent to my “svn blame” command that would let me say, find out what lines were contributed by what person in a merged file so I can selectively target such instances if I were inclined to do mass correcting.

As skill goes up, the less attractive a project becomes if you care about overall quality because there’s increasingly more things to do. So what a wiki would be looking for are people who are good, but don’t get too worked up about having their good work put next to work that isn’t so good, or have the energy to clean up the rest on top of everything else they’re doing. They can only hope that if they make changes, there’s no bizarre argument over what’s right or not.

I don’t deny that such people exist, that’s not the point of this argument. What I’m pointing out here is that there is a barrier to entry that gets more difficult as skill increases. You’d think it’d be the reverse.

What you ultimately get is a pooling of mediocre talent. They’re “about good enough” for the task at hand but aren’t good enough to be hit by the amount of re-work that needs to be done. It’s a talent pool that consists of people who think they’re good enough, or who only have the dedication to stick around for a limited amount of time, and if you’re lucky the occasional altruist who knows up from down.

Social loafing

I think most social psychology students have heard of the bystander effect which is a rather robust and dramatic effect in the field. It sets the stage for a similar social problem that can easily exist in a wiki. Most commonly, I see it referred to as social loafing.

Essentially, “I can slack off because there’s so many other people looking at this, I’m sure someone else will fix it.” Hey, doesn’t that sound familiar? Someday, someone, somewhere, will come and fix whatever needs fixing on the wiki… (hint: scroll up).

Sure you have the choice of what you want to do, or if you want to work. Is the “being valued by the group” there? For some, yes, for others, maybe not so much. If a ‘better’ translator comes and clobbers all the bad work out in quiet edits, what’s left for the corrected translators to do? Do they continue, knowing they’d be clobbered?

Workflow? Do I get fries with that?

With a wiki, you have your perfect version history of all the files, so you can always look at all the previous versions and the differences between any two arbitrary versions. You can post things, edit things as much as you want, and since scripts are always in text, what more can you ask for, right? Well, maybe I just fail at using Mediawiki, even though I’ve set up a few for work previously. The workflow is just horrid for group translation.

As near as I can tell, there’s no facility for merging, or even simultaneous editing of a given page. Of course there’s no local editing away from the Internet unless you prepare yourself ahead of time by copying files over(at which point you pray you don’t clobber someone else’s work when you get back).

But that’s okay, since there’s apparently so few translators around, the likelihood that you’d edit the same page at the same time is close to zero. Same goes for editors. Everyone just needs to coordinate with each other on IRC or something every so often if it starts happening.

Already I’ve mentioned the lack of the ability to ‘blame’ lines on a given user/revision number. I hope that no one takes a good line, changes it to a bad line, and a non-translating editor needs to go back and figure out which rev I need to reverse.

Less of an issue, but final script insertion involves having to pull that text off the wiki into text files for the tools.

Alternatives

So first, why must we have things set up to wait for saviors, and then have an environment that doesn’t exactly encourage them to participate? What you’re looking for is one or two really good people who have motivation. This is before issues about wiki, or private project, or whatever.

A wiki is merely an exit strategy should the people not work out. You can quickly replace the broken cog with a new one since everything’s stored out in the world anyway. But you pay a heavy price in your ability to attract talent in the first place for the reasons I put forward above.

And don’t be fooled into thinking that you need an army of people to complete a single project. Take a look at the amount of work done on any of these wiki projects you’ll quickly find that the old 80/20 rule is in effect. 80% of the work is done by 20% of the people. Demonbane got to over 50% thanks to one translator, Chaos;head apparently has done the same. Vast tracks of AIR was completed by one person, then a second team before it was wikified.

Why? Because they were motivated and as luck had it they found their way onto the project (or the wiki inherited the old project files in the case of AIR). Would these projects have lost anything if the scripts weren’t on a wiki? Would they have gained something if they were on something else?

Workflow. I think the workflow is horrible and only serves to make people working on it miserable. You know versioning of text files isn’t hard to get. Go back a few decades and you’ve got CVS. Come into the modern age, and there’s buckets of revision control systems. I use subversion, I’ve seen others put to use. With a decent version control, I can work with actual files, using an actual text editor. More cool systems let me merge, compare, track history down to lines, make branches. If you wanted to make your work “public” for the world to edit, then fine, allow anonymous editing, it’s not difficult.

So, this is my argument thus far. A wiki is simply a tool, and it’s got lots of flaws in it when it comes to using one to conduct a VN translation project. It drives like a cow, and has the attractiveness of one from the outside. At best I can only see a wiki being a support tool for a project, while the real work goes on somewhere else. It’d serve fine as a scratchboard and random project tracking resource, but there’s got to be hundreds of other ways to do things better.



comments



  1. 08/11/2010 02:22 AM | #

    All good points, but they are not really points against wikis, but simply how they are traditionally used.

    As for TLWiki, if you take a look, you’ll notice that the projects that actually got completed and released and had somewhat of a good quality had a team behind them, much like any other, non-wiki translation effort. The point of the wiki was not to crowdsource the translation. The point was to make it totally open to visitors to be able to see what was going on, and furthermore just to have an easy way to share data without using a VCS. Basically TLWiki is a wiki because wikis are 1) websites; 2) editable; 3) have a lot of tools from other communities that you can work with, such as familiar design/formatting of status pages, raw page downloads and dejunkers, uploaders, file storage, etc. etc.

Commenting is closed for this article.