Yes. memoQ uses the spell checker of Microsoft Office for this in the background. If you are using a language version of Microsoft Office 2000 that does not provide built-in support for the language you are translating into, you can simply copy the required files and Office will support that language as well. However, this is not enough when you try to use memoQ spell checking. Because Microsoft Office does not automatically install some elements, you need the original installation CD to proceed.
This is not an issue with Microsoft Office 2003 or newer.
Some users have experienced the following issue. When they confirm a translated segment, some of the Central/Eastern European diacritical characters get corrupt. For example in Czech "ř" changes to "ø", "č" changes to "è". This happens on computers that ever had an early version of Trados installed (any version before 6.5). Uninstalling or updating Trados does not solve the problem. Trados used to have a problem with displaying special characters of Central/Eastern European languages. For a long time, Trados did not issue a fix for this problem, but advised their users to work around it by changing a setting in the registry. This made the problem go away in Trados, but it is still causing problems in other applications like memoQ. The solution is to change this registry setting back to the original value.
No, that is not possible. The way {tags} work in memoQ is, they stand for something that constitutes the structure of the original document (the "skeleton"). Without that skeleton, there is simply no way memoQ can restore a correct document at export. Not copying tags and allowing export would simply result in a file with DOC extension (for Word DOC's) that can do one thing: crash Word when you open them...
However, Word documents will sometimes show tags that clearly do not stand for anything sensible (especially if the DOC was created from a PDF file). Such tags are also called rogue codes. For some ideas on how to get rid of them, see Getting rid of codes in Word documents in the Tips and Tricks chapter.
Among other things, the auto-translatables function in memoQ can be used to convert numbers from one language format to another. For example, English uses the comma as a thousands separator, and the full stop as a decimal separator. Italian uses them the opposite way. With the proper auto-translatable rules set, memoQ will provide the "localized" version of numbers found in the source segment. These localized numbers are shown in the Translation results list. These auto-translated hits can be inserted quickly into the translation just like hits from translation memories or term bases. Auto-translatables are also used by the fragment assembly function.
Auto-translatables can be set at the project level (in the settings page of the project) or the global level for every project with the same source and target languages (in Tools menu > Options > Auto-translatables).
English to Danish/Dutch/Croatian/German/Romanian/Slovenian/Spanish
Below are the rules to enter for a project translated from English to the above (and possibly other) languages. It will localize numbers containing decimal separators or thousands separators (not both). The rules need to be entered exactly as below in the exact same order to ensure that they work correctly. For information on entering auto-translatable rules, see the memoQ help topics under Language specific settings > Auto-translations.
Rule 1 (changes 1.234 to 1,234)
Auto-translatable rule:
(\d+)\.(\d+)
Replace order rule:
$1,$2
Explanation: If a sequence of digits is followed by a full stop and another sequence of digits, this rule will replace the full stop with a comma.
Rule 2 (changes 12,345,678 to 12.345.678)
Auto-translatable rule:
([\d]{1,3}),?(\d\d\d),?(\d\d\d)
Replace order rule:
$1.$2.$3
Explanation: If a sequence consisting of 1 to 3 digits is followed by a comma, which is followed by three digits, another comma and thrre digits again, the rule will replace the commas with full stops.
Rule 3 (changes 12,345 to 12.345)
Auto-translatable rule:
([\d]{2,3}),?(\d\d\d)
Replace order rule:
$1.$2
Explanation: If a sequence consisting of 2 to 3 digits is followed by a comma, which is followed by three digits, the rule will replace the comma with a full stop.
If you want to copy large blocks of text from the source to the target during the translation process, memoQ may currently hang or crash if the Quality Assurance module is running in the background.
Go to the Project QA Settings in the main settings area and make certain that none of the boxes above the tabs are checked. Wait until you really get to the point where you really want to start doing quality assurance checking before you actually start to run the QA features.
For some languages, you may want to disable the case conversions in the "Translation Results" pane.
For certain Word documents, memoQ will show superfluous tags that apparently serve no purpose. Once you import your document, there's no way to delete these tags; the best you can do is to insert them by pressing F8 or put them at the end of the target segment by hitting Alt+F8.
There are several possible ways to reduce such tags prior to importing:
These and other methods are discussed here: http://www.necco.ca/dv/word.htm#Rogue_codes
Some of these pre-import tips and others have been automated in a set of macros that I've assembled in a Word template with a custom toolbar (CodeZapper_2.3). This template also includes a few other pre- and post-processing macros that may be useful. It was principally intended for use with Deja Vu but memoQ users may also find it useful in some circumstances. You can find it in the files section (http://tech.groups.yahoo.com/group/memoQ/files/). Dave Turner
More ideas on removing rogue codes from Jim Wardell:
If Word files cause rogue codes in memoQ, pre-edit them looking for the problems suggested above by Dave. Also:
Make sure autohypenation is deactivated in the entire Word file.
Use Find and Replace to remove all optional hyphens.
Make sure the Word setting "Hyphenate words in CAPS" is off.
Sometimes rogue codes are caused when the font size in the source PDF text hovers between two integer sizes. The OCR output (which even allows half-point sizes) then can contain embedded font size changes (e.g. 11 pt. --> 11.5 pt. --> 11 pt --> 10.5 pt.). If you get a lot of these, and the Word file itself contains several font sizes that you want to retain, you may need to go through and select the continuous font-size passages and apply the font size you want to use (in the above case, for example, perhaps Arial 11 pt.). A slicker, more professional way to do this would be to apply a style definition to such passages. Your style definition would also include No Autohypenation and normal character spacing.
If your source document does not contain bold or italics, select the entire file and change all to Bold + Italics. Then select the entire file again and remove the bold and italics.
If you are scanning PDF files using OCR software (and therefore are the one who created the rogue codes in the first place!), take a close look at the detailed settings options that were in effect when you exported from OCR to Word. Only use those settings that you need, the others may be generating rogue codes.
The Arial Unicode font is installed by OmniPage. OmniPage inserts tags around umlauts in Word files. I've solved this problem by removing the Arial Unicode font from my system. It's also a good idea when using OCR software to use font matching to restrict the fonts that are allowed in OCR output, e.g. to Times New Roman and Arial.
If your client offers to convert PDF files to Word for you, consider that he/she may be using a cheap PDF converter program to do this and might not have the slightest clue what he/she is doing. In this case, you're better off getting the PDF file yourself and using high-quality OCR software to do the conversion yourself. Be aware that PDF converters, even the best ones, are likely to cause more problems with rogue codes and formatting than professional quality OCR software. You get what you pay for. There also are major differences between the two leading professional-grade OCR programs in their ability to reduce rogue codes and produce TM-friendly formatting. Test both carefully and see which gives the more TM-friendly results in your situation.
The suggestions offered by Dave and myself should help you eliminate nearly all rogue codes, however if you are still getting too many, open MQ and notice where a given rogue code occurs, then open the offending file in Word at the same time. Try selecting the characters around the offending location and check for any changes in settings. If you learn something useful, please register as a Wikibooks author and add them to this page.
Although this is not a documented feature, memoQ can enter non-breaking spaces useful e.g. in the case of French quotation marks. To enter a non-breaking space press ctrl+shift+space instead of space.
Sometimes, when your client sends you a TM using a specific source language (ex. EN-CA), you may import your TTX files into a project using another regional language (ex. EN-GB) only to discover later that, when you export the resulting TTX, the source language has changed! This may lead to problems, as TagEditor refuses to edit a TTX using language settings different than the TM is is currently associated with.
In fact, memoQ sets the source and target language of your TTX files to those chosen for the current project. You may sometimes want to turn that to your advantage and deliberately chose whatever source and target language you see fit.
To do that, proceed as follows:
And here you are, you now have fully working bilingual TTX files you can open using TagEditor with the source/target language you chose!