Just a quick post to see if anyone else out there who finds this article via Google or wherever is interested in solving some of the translations issues with InDesign by using XLIFF. XLIFF is a standard XML-based format for storing translations, simplifying your translations workflow by making the actual containing format for the translations standard – and then having various software vendors implement import/export features to/from XLIFF.
Currently InDesign does not have any integration with XLIFF. However, InDesign 4 is scheduled to have a great deal more XML support, and there is a possibility that we can get a workable XLIFF import/export workflow happening. Anyone else interested?
For any of you folks out there that have the unfortunate circumstance of having two SVN repositories which both have to be read/write, there is a way to easily do this using SVK.
I had some help on this from this article here: http://wiki.opengarden.org/User%3APeteE/Synchronizing_SVN_Repositories_With_Svk That article covers what to do if you are synchronizing only in one direction. You can in fact synchronize in both directions, so here’s instructions with that in mind:
After downloading and installing SVK, initialize the default depot (storage location for SVK data):
svk depotmap –init
You can also make a separate depot specifically where you will keep the two repositories you are synchronizing.
svk depotmap /syncstuff/ c:\repo\syncstuff
Now, for some reason when I did this (hopefully some SVK guru can explain this and I’ll update the article), I had to manually copy the contents of my HOME_DIR/.svk/local folder into the path above (c:\repo\syncstuff\), otherwise it produced the error: Can’t open file ‘c:\repo\syncstuff\format’
Once that’s done, you use the mirror command to associate a path in SVK with a repot SVN repository. You do this for each repository, e.g.:
svk mirror /syncstuff/mirror1 https://svn.mirror1.com/
svk mirror /syncstuff/mirror2 https://svn.mirror2.com/
The above commands only perform the association of the path in SVK with the remote repository – it doesn’t actually copy any data.
Use the sync command to synchronize each set of data (pull down each of the revisions locally into SVK):
svk sync /syncstuff/mirror1
svk sync /syncstuff/mirror2
While you could the next part in various ways, when I tried this I started with all of my files in the first repository (mirror1, let’s say) and the second repository was empty. So the first task was to merge from mirror1 to mirror2. When you do this you’ll want to include the –baseless options, which tells SVK that the source trees are totally different sets of information and we are going to sync them (as opposed to after you have synced everything up, you omit this flag to let SVK optimize what it’s doing since it now knows that these two trees were once the same and we’re just syncing new modifications):
svk smerge –incremental –baseless /syncstuff/mirror1 /syncstuff/mirror2
Then, you can merge in both directions like this:
svk smerge –incremental /syncstuff/mirror1 /syncstuff/mirror2
svk smerge –incremental /syncstuff/mirror2 /syncstuff/mirror1
You’ll end up with the same code in both places. See below for caveats.
So far the only gotcha I’ve run into is that you have to resolve conflicts in both directions. This can be painful if you have too many conflicts. So far, it’s worked for me, with the conflicts being relatively minimal.
Bear in mind that conflicts are often the result of lack of coordination among developers, rather than technical issues (i.e. two people [re]writing the same section of a project is not a technical problem, it’s an administrative problem.). At least that’s my viewpoint anyway.
Anyhow, if you’re looking for bidirectional SVN repository synchronization – hopefully this helps.
In the end, the project that this article was based on experience from eventually failed. The conflicts got too far out of control and after spending scores of minutes resolving conflicts in both directions (which seem to start repeating again and again once things get out of sync) at each synchronize, I finally gave up.
Apache XMLBeans is an excellent and simple library for managing XML through a set of custom classes that match the XML’s schema definition (from an .xsd file). It does a similar thing to JAXB, but is IMO simpler to use and less error prone. XMLBeans also does a better job of preserving the the formatting of XML that you read and is apparently very fast in comparison to other similar solutions.
How it Integrates with the Build
In essence, you use it like this:
Create an XML schema document that …
XMLBeans performs code generation (i.e. it creates .java files) for each of the elements of your XML schema. When you perform this code generation is up to you, but I found it most workable to simply run it as part of the regular build process – generating the source code into the source tree of the project and then letting the regular build process compile that (there are other compile options, including having XMLBeans compile it’s own code – I like to be able to see the source, just in case; also you can just run the code generation manually whenever the schema is updated instead of after each compile). This ensures that any schema changes are reflected in the generated code on your next compile. Fortunately, schema generation tends to be very fast for relatively small XML schema (only a couple of seconds on a decent machine) so it shouldn’t bother you too much.
After XMLBeans does it’s code generation, you’re pretty much home free. As long as you have the right jars in your class path you can just start hacking away. See the XMLBeans tutorial for how to get rolling.
Configuration with Netbeans
After trying a few different configurations for this, I’ve arrived at the following as the technique that seems to work the best with Netbeans (tested with Netbeans 6.0 and 6.1):
- Download and extract the latest version of the XMLBeans binary distribution (2.3.0 as of this writing): http://xmlbeans.apache.org/sourceAndBinaries/index.html#Current+Release
- Add the following jar files to your project (pretty simple, eh? – try adding all of the dependencies for Hibernate sometime when you want a comparison)
- Now you’ll need to define the Ant task, which is as simple as adding this to your build.xml (you of course need to replace out the PATH_TO_JARS with the correct path, relative to the root of your project):
- Now you create the target that will perform the code generation. We use the Netbeans -pre-compile target which is executed as part of the Netbeans Ant build before the actual compilation occurs. Here’s an example of how this goes (the comments describe what you need to modify for your project):
<!– set ‘dir’ to the path where the .java files go and ‘includes’ to where
to find your XML schema –>
<fileset dir=”src/org/whatever/schema/” includes=”**/*.xsd **/*.xsdconfig”/>
- If you wish to customize which package your Java classes will be generated in, you must create an .xsdconfig file and place it along side your .xsd file. Example:
<?xml version=”1.0″ encoding=”UTF-8″?>
- Now build your project. You should be all good to go!
Comments are welcome!