Wordfast Pro: Translating memoQ bilingual RTF tables

After a recent crisis an agency friend of mine experienced when a translator did a large job of some 22,000 words and was unable to incorporate corrections by a reviewer (resulting in a rather creative but stressful rescue effort involving memoQ LiveDocs), I resolved to have a look at WordFast Pro myself and see if there wasn't some better, easier way to work with translators who have this tool.

The current version of WordFast Pro doesn't support XLIFF, so that's out as a possibility. However, it does read RTF files, so I tried the same techniques which have recently proved successful for improving the interoperability workflows with Trados TagEditor and SDL Trados Studio among others. And indeed this approach was successful.

A view of the memoQ bilingual RTF file imported into Wordfast Pro for translation.
By hiding the red tags with the mqInternal style, the tag content is protected in Wordfast Pro

To prepare content in memoQ for translation in WordFast Pro, do as follows:

1. Copy the source to the target for the entire text.
2. Export a bilingual RTF file.
3. Hide all the content of the RTF file which is not to be translated.
4. Use the search and replace function in your word processor to hide the dark red text for the tags, which are marked with the mqInternal style. The settings for the dialog in Microsoft Word are show below and are set using the Font... option (marked with a red arrow in the screenshot) in the Format dropdown menu of the Replace dialog.
   
   
   
   
   
   The font color to hide will be found under More Colors... in the font colors of the font properties dialog:
    
   
   
   In this way, the translation can proceed without the risk of damaging the text constituting a tag, and the QA features of Wordfast Pro can be used to do a tag check before delivery.
   
   
   After the translation is completed and the tags have been checked, export the RTF file and unhide all the text. If there is a comments column available, any comments which are added to the table will be importe back to memoQ for feedback.

SDL Trados Studio: Translating memoQ bilingual RTF files

Some time ago, I noted that SDL Trados Studio experiences difficulties importing XLIFF files in which the sublanguages are not exactly specified if the default languages are not set to the same major language. So if you plan to translate an XLIFF from memoQ or another tool in SDL Trados Studio, it is necessary to ask the one generating the file to specify the sublanguages or, if that is not practical, use the workaround described here. I discovered this bug before the release of the 2011 version of Studio and spoke to SDL development and management staff specifically about this at the TM Europe conference in Warsaw, but apparently this is not a priority to fix compared to other issues, and it may be a while before SDL Trados Studio users can work with client XLIFF files without coping with this headache.

Several of my client agencies using memoQ for project management have quite a number of freelance translators using various Trados versions and who have no intention to stop doing so. It's important to work smoothly with these resources in a compatible way, which also protects the data and formats. In a recent article on processing memoQ content with Trados TagEditor, I published a procedure I developed which enables the memoQ tags in the text of the bilingual RTF table export to be protected as tags when working in SDL Trados TagEditor. Now I would like to present a similar approach for Trados Studio users, which can serve as an alternative to XLIFF exchange.

If the bilingual RTF table is created in memoQ specifying the mqInternal style for tags

this style setting can be specified as non-translatable in SDL Trados Studio. To do this, select the menu choice Tools > Options, and in the dialog which appears under File Types, add the mqInternal style to the list of styles to be converted to internal tags in the appropriate formats (RTF, and just in case the file gets re-saved as a Microsoft Word document, for Microsoft Word 200-2003 and Microsoft Word 2007-2010 as well):

SDL Trados Studio dialog for setting RTF, DOC and DOCX styles as "non-translatable" (converting to tags)

Once the mqInternal style has been entered this way in SDL Trados Studio, the prepared bilingual RTF file can be imported. "Preparation" for import includes copying the source text to the target and hiding all the text you do not intend to translate (the file header, the source column, and the comments and status columns if present). The result will look something like this:

The prepared memoQ bilingual RTF file imported to SDL Trados Studio. Note that the bold and
italic type are displayed normally as in memoQ, which offers the translator greater working ease.

Please note that the same procedure described for working with these files in TagEditor (hiding the red text of the tags, see the TagEditor article for details) also works for SDL Trados Studio, but this method involving the mqInternal style saves a few steps.

Clean up the tag mess with CodeZapper for all CAT tools

Readers of this blog probably know by now that I am a Dave Turner fan. His CodeZapper macros have probably saved me hundreds of hours of wasted time over the years (not an exaggeration), and I think there are a lot of other translators and project managers with similar experiences. It doesn't solve every problem with superfluous tags, but it solves a lot of them, and Mr. Turner works steadily at improving the tool. I blogged the release of the latest version not long ago; it is now available directly from him for a modest fee of 20 euros (see the link to the release announcement for a contact link). That means it pays for itself in far less than an hour of saved time.

Over the past few days I have been updating some training documentation and running a lot of tests on tagged files as part of this. During this work, I have been struck time and again by the differences in the tags "found" by different tools working with the same file. Sometimes one tool looks better than another, but the patterns are not always consistent. What is most consistent is the ability of CodeZapper to clean up the files in various versions of Microsoft Word and make the tag structures appear a little more uniform.

Here's an example of the same DOCX file "unzapped" in several tools:

Import into memoQ 5, as-is, no tag clean-up. Previous versions of the same file showed more tags in places.

SDL Trados Studio 2009 before tag clean-up.

TagEditor in SDL Trados 2007 before tag clean-up

Initially, OmegaT would not import that particular DOCX without a tag cleanup. I reported the problem to the developers, who upgraded the filter to handle a previously unfamiliar character in internal paths of the ZIP file (DOCX is actually just a renamed ZIP package like many other file types). See http://tech.groups.yahoo.com/group/OmegaT/message/23931 for information on the new release. Opening, editing and re-saving the troublesome file enabled it to be imported after all without the latest version bugfix. So users should keep that trick in mind perhaps if a similar problem is encountered. I've had to do similar actions in the past with other tools, so this is probably a good general tip to keep in mind regardless of what tool you use. When I downloaded an tested the latest standard release of OmegaT (2.3.0_4), the tag structure looked fine - no zapping of the DOCX was necessary in this case.

After treatment with CodeZapper, the file looked the same in memoQ (where the extra tags weren't present in the first place, though one can't count on things always being this way). The view in Trados Studio and TagEditor improved significantly, though there were still more tags, and OmegaT accepted the DOCX after tag cleaning.

SDL Trados Studio 2009 import of the DOCX file after tag cleanup with CodeZapper

SDL Trados 2007 TagEditor import of the DOCX file after tag cleanup with CodeZapper

OmegaT import of the DOCX file after tag cleanup with CodeZapper (OmegaT 2.3.0_3)

It is important to consider that superfluous tags mean wasted work time with formatting and QA corrections, perhaps even a higher risk of file failure (such as the inability to import the file at all into one tool). This is why for some time now, I and others have advocated modifying the costing of volume-based translation work to include the amount of tags. This requires, of course, that you have access to a counting tool which reports the number of tags (SDL Trados Studio does this - Atril's Déjà Vu has long offered this feature, and memoQ even allows you to assign a word or character "weight" for counting purposes). This is the only fair way I know of to account for the extra work (beside time-based charges). Consider that everyone is affected: translators, reviewers and project managers! I've had to talk more than one of the last group through "tag rescue" techniques after hours.

Perhaps it is worth considering as well that cleaner tagging will also improve "leverage" (match quality) in translation memories. So if a tool does offer cleaner tag structures (fora variety of source formats) consistently, working with that tool efficiently to manage projects will save time and money as well on top of the time and money saved with the use of CodeZapper macros in MS Word files.

OmegaT: Best practice for translating content from memoQ

OmegaT is popular in some circles because it is Java-based and thus cross-platform, and it is free. Although rather limited in many respects compared with full-featured commercial tools such as SDL Trados Studio or memoQ, this Open Source tool can handle quite a number of formats well, offers interoperability pathways with the leading commercial tools and there are a good number of excellent professional translators who are satisfied with its features. Thus outsourcers using memoQ should understand the best procedures to follow if working with translators using OmegaT in order to avoid difficulties.

In the past, I have recommended using the bilingual XLIFF exports from memoQ for compatibility with memoQ. In theory, it's a nice approach, but I am encountering difficulties with memoQ-generated XLIFF files (possibly a Kilgray problem or a problem specific to my installation, not one having to do with OmegaT, which handled XLIFF from other sources properly in my tests). So for now I would say that a workflow involving memoQ's bilingual RTF tables is the best approach. Do the following to prepare the content for the translator:

1. Create a bilingual RTF table export from memoQ of the content to be translated. Use the "mqInternal" option for tags in order to change their color and facilitate proofreading of the final result.
2. Copy the source content cells into an empty DOCX or ODT file. OmegaT cannot read RTF and requires one of these two formats to be used in this case. The translator will be able to read these directly and translate.
3. Other resources such as TMs and glossaries:

• OmegaT uses TMX for its translation memory. If you have a TM, provide it to the translator in this format.

• The OmegaT glossary format is:
  source term        target term        additional information
  Provide terminology to the translator in this format if possible.
  OmegaT is also capable of reading TBX, the industry-standard for glossary files.

The table cell content from the prepared file will look something like this in OmegaT:

Note that the memoQ tags are surrounded by additional OmegaT tags. Since OmegaT does not actually protect tags in its working environment, it is important that the translator verify the tags and proofread carefully, checking that all tags are present and applied correctly.

Once the translation is ready in the target DOCX or ODT file, open it in Microsoft Word, copy the translated table cells and paste into the target column of the bilingual RTF file, add any comments necessary to the Comments column of the table (if present). After the bilingual RTF is re-imported to memoQ, run a QA check to verify the tags again. After that the work can be proofread for content in memoQ or a bilingual export of an appropriate kind and the target file generated and delivered afterward.

SDLXLIFF files in TagEditor, OmegaT and memoQ

As SDL Trados Studio gains acceptance, SDL's own flavor of XLIFF is encountered with increasing frequency by translators using other tools. I decided to test three of these to see how they fared: TagEditor (for "backward compatibility" with Trados users who haven't upgraded), the Open Source tool OmegaT and memoQ.

A simple DOCX test file was created, which looked like this:

It was opened in SDL Trados Studio 2009 and saved as an SDLXLIFF file, which was subsequently imported into each of the other three translation environment tools.


TagEditor test
Using the default XLIFF INI supplied with SDL Trados 2007, I obtained results which looked as follows:

Some ugly tag salad there and exposed , vulnerable information from the header. Using the adapted INI file I made for memoQ XLF files, things improved a bit:

Still not very pretty, but it works, and it works better than an memoQ XLIFF currently does in TagEditor. No breaking of tags.

Translated and brought back into SDL Trados Studio, the translation grid looked like this with everything in good order:

The target DOCX file with the translation saved nicely and was perfect.

In real life, however, it may be necessary to adapt the INI file in TagEditor more extensively for good results. The German consultancy Loctimize has compiled some good instructions for doing so in which the entire workflow is also described nicely (in German). So far I haven't run across similar instructions in English.


OmegaT test
Initially things looked much better with the SDLXLIFF file imported to OmegaT:

A great start, much cleaner-looking than TagEditor! But when the translation was re-imported to SDl Trados Studio, a small problem was apparent:

One of the tags in the second segment was dropped. In a similar test with an XLIFF from memoQ, the version of OmegaT I tested (version 2.3.0, update 3) appeared to trash even more tags, and the target file was completely reformatted! In fact, it even trashed tags on the source side in the memoQ file! Thus I was deeply concerned about the XLIFF filter in OmegaT. However, as astute observers have noted, I probably deleted the missing tag when editing in OmegaT, and a subsequent successful re-test of the workflow confirmed this. But the problem with the XLF file from memoQ was frighteningly repeatable. Careful, systematic testing revealed, however, that the roundtrip of a bilingual XLF file from memoQ back into memoQ failed. Either there is a problem with the version I have installed (5.0.56) or the installation is corrupted. The matter is being pursued with Kilgray support. The target file from the SDLXLIFF translated with OmegaT was fine.


memoQ test
I have translated many SDLXLIFF files in memoQ and seldom encountered a problem of any kind. The file from SDL Trados Studio looks as follows in the memoQ environment:

Please note: with memoQ I can use an XLIFF which has not had the source copied to the target or one which has been pretranslated. That is not really the case for the other two environments tested, because with both TagEditor and OmegaT the source must be copied to the target or you have nothing to translate. You might say that memoQ offers "real" XLIFF editing for translation.

The SDLXLIFF file translated in memoQ reimported beautifully to SDL Trados Studio 2009 and saved to a target file (DOCX) from there with no problems.

Trados TagEditor: Optimal translation of memoQ bilinguals

With the growing number of translation agencies, direct clients and outsourcing translators adopting Kilgray's memoQ as a working platform for managing translation project content, it is particularly important for these new memoQ users and their partners to understand the best approaches to working together with persons who use other tools. One tool which is still commonly found is SDL Trados TagEditor. Compared to the other "classic" Trados tool, the Workbench macros for Microsoft Word, TagEditor has the advantage of enabling many different file formats to be processed while protecting their formatting elements (also known as "tags").

SDL Trados TagEditor can work with two types of "bilingual" files prepared in memoQ: XLIFF (*.xlf) files and bilingual RTF tables. Each approach will be presented here along with some suggestions for best practice.

XLIFF files
TagEditor comes with a default INI file for translating XLIFF, typically found at the path C:\ProgramData\SDL International\Filters\XLIFF.ini.This INI enables the contents of the target segments from the memoQ XLF file to be translated as the source in TagEditor. Thus for this approach to work, the source must be copied completely to the target in memoQ before the bilingual XLIFF is created using the Export bilingual function of the Translations page. This makes pretranslation undesirable in most cases, because the source text for matches will not be accessible and the translator will end up with a very screwy TM. Data for the TM should be supplied to the translator as TMX; be aware that match rates for the segments in TagEditor will differ significantly in some cases.

The memoQ XLIFF files will have a lot of "junk" at the top of the file when viewed in TagEditor:

Skip the content between the mqfilterinformation tags and do not change it in any way. Place the  cursor below that to start working. If you prefer not to see that information at all, use the XLIFF INI for TagEditor which I modified for use with memoQ XLF files. Then the XLIFF will look a bit cleaner with the header information filtered out:

Astute observers may have noticed, however, that all is not really well with the tag structures in the views above. I think there is  problem with the way that memoQ is generating the XLIFF files, with some tag structures being replaced by entities. (You see this if you open the XLIFF from memoQ in a text editor.) This causes consistent problems like the following in TagEditor:

This will require a lot of tag fixing. Thus I really can't recommend the XLIFF method at this point, not for my simple little test file in any case. The methods using the bilingual RTF tables with memoQ tag protection are safer and the structures that result are much simpler.

But if you do use this method, when the translation is complete, clean the TTX file using Trados Workbench or use the menu option File > Save Target As... in TagEditor to create an XLIFF file to return with the translated content. If the content inside the mqfilterinformation tags has not been segmented, an accurate count of the words translated will be shown in Trados Workbench upon cleaning the TTX (as accurate as that tool is given its limitations with numbers, dates, etc.)

Bilingual RTF tables
There are created in memoQ using the Two-column RTF option of the Export bilingual function. Technically speaking, the files have more than two columns (source and target, index numbers and possibly columns for a second target text, comments and status). Good practice for working with these files in TagEditor and many other tools also requires the source to be copied to the target column. This can be done in memoQ or later in a word processor. The table might look like this, for example:

For best results in TagEditor, it is important that this file be generated with the "mqInternal" style selected for tag formatting. The dark red color imparted to the tags with this option means that proofreading in a word processor is easier, and it also enables the text of the tags to be selected and hidden using a search and replace function. If the RTF file is then saved as a Microsoft Word file, the memoQ tags in the table will then be protected in TagEditor!

If the "full text" option for tags is selected, this makes little or no difference in the TagEditor view.

Here's a quick look at what the protected memoQ tags look like in TagEditor and what can happen without protection:

One possible workflow for memoQ RTF tables in SDL Trados TagEditor consists of the following steps:

1. Copy the source text to the target in memoQ
2. Export a bilingual "two-column" RTF file with the mqInternal style option selected for the tags
3. Re-save the RTF as a DOC or DOCX file! This is necessary so that TagEditor will use the right filter.
4. Select and hide all the text in the file
5. Select only the text to translate in the target column and unhide it
6. Using search and replace, hide all the dark red text. The settings for the dialog are show below and are set using the Font... option (marked with a red arrow in the screenshot) in the Format dropdown menu of the Replace dialog.
   
   
   
   
   The font color to hide will be found under More Colors... in the font colors of the font properties dialog:



7. Launch TagEditor and open the Microsoft Word file with your content to translate. All the hidden text will be protected in tags. Translate the accessible text.
8. Create a target MS Word file from your TTX as described above for the XLIFF files translated in TagEditor.
9. Open the target file and unhide all the text.
10. (Optional) When reviewing the text in the word processor, comments may be added if there is a comments column. These will be imported back into memoQ and can serve as valuable feedback.
11. Re-save the target file as an RTF
12. Re-import the RTF with the translated table into memoQ. The target text will be updated to include the translation. 
13. A QA check for tags, terminology, etc. should be performed in memoQ before exporting the final file for delivery. If an external reviewerr is used, another bilingual file in an appropriate format can be generated in memoQ for that work.

Steps 4 to 6 can be performed using a macro for convenience.

The procedure described above can, of course, be abbreviated considerably by simply copying the source text cells into a new Microsoft Word document, doing the search and replace to hide the dark red text for the tags, then processing the file in TagEditor. After translating, unhide the text in your working file, then paste the cells over the target cells in the RTF file.

Here's a look at the test file translated in TagEditor (with a comment added as shown by the dark speech balloon icon) after it was re-imported to memoQ:

And here's the translated file itself:

Converting MARTIF to Excel

This afternoon I received an interesting project of a sort I don't see often - Star Transit. I avoided these like the plague for years, because I dislike Transit as a working environment, though I expect the latest version is probably an improvement over what I used to use. However, since Kilgray created an excellent import routine for Transit packages (PXF files), working on these projects is quite a simple matter. Except for terminology. The memoQ integration currently does not include the Transit terminology.

The client was kind enough to supply MARTIF exports from the Transit dictionaries, but unfortunately that's not an import format for memoQ, though really it should not be that difficult to deal with that XML format (I hope). So I went on the search for a solution and soon discovered a PrAdZ thread in which Czech translator Antonín Otáhal offered a VBA macro for converting the MTF files (MARTIF) to Excel.

The solution works nicely, though in my tests I found it necessary to open the MTF files in Notepad and re-save them as ANSI so the special characters in German would not get trashed. And I hate typing a full file path into the selection dialog, so I modified the code to include a proper file selection dialog. If anyone else can use such a tool, I've made it available here as an XSLM file (a macro-enabled Excel worksheet for MS Office 2010). Improvements are very welcome; I've been out of the programming game too long now to refine this much without investing more time than it is worth to me.

Nonetheless, I'm quite pleased that I can now save a tab-delimited or CSV text file from Excel and import this easily into memoQ or other translation environments. So moving term data from Star Transit to other tools is now a little easier.

To use the tool

1. Make a copy of the Excel file
2. Open your working copy of the Excel file
3. Press Alt+F8 to bring up the list of macros
4. Select the macro "mtf2excel"
   
   
   
   
5. Click the Run button. A file selection dialog will appear, and if everything is OK with the encoding, your term data should appear shortly in the columns of the Excel sheet.

Presegmented "classic" Trados files

Given that many outsourcing translators, agencies and companies still use older versions of Trados but often want to work with qualified translators without tripping over tool issues, this is still a current topic despite the new SDL Trados tools having been on the market for several years. And my old published procedures on these matters are either no longer publicly available or are somewhat in need of updating.

Before I began blogging in 2008, I wrote a number of procedures to help my partner, colleagues and clients understand the best procedures for handling "Trados jobs" with other translation environment tools. When translating a TTX file with Déjà Vu, memoQ and many other applications, it is often best practice to "presegment" the file using a demo or licensed version of Trados 2007 or earlier. In fact, if this is done on the client's system, many little quirks of incompatibility that can be experienced if the translator used a different build of Trados (for example) can be avoided.

What does "presegment" actually mean? It is a particular method of pretranslation in which for segments where the translation memory offers no match, the source text is copied to the target segment. If performed with an empty TM, the target segments are initially identical to the source segments. If this procedure is followed, full, reliable compatibility is achieved between applications such as Déjà Vu and memoQ for clients using Trados versions predating Trados Studio 2009. For newer versions of Trados, the best procedure involves working with the SDLXLIFF files from Studio. If a freelance translator does not own a copy of SDL Trados 2007 or an earlier version used by an agency or direct client, this is the procedure to share with a request for presegmentation. While some clients might expect the translator to do such work using his or her own copy of Trados, I have experienced enough trouble with complex files over the years when different builds of the same version of Trados are used that I consider this to be the safest procedure to follow - safer even than having the translator do the work in Trados in many cases.

Step 1: Prepare the source files
Before creating a TTX file and presegmenting it for translation in DVX or creating a presegmented RTF, DOC or DOCX file compatible with the Trados Workbench or Wordfast Classic macros in Microsoft Word, it is a very good idea to take a look at the file and clean up any "garbage" such as optional hyphens, unwanted carriage returns or breaks, inappropriate tabbing in the middle of sentences, etc. Also, if the file has been produced by incompetent OCR processes, there may be a host of subtle font changes or spacing between letters, etc. that will create a horrible mess of tags when you try to work with most translation environment tools. Dave Turner's CodeZapper macros are a big help in such cases, and other techniques may include copying and pasting to and from WordPad or even converting to naked text in Notepad and reapplying any desired formatting. This will ensure that your work will not be burdened by superfluous tags and that the uncleaned file after the translation will have good quality segmentation.

Step 2: Segment the source files
If the source files are of types which Trados handles only via the TagEditor interface, then they may be pretranslated directly by Trados Workbench to produce presegmented TTX files. If they are RTF or Microsoft Word files, on the other hand, and a TTX file is desired, you must first launch TagEditor, open the files in that environment and then save them to create the TTX files, which are then subsequently pre-translated using Trados Workbench. If a presegmented RTF or Microsoft Word file is desired (for subsequent review using the word processor, for example), then the files can be processed directly with Trados Workbench.

Important Trados settings:

• In Trados Workbench, select the menu option Options > Translation Memory Options… and make sure that the checkbox option Copy source on no match is marked. 

• In the dialog for the menu option Tools > Translate, mark the options to Segment unknown sentences and Update document.

After the settings for Trados Workbench are configured correctly, select the files you wish to translate in the dialog for the Workbench menu option Tools > Translate and pretranslate them by clicking the Translate button. This will create the "presegmented" files for import into DVX, memoQ, etc. If the job involves a lot of terminology in a MultiTerm database, which cannot be made available for the translation in the other environment (perhaps due to password protection or no suitable MultiTerm installation on the other computer), you might want to consider selecting the Workbench option to insert the terms.

Note: to get a full source-to target copy, use an empty Trados Workbench TM. However, if an original customer TM is used for this step you will often get better "leverage" (higher match rates) than if you work only with a TMX export of the TM to the other environment. If I am supplied with a TWB TM, I usually presegment with it first, then export it to TMX and bring it into memoQ or DVX for concordancing purposes. However, in some cases, such as with the use of memoQ's "TM-driven segmentation", you might get better matches in the other environment (not Trados).

The one performing the presegmentation might want to inspect the segmented files in TagEditor or MS Word to ensure that the segmentation does not require adjustment. Segments can typically be joined in other environments such as memoQ in order to have sensible TM entries in that environment or deal with structural issues in the language, but this will not avoid useless segments in the content for Trados. The best way to deal with that is by fixing segments there. Otherwise, I often provide a TMX export from memoQ to improve the quality of the Trados TM.

Step 3: Import the segmented source files into the other environment
The procedure for this varies depending on your translation environment tool. Usually the file type will be recognized and the appropriate filter offered. In some cases, the correct filter type must be specified (such as in memoQ, where a presegmented bilingual RTF/DOC must be imported using the "Add document as..." function and specifying "Bilingual DOC/RTF filter" instead of the default "Microsoft Word filter".

Some tools, like memoQ, offer the possibility of importing content which Trados ignores, such as numbers and dates, This is extremely useful when number and date formats differ between the languages involved. It saves tedious post-editing in Word or TagEditor and also enables a correct word count to be made.

A few words about output from the other (non-Trados) environment
If you import a TTX to Déjà Vu, memoQ, etc., what you will get when you export the result is a translated TTX file, which must then be cleaned using Trados under the usual conditions. Exporting a presegmented RTF or Microsoft Word file from DVX gives you the translated, presegmented file. The ordinary export from memoQ will clean that file and give you a deliverable target file. To get the bilingual format for review, etc. you will have to use the option to export a bilingual file.

Other environments such as memoQ or Déjà Vu may also offer useful features like the export of bilingual, commented tables for feedback. This saves time in communicating issues such as source file problems, terminology questions, etc. and is infinitely superior to the awful Excel feedback sheets that some translation agencies try to impose on their partners.

Editing translations performed with Trados
A translation performed using the Trados Workbench macros in Microsoft Word or using TagEditor can be easily reviewed in many other environments such as Déjà Vu or memoQ. In fact, I find that the QA tools and general working environment with this approach is far superior to working in TagEditor or Word, for example. Tag checks can be performed easily, compliance with standard terminology can be verified, content can be filtered for more efficient updates and more.

Editing translations performed with more recent versions of Trados (SDL Trados Studio 2009 and 2011) is also straightforward, as these SDLXLIFF files are XLIFF files which can be reviewed in any XLIFF-compatible tool.

Damn the stinking "captcha" technology

This afternoon I tried to post the following note on my Facebook page:

Recently, I blogged about my new Kindle (http://goo.gl/JJF0q) and some of the personal and professional possibilities I saw for it. Since then, various friends and colleagues have raised the "compatibility" and monopoly issues for published eBook formats. I have found that Calibre (http://calibre-ebook.com/) is an excellent way to overcome this by easily converting between all formats and managing your electronic library. It also does great news compilations.

After a few dozen failures at reading and retyping things like

 

I had to conclude that the idiots programming for Facebook must never have considered the possibility of two links in one comment. In any case, I resent being asked to do security checks on my own page. Even the "audio captcha" attempts were failures.

This form of verification technology is extremely intrusive and makes me less concerned with security, not more. Really, there must be a better way.

Oh, yes... Calibre is an excellent tool for eBook management and seems to overcome many of the barriers which concern some colleagues and friends. And there's nothing Amazon can do about it.

Back to 2003!

Like many people, I am deeply unhappy with the changes that Microsoft made to its Office Suite in the 2007 and 2010 versions. Since I upgraded from Office 2003 about a year ago, I have been unable to find many functions I used for decades. I find the "ribbon" paradigm used in the current interface appalling. Icons have been carried much too far in interfaces. We need words to figure out where things are in most cases. Or I do at least.

This topic has been raised several times on the private translators' forum Stridonium in which I participate, but until recently I managed to overlook the solution suggested there. One colleague suggested the commercial solution from Addintools. When I mention this at last night's translators' social evening in Hohen Neuendorf near Berlin, one person there thought I was referring to a macro solution from Switzerland, which I was not. This morning he sent me a link to UBit's pages with their interesting solution:

The macro from UBit adds a "Menu" menu to the MS Office 2007 or 2010 menu bar (how's that for redundancy in wording?). When selected, it displays a strip of dropdown menus corresponding to the structure of the MS Word 2003 menus. The product was developed to make the transition to the awful new interface less painful. So far it looks promising. There's a little info video, which is short on information but has a nice music track:

Dezember-Übersetzertreffen in Hohen Neuendorf

Liebe Kolleginnen und Kollegen,

unser letztes Übersetzertreffen in diesem Jahr steht an, und zwar am:

                Donnerstag, 15. Dezember 2011, ab 19.00 Uhr

Wir probieren mal wieder etwas Neues aus (Dank an Heidruns Wolfgang für den Tipp!):

                Gasthaus-Pension Strammer-Max

                Schönfließer Str. 16 a

                16540 Hohen Neuendorf

                S-Bahn S1 und S8 Hohen Neuendorf

Das Gasthaus befindet sich direkt gegenüber vom S-Bahn-Ausgang auf der anderen Straßenseite und ist nicht zu verfehlen.

Hier ein kurzer Blick aufs Angebot:

http://pension-strammer-max.com/auszug-aus-der-speisekarte/

 

Bis Donnerstag!

Andreas Linke

Vorschau:

Das übernächste Übersetzertreffen findet wie üblich am dritten

Donnerstag des Monats statt - am 19. Januar 2012.

Heads in the Cloud? Or somewhere else?

As noted in my last post, concerns are growing over the trend toward "Cloud-based" translation management solutions and the potential negative impact on interoperability between TEnT systems with the wrong approach. As Jost Zetsche noted, there is a need to push solution providers such as SDL, Kilgray, Atril, Wordfast et alia to develop working, open interfaces so various clients can be used with a given server solution in online projects.

From a somewhat different perspective, Hungarian translator Csaba Bán noted that bits and dribbles of text translated via project management tools in the Cloud, while perhaps offering some efficiencies for an LSP or other company, too often unnecessarily fragment and waste the translator's time for inadequate compensation under most current schemes. I've heard a number of my clients talk about developing web-based "instant interfaces" for quickie translation service, and I know of a number of companies who have had something like this for years, but it all seems a bit like a sleazy back alley encounter on the fringes of a Red Light district with too great a chance of the translator's business suffering ill health from such indulgence. Cloud solutions which do not cleanly integrate with a translator's working environment tools but which require copying and pasting in various fields and windows are simply inefficient (despite some tools offering Clipboard integrations) and not very attractive. And appropriate minimum charges and premiums to offset the disruptions caused by too many dribbles during the day are called for. This requires some thought, and I can't pretend to offer any brilliant solutions to the dilemma, as I think each situation will have to be considered individually until a good set of general principles for best practice emerge. I have one such case I'm puzzling over myself right now: how to charge for "tweet translation" for a long-term client who runs a PR agency. So far I haven't, because the volume has been modest and fits well enough into the ordinary flow of our business discussions, but the case has me thinking.

As readers of this blog probably know, I am also involved in other types of Cloud-based project management for translation. When I began to encounter the first web-based administration interfaces with my agency clientele a decade ago, I hated them. In fact, I have dumped several otherwise rather good clients, some paying rates on par with decent direct clients, because I found their systems too cumbersome and prone to fault. One of the worst was a custom mess from an international LSP whose Swiss branch was a frequent customer; half the time, secure deliveries via their portal were simply impossible and I had to resort to insecure e-mail attachments. (Yes, these can be passworded, but that involves additional trouble.)

Gradually, decent standard solutions emerged. A number of my clients are happy with the German Plunet solution; I favor LSP.net's OTM, not because I localize the English interface but because it's comprehensive, legally secure, provides robust processes and archiving, is software as a service (SaaS) at modest cost, and I don't have to screw around with the infrastructure at my dilapidated country estate with its lousy bandwidth availability; and there are other acceptable alternatives beside the rather nightmarish mess of the Open Source solution I once tortured myself with for several months (Project ]open[ Translation). A good online administrative solution like this has many advantages over desktop or LAN solutions, and I have discussed many of these benefits in previous posts about OTM. Even the best solutions I have seen, however, have one glaring weakness: login management!!!

This is a big problem with many online applications. We all have too many damned passwords to juggle. When suddenly I have another dozen or two dozen logins to translation project administration systems for my agency and big corporate clients, things begin to get dicey if cookies, utilities like KePass or other methods are not applied. Personally, I would like to see options for OpenID and other integrations as one is beginning to see with some of the social media. Despite the hassles sometimes involved here, I think Cloud-based tools of this kind are among the most useful for managing translation-related processes and making them secure. I use my OTM for encrypted deliveries of confidential files and for providing clients with full access to their project backup archives. This is a blessing if I'm off somewhere taking a break and someone desperately needs a copy of a translation I did last year which has gone missing.

Don't surrender freedom again - demand interoperability

Once upon a time, in my youth, communication, including translation, used media that were more or less common standards. Any pen or pencil could write on most any paper or vellum, and while one might have preferences in a brand of typewriter, the choice mattered little to the end result. Transmission by postal mail, courier, teletype or (later) fax also used mostly compatible protocols, and fewer things got lost in the pile of junk mail, as the kinder, gentler form of "spam" was called in those days.

Then the rise of IT and media technologies in the commercial and consumer world shattered this pax, and a myriad of information fiefdoms rose and fell, with users as the foot soldiers and cannon fodder in their conflicts. Eventually, on the main stages of IT, the vendors were forced to realize that their futures depended not on information fortresses but in open exchange and interoperability. 

In IT backwaters such as the translation "industry", old practices persisted like medieval kingdoms and customs around the Himalayas, but eventually modern data sanitation reached even this provincial niche, which had adopted some computer tools while ignoring most best practices to maintain proprietary strangleholds. But eventually, the march of progress reached even those altitudes, and TMX, TBX and XLIFF became common parlance. And all is well or shall soon be. Really?

In the 203rd edition of his Tool Box Newsletter (premium version), Jost Zetzsche discusses a recent article in Forbes magazine (Cloud Computing's Vendor Lock-In Problem: Why the Industry Is Taking a Step Backward) and its implications for IT service consumers, including those involved in the translation business. The original article and Jost's commentary are very much worth reading (which is why I subscribe to the full content of his newsletters). His insights included the following comment:

"While we have data exchange standards that are more or less well supported (TMX for translation memories, TBX for termbases, XLIFF for the translation data, and the upcoming Linport for translation packages), there are no mechanisms that enable tool A to enter into the server- or cloud-based workflow of tool B. So, if your client sends your project not as data but as a login that you can use within a tool to access an online-based project or -- even more simply -- to actually log into an online-based tool that automatically gives you access to online-based data, all the hard-fought-for advances in widely accepted data exchange standards are nullified."

This is one of the problems which has concerned me, along with the loss of platform freedom for translators currently wanting to work on server-based projects. Although I know some translation companies, such as Translators International in the Netherlands, who use their server-based memoQ and other technology to make translatable content available to their language pair teams in a variety of best practice, compatible formats, in too many cases, server-based projects lead to a kind of lock-in which ultimately is in no one's best interest. Across Systems, with its wicked policy of deliberate incompatibility, represents the worst case I know, because it is not even possible to work with data exports of some kind as one can with respectable systems such as some SDL technologies, memoQ, Ontram and others. 

Various influencers within SDL, Kilgray, Atril, MultiCorpora, Andrä AG and elsewhere are probably quite tired of hearing me pluck the strings of my dream harp loudly and repeatedly in their presence: I want to see online server communication standards which enable a client user of Trados Studio or Wordfast Pro to connect to a memoQ Server project, or someone with a memoQ Translator Pro installation to connect to an Ontram or SDL server project and work most effectively using the ergonomic tools with which the translator or editor is most familiar. I don't buy the arguments of "difficulty" at face value; just look at all the integration plug-ins that are being released by various vendors, with remote TM or termbase access, and it's fairly obvious that at least some degree of online interoperability should be achievable without much pain.

Jost's commentary concludes with a quote from the Forbes article: 

"Only one thing will eliminate or reduce the risk of vendor lock-in in the long run: if end-user customers start demanding standardization and interoperability, just as they have in the past with on-premises applications... providers will fall in line."

All of us - individual translators, translation companies and corporate customers who manage their own translation services with server-based technologies - need to demand that all the credible providers of translation environment technologies "fall in line".