Monday, October 21, 2013

Concordance blues

CAT tools' concordance features are usually more helpful to translators than fuzzy matching, especially in the long run - I consider my translation memories as a growing treasure that I can search to see how I translated something in the past, and for that it doesn't matter if the segments are not similar enough to suggest a fuzzy match.

But sometimes the way concordance works in some CAT tools leads me to wonder whether CAT tool programmers realize that when we search for a match in our translation memories we are not looking for a completely different word.

For example, if I'm trying to find whether or not I had previously translated "rocking strip" (a piece of a thrust bearing), getting a reminder of how I previously translated "backing strip" (the strip of paper that covers an adhesive) is worse than useless:

it just wastes time, without helping me one bit.

The example above is from Studio 2011, but I've seen similar mismatches in other translation tools. (Before anybody comments: no, I've not enabled the "character-based concordance search" for this - or any other - memory.)

I'd really like to know why CAT tools' programmers think providing this kind of results could be helpful: what's the rationale behind them? Has any translator asked for this type of matching? Would it be helpful for certain languages? (If so, shouldn't it be enabled only for those languages, and not for all of them?)

Friday, October 18, 2013

Java problems in Multiterm

Once again, Multiterm is suffering from Java problems: it seems that the latest updated to Java (7.45) creates various problems with Multiterm (for more details, see article 4956 in SDL's knowledge base)

While SDL has been very timely in signalling the problem, and in publishing a workaround in the KB article, saying that this is not an SDL-created problem (as SDL representatives are saying for example on ProZ) is, I think, disingenuous.

Yes: the actual problem is caused by Java, so it is ultimately Oracle's fault, BUT

  • It is SDL who decided to use Java - so it is SDL who is responsible for using Oracle's unreliable and/or defective technology.
  • It is SDL who keeps on using Java - despite previous instances of problems caused by Java: as far as I can see SDL fine-tunes their tools to a specific version of Java (7.25 in this case), and then they cross their fingers and hope that the next version released by Oracle won't break Multiterm.
  • When (not if) such problems happen, SDL have little recourse but to recommend to uninstall the latest Java version, and reinstall the previous one. This may bring back the Multiterm functionality, but, presumably, at a cost: if the new version of Java has been released to solve newly-discovered vulnerabilities in the previous version, SDL is asking its customers to stay open to said vulnerabilities.

This, to put it mildly, is not a "best practice" (though SDL claims it as such in their KB article: "Step 3: Follow-up for Best-Practice to avoid the question to install Java 7 Update 45 again.").

My questions:

  • Why does SDL keep on relying on Oracle's defective technology?
  • What is SDL doing to permanently solve these recurring issues?