An exploration of language technologies, translation education, practice and politics, ethical market strategies, workflow optimization, resource reviews, controversies, coffee and other topics of possible interest to the language services community and those who associate with it. Service hours: Thursdays, GMT 09:00 to 13:00.
This post has been updated. The good two-template solution has been improved to make a one-template solution. This is user engagement at its best in the world of memoQ.
Marek Pawelec (aka @wasaty), one of my favorite technical solution finders in translation, has published an effective improvement for those who prefer to do memSource projects in memoQ. I have done a good bit of this in the past, as I greatly dislike the limitations of the memSource local editor and dislike browser environments (from any firm) even more for translation, but the funky interpretation of XLIFF used by that tool requires some custom filter configuration to enable work to proceed without the risk to unrecognized tags. Even so, the inability to transfer match percentage information and locked status for segments gave me more than a few headaches with these projects.
Someone at Kilgray mentioned a while ago that a proper memSource filter had been considered, but that resources were, alas, focused on other priorities, like 8.x "fixes" to features that weren't broken so that life would become more interesting for legal and financial translators whose work was becoming too easy with memoQ 7.8. No matter: once again, Marek has come through with an excellent professional solution for doing memSource better in memoQ.
Some highlights of the template provided:
memSource match rates are visible in memoQ
locked segments stay locked!
"translated" status will be kept
machine pseudo-translated garbage is marked with "MT" status in memoQ
memSource tags can be converted to memoQ tags
populated segments can be given "edited" status
Currently, this template is the best technical solution for working more efficiently and accurately with memSource MXLIFF files in memoQ and will probably remain so until Kilgray does get around to creating a properly integrated filter with configurable options. So if you have valued customers who use memSource but you want to leverage all your memoQ resources to do the work better, Marek's template is for you. Check out the detailed description and instructions on his blog!
It has been interesting to see the behavior of my codornizes since I moved them from the confines of a rabbit hutch in a stall at my old quinta to the fenced, outdoor enclosures in the shade of a Quercus suber grove. In the hutch, they were fearful creatures,panicking each time I opened their prison to give water and food or to collect eggs. Their diet was also rather miserable; the German hunters who first introduced me to these birds for training very authoritatively told me that they ate "only wheat", and I felt bold to offer them anything different like cracked corn or rice. In the concentration camp-like conditions in which they lived, they also developed a serious case of mites and lost a lot of feathers. I thought about slaughtering and eating them as an act of mercy.
Then last spring I moved to a new place with a friend, who built a large enclosure for my goats and chickens. She didn't know about the quail. I brought them one day and hastily improvised an enclosure for them with a large circle of wire fence around a tree, because I was afraid the goats might trample them. There was far more space in this area than they had before, and real, dry dirt for taking dust baths. Soon the mite infestations improved (even before regular dunks in pyrethrin solution began), and the behavior of the birds began to change. They became less nervous, though sometimes when someone approached the enclosure they flew straight up in panic as quail sometimes do and bloodied themselves on the wire.
A few months later I built a much larger enclosure for a mother hen and her chicks to keep them out from under trampling feet or from wandering through the chain link fence of the enclosure into the hungry mouths of six dogs who watched the birds most of the day like Trump fans with a case of beer and an NFL game on the TV. The quail were moved in with the chickens as an afterthought. With nine square meters of sheltered space, the three little birds underwent further transformations, becoming much calmer, never flying in panic and allowing themselves to be approached and picked up with relative ease. They also exhibited a taste for quite a variety of foods, including fresh fruit and weeds such as purslane. Most astonishing of all, they began to lay eggs regularly in an overturned flower pot with a bit of dried grass. Nowhere else. All the reading I've done on quail on the Internet tells me that quail are stupid birds who drop their eggs anywhere, do not maintain nests and seem to have no maternal instincts whatsoever. I am beginning to doubt all that.
At various times in my life I have heard many statements made about the cultural proclivities of various ethnic minorities, but these assertions usually fail to take into account historical background and circumstances of poverty and prejudice, choosing instead to blame victims. In cases where I have seen people of this background offered the same opportunities I take for granted or far less than my cultural privilege has afforded me, I cannot see any result which would offer itself for objective negative commentary.
There are a lot of ignorant assumptions and assertions made about the class of digital sharecroppers known as translators. Some of the most offensive ones are heard from the linguistic equivalents of plantation owners, some of whom have long years of caring for these hapless, technophobic, unreliable "autistics" who simply could not survive without the patriarchal hand of their agencies.
Fortunately, technology continues to evolve in ways which make it ever easier to take up the White Man's Burden and extract value from these finicky, "artistic" human translation resources. The best of breed in this sense could make old King Leopold II envious with the civilization they have brought to us savage translators.
On many occasions, I have advocated the use of various server-based or shared online solutions for coordinating translation work with others. And I will continue to do so wherever that makes sense to me. However, I have observed a number of persistent, dangerous assumptions and practices which reduce or even eliminate the value to be obtained from this approach. It's not a matter of the platform per se, usually, unless it is Across to bear, but too often over the past decade, I have seen how the acquisition of a translation memory management server such as memoQ or memSource or a project management tool such as Plunet, OTM or home-rolled solutions has led to a serious deterioration in the business practices of an enterprise as they put their faith more in technology and less in the people who remain as cogs in their business engines.
As the emphasis has shifted more and more to technologies remote to the sharecroppers actually working the fields of words, a naive belief has established itself as the firm faith of many otherwise rational persons. This is expressed in many ways – sometimes as a pronouncement that browser-based tools are truly the future of translation, often in the dubious, self-serving utterances of bottom-feeding brokers and tool vendors who proclaim the primacy of machine pseudo-translation while hiding behind the fig leaf argument that we need such things to master the mass of data now being generated. It is fortunate for them perhaps that this leaf is opaque enough to hide their true linguistic and intellectual potency from public view.
A related error which I see too often is the failure to distinguish between the convenience of process and project managers and the optimum environment for translating professionals. I don't think this mistake is malicious or deliberately ignores the real factors for optimal work as a wordworker; it's simply damned hard much of the time to understand the needs of someone in a different role. I could say the same for translators not understanding the needs of project managers or even translation consumers, and in fact I often do.
So indeed, the best tool for a project manager or a corporate process coordinator might not be the best tool for the results these people desire from their translators. Fortunately, this is usually a situation where, with a little understanding and testing, both sides can win and work with what works best for them. The mechanism to achieve this is often referred to by the nerdy term "interoperability".
Riccardo Schiaffino, an Italian translator and team leader based in the US, recently published a few articles (trouble and memoQ interoperability) about memSource, a cloud-based tool whose popularity among translation agencies and corporate or public entities with large translation needs continues to grow. High-octane translators like Riccardo and others have trouble sometimes understanding why these parties would choose a tool with such great technical limitations compared to some market leaders like SDL or memoQ, but the simplicity of getting started and the convenience of infrastructure managed elsewhere on secure, high-performance servers with sufficient capacity available for peak use is an understandably powerful draw.
And the support team of memSource and the tools developers are noted for their competence and responsiveness, which is equal in weight to a fat basket full of sexy technical options.
So I will not argue against the use of memSource by agencies and organizational users whose technical needs are not particularly complex and who do not have concerns about a tool almost entirely dependent on reliable, high bandwidth internet connectivity at all times to fulfill its key promises. In fact, it's a good and easy place to start for many, perhaps more so than the rival memoQ Cloud at present, which suffers sometimes from limited capacities (at the same data center used by memSource and others!) during peak use. Unlike the barbed-wire, unstable and unfriendly solution Across, which has achieved some popularity in its native Germany and elsewhere through sales tactics relying on fear, uncertainty and doubt regarding illusionary or delusional data security, memSource works, works well, and the data are portable elsewhere if a company or individual makes another choice some day.
But damn... it's just not very efficient for professional work, especially not for those of us who have amassed considerable personal work resources and become habituated to other tools like SDL Trados Studio, Déja Vu or memoQ like a carpenter is to his time- and work-tested favorite tools. Trading one of these for the memSource desktop editor or, God forbid, the browser-based translation interface feels worse than being forced to do carpentry with cheap Chinese tools cast from dodgy pot metal. Riccardo mentions a few of the disadvantages, and I could fill pages with a catalog of others. But compared to some other primitive tools, it's not so bad, and for those with little or no good experience with leading translation environment tools, it may seem perfectly OK. You don't miss a myriad of filtering options to edit text or sophisticated QA features if you are still amazed that a "translation memory" can spit out a sentence you translated once-upon-a-time if something similar shows up six months later.
And as mentioned, memSource - or some other tool - may indeed be the best solution on the project management side. So what's a professional translator to do if an interesting project is on offer but that platform is unavoidable? Riccardo's tips on how to process the MXLIFF files from memSource in memoQ offer part of a possible good solution which would work almost equally well in most other leading tools as well these days. One additional bit is needed in the memoQ Regex Tagger filter to handle the other tag type (dual curly brackets) in memSource, but otherwise the advice given will allow safe translation of the memSource files in other environments. I can even change the segmentation in memoQ if, as usual, the project manager has failed to create appropriate segmentation rules in memSource to accountfor some of the odd stuff one often sees in legal or financial texts, and this does not damage or change the segmentation seen later when the working file is returned to memSource.
Even concerns about the "lack" of access to shared online resources in memSource if an MXLIFF is translated elsewhere are easily addressed. A few useful things for this include:
pretranslation of the memSource files to put matches into the target before transferring to other environments,
leaving the browser-based or desktop editor for memSource open in the background for online term base or TM look-ups, and
occasionally exporting and synchronizing the MXLIFF in memSource to make the data available to team members working in parallel on a large project - this takes just a minute or two and allows one as much time as needed for polishing text in the other environment.
The last tip is particularly helpful to calm the nerves of project managers who are like mother hens on a nest of eggs which they fear might in fact be hand grenades and who panic if they don't see "progress" on their project servers days before anything is due. One can show them "progress" every twenty minutes or so without much ado if so inclined.
I am past the point where I recommend any translation memory management server in particular for agency and corporate processes. There are advantages to each (except Across, where these are actually hallucinations) and disadvantages, and where I see real problems, it is seldom due to the choice of platform but rather the lack of training and process knowledge by those responsible for the processes. The bright and shining prospects of a translation server are easily sold with a slick tongue, but without an honest analysis and recommendation of needs for initial and ongoing staff training these too often end up being bright and shining lies. I think very often of a favorite German customer who invested heavily in such a system four or five year ago and has not managed one single successful project with the system in all that time. This makes me sick to think of the waste of resources and possibilities.
So on the project management and process ownership side, memSource may be a great choice. Certainly some of my clients think so, and the improvements in their business often back this belief up. And for those who work with gangs of indigent, migrant or sharecropping translators whose marginal existences make the investment in professional resources like SDL Trados Studio or memoQ seem difficult or undesirable, it may be all that is needed by anyone.
The good news for those who depend on the efficiency of a favored tool, however, is that with a few simple steps, we need not compromise and can get full value from our better desktop tools while supporting interesting projects based in memSource. So each side of the translation project can work with what works best for them, without loss, compromise, risk or recriminations.
And the translating quail who start out in a dark box with a stunting lack of possibilities can look forward to the real possibilities of work liberation in a larger environment richer in healthy possibilities and rewards.
From mid-October until the end of 2013, I placed two small survey questions at the top of the blog page and publicized these in a variety of user forums. The questions were similar to two posed in 2010, because I was interested to see how things might have changed. This is, of course, an informal survey with a number of points in its "methodology" wide open to criticism, though its results are certainly more reliable than anything one can expect from the Common Sense Advisory :-) My personal interest here was to get an idea of the background readers here might have with various translation environment tools, because it is useful to know this when preparing posts on various subjects. Here is a quick graphic comparison of the 2010 and 2013 results:
Responses to the question about the number of translation environment tools were very similar in both cases. About half use only one, with between 25 and 30% of respondents using a second tool and increasingly small numbers going beyond that. The question posed covered preparation, translation and checking in projects, so some respondents using multiple tools may be translating and maintaining terminologies and translation memories in only one tool. I am encouraged by this result, as it means that despite changes in the distribution of particular tools, users are exercising good ergonomic sense and predominantly sticking to one for their main work. Everyone benefits from this: translators generally work more efficiently without tool hopping, and more effort is focused on what clients need - a good translation.
In 2010, half the respondents cited the use of some version of "SDL Trados" (more details on this were provided in a later survey); the next highest responses at just under 20% were for Déjà Vu and memoQ. Three and a half years later, Atril's share of users appears to have declined considerably, and the use of memoQ appears to be about on par with SDL Trados Studio. OmegaT, an excellent free and Open Source translation support tool capable of working with translation formats from the leading tools, appears to be doing better than many of the commercial tools in the survey, which should not surprise anyone familiar with that software.
Across continues to be a loser in every way. Despite massive efforts in the low end of the market to promote this incompatible Teutonic travesty and the availability of the client software free of charge to its victims (translators), no real progress has been made in the Drang nach Marktanteil. One would expect that a good solution supported by a competent professional development team and a marketing budget, available free to translators, would easily beat the low-profile OmegaT. And I am sure that this is the case. The case simply doesn't apply to Across, which drives some of the most technically competent translators I know completely berserk. The fact that OmegaT is about twice as popular despite its volunteer development and total lack of marketing budget speaks volumes.
More important than any of the individual figures for translation support tools are some of the implications for interoperable workflows that the numbers reveal. Most of the tools listed support XLIFF, so if you use a tool capable of exporting and reimporting translation content as XLIFF, developing an interoperable workflow for translation and review that will work with the majority of tools will probably not be that difficult. An XLIFF file from SDL Trados Studio or memoQ is usually a no-brainer for translation in Déjá Vu, OmegaT, Cafetran or Fluency, for example, and any concerns can be checked quickly with a "roundtrip test" using pseudotranslation or simply copying the source text to the target, for example.
While individual tools have largely improved in their mutual compatibility and ability to share translation and resource data, there is legitimate continuing concern about the increased use of translation servers by translation agencies and corporations with volume needs who manage their own translation processes. Jost Zetsche and I have expressed concerns in the past regarding the lack of compatibility between server platforms and various clients, though with the appropriate use of exchange formats, this can still be overcome.
The greatest challenges I have seen with server-based work is that the people creating and "managing" projects on these servers often lack a basic understanding of the processes involved, so that the skills of the translators competent with a particular client tool may be effectively nullified by an incompetently prepared job. I experienced this myself recently where segmentation, termbase rights and even the source language were set wrong on the server, and the project manager had no idea how to correct the situation. However, things worked out in the end, because I had a playbook of strategies to apply for such a case. In the end, better training and a good understanding of the interfaces to the processes our partners use can get us past most problems.
