Subversion 1.6 Introduces Welcome Improvement for Localization Projects
Posted on Fri, Aug 21, 2009
Today
Jim's talking about Subversion 1.6...
Howdy!
Are you a fan and/or user of the open-source version-control system Subversion®? If you're like me, you may have missed that back in March of this year the tool underwent a fairly substantial update - version 1.6.
Someone at CollabNet must have been reading my mind, because the 1.6 update includes a significant change that addresses one long-standing pain point for me - file-level granularity in the svn:externals property. Before 1.6, you could specify folders but not files, but now the externals property supports individual file definitions too. :-)
Why do I care about being able to include individual files within an externals definition, you ask? To explain, I should briefly explain one of the common ways that Subversion is used in Lionbridge on localization projects.
Subversion in a Localization Project
Like other code development projects for which Subversion was actually designed, a localization project can be looked at as a set of files which undergo a series of changes based on the contributions of the project participants. In the localization world those contributions tend to be more focused on language activities (i.e. translation), however.
Subversion is great for managing localization projects. In addition to providing version control, an SVN Repository can act as the hub of an on-demand, pull-based file distribution system - allowing dozens of translators and other participants to be working simultaneously without the need of a file dispatcher (read: bottleneck). Combined with Logoport-based online TMs, such a mechanism supports round-the-clock progress and parallel processing on even very complex, high-volume projects.
When designed properly, files will remain in their natural directory structure throughout the process, avoiding the need to shuffle-around files into different packages at different stages - at best an inefficient process and at worst a potential source of error.
The Pain Point
One challenge with having contributors interact directly with a Repository, however, has been in trying to prevent those folks from having to check-out files which aren't relevant to them. German translators, for example, probably have little interest in the localized resources for French, Spanish, Japanese, Czech, Russian, etc - so it makes sense to try to spare them the burden of having to download these files on check-out.
This is easier said than done, unfortunately. Of course if resources are segregated by language-specific sub-directories, you could always provide the German translators the path to the subdirectory containing the German resources, but if we have many language subdirectories (one per component, for example), we're hardly making their lives easier by doing so.
Enter "Custom Modules"
One technique that we've employed is the concept of modules (borrowed from the CVS world) - essentially an empty directory that is unique to a particular role and is "loaded" with externals pointing to all relevant subdirectories for that role.
For example, the German translators would be directed to check-out ProjectName/CustomModules/GermanResourcesModule
...an empty directory that includes an externals property which "links" to the following subdirectories within the "natural directory structure":
ProjectName/NaturalDirectoryStructure/SomeComponent/GermanResources
ProjectName/NaturalDirectoryStructure/AnotherComponent/GermanResources
ProjectName/NaturalDirectoryStructure/YAComponent/GermanResources
In essence the German translators get a custom package that includes only those directories which are relevant to them, but the files themselves remain linked to their natural home within the natural directory structure - the best of both worlds!
Unfortunately, since the externals property only supported directories prior to version 1.6, this technique would only work if your languages were segregated by subdirectory. If all your language resources live together in one directory (identified by a prefix or suffix in the file name, for example) this technique would simply not work.
But now since you can specify individual files in the externals property (hopefully supporting a regular expressions syntax), hopefully this limitation is a thing of the past.
I haven't actually installed version 1.6 yet, but this upgrade would seem to be worth the effort.
What do you think?