Showing posts with label memoQ. Show all posts
Showing posts with label memoQ. Show all posts

Tuesday, July 27, 2021

An AutoHotkey solution to a memoQ problem

The memoQ problem…

Some installations of memoQ suffer an annoying problem: cut and paste doesn’t work. The rest of the program works, as does copy and paste, but not the "paste" part of cut and paste: memoQ deletes your text at Ctrl+X all right, but it does not save it to the clipboard, so you have nothing to paste when you hit Ctrl+V.

If you try to perform the operation via the context menu, no luck, either: after Ctrl+X, paste (Ctrl+V) is greyed out.

Cut and Paste not working in memoQ

The problem appears unpredictably: you could have (as I do) two similar computers, with a similar panoply of software installed. On one cut and paste works as expected in memoQ, while in the other it doesn't.

memoQ’s support staff are aware of this problem, but (since they have never been able to reproduce it) their developers are unable to fix it. memoQ's support offer several suggestions that sometime work, from disabling other programs that might interfere with the clipboard, to deleting certain temporary files, and finally to that old favorite of all support organizations: reinstalling the program… but even reinstallation, for certain users, fails to correct the problem.

Fortunately, there is a simple workaround: instead of hitting Ctrl+X to cut and Ctrl+V to paste, you can add a step—copy (Ctrl+C), delete (Del), and finally paste (Ctrl+V)—but if you are accustomed to just using Ctrl+X/Ctrl+V in all other programs, you are likely to forget that you have to use different steps in memoQ.

...and the AutoHotkey solution

So we need a more permanent solution, and one is at hand (this also is thanks to a suggestion from memoQ support): using an AutoHotkey1 script to replace the “cut” part of cut and paste.

Here is the script (complete with comments to explain what each step does):

#NoEnv  		; Recommended for performance and compatibility with future 
                        ; AutoHotkey releases.
SendMode Input  	; Recommended for new scripts due to its superior speed 
                        ; and reliability.
SetWorkingDir %A_ScriptDir%  ; Ensures a consistent starting directory.
^x:: 			; Assigns to the Ctrl+X shortcut the following actions:
#IfWinActive memoQ 	; ensures script works with memoQ only, not with other programs
Send ^c 		; Copy (as if "Ctrl+C" had been pressed)
Send {del} 		; Delete (as if the "Delete" key had been pressed)
#IfWinActive 		; end of the "works in memoQ only" part of the script
Return 			; end of the script

You can use this script "as is" if you already have AutoHotkey installed: just copy the above code to an empty text file and save it with an .ahk extension; then, whenever you need to work in memoQ, double click on the script file to launch it.

If you use other AutoHotkey scripts, you also can add the above code snippet to one of your other scripts (so long as none of them tries uses Ctrl+X as a hotkey). And you can even compile the script to an independent .exe file, to use on computers where AutoHotkey is not installed.

 


1 AutoHotkey is a free, open-source scripting language for Windows that allows users to easily create small to complex scripts.

Wednesday, June 30, 2021

memoQ Regex Assistant

Version 9.8 of memoQ includes the Regex Assistant, a new tool that helps creating, validating and using regular expressions. I haven’t used the new feature extensively, yet, but look forward to exploring it more next time I use memoQ for a translation project.
memoQ 9.8 - Regex Assistant



Monday, October 23, 2017

Bad programming decisions in CAT tools

Everyone knows what software bugs are: flaws in a program that make the software fail or behave in unwanted and unexpected ways. Bugs are unavoidable in something as complex as software. The most we can reasonably ask of programmers is that they try to lessen the frequency and severity of bugs by using sound programming practices, and that they correct bugs quickly, once found.

Bugs are unintentional, whereas virus, Trojans and other malware are created with malicious purpose.

But, between unintentional bugs and willful malware, there is an entire class of problems caused by intentional programming decisions: when software features work as designed, but the design itself is ill-thought-out.

I'll give two examples from SDL Trados Studio and memoQ.

In Studio, an example of flawed design is the deliberate disabling of "smart quotes" when change tracking is active. According to SDL, "This currently is by design so that no uncontrolled/automatic changes should happen when typing in review mode." However, they didn't think through the real-world consequences of their decision: now, a translator may use smart quotes during translation, but since they are disabled during review, any apostrophe or quote entered during review will be straight. After review, the text of the translation will contain a mess of straight and curly quotes and apostrophes.

SDL Studio: The translator used smart quotes, but the apostrophe used during review is a straight single quote.

Furthermore, apostrophes and quotes are tiny characters: it is entirely possible no one will notice the problem for a while. The first person to notice might very well be the customer... perhaps when he receives the final printed copy, after it is too late to correct the error.

Disabling smart quotes when change tracking is active is harmful, and the problem is made worse because it is not well documented.

For me, I have a good workaround: a short program I wrote in AutoHotkey that allows me to use two different types of smart quotes (and also straight quotes) with no tweaking of Studio's settings, no matter whether change tracking is active.

Maybe, under certain circumstances, it would be better to disable smart quotes during review, but this is a decision that should be left to the translator, not imposed by SDL.

Let's now pass to Studio's main competitor, memoQ.

Here, the flawed feature is a change introduced with version 8 of memoQ: a new behavior, touted as an ergonomic improvement, of the Shift+F3 "change case" function.

Before version 8, Shift+F3 behaved in memoQ much the same as in Word, Studio, or many other programs--it toggled through the various permutations of change case: all lowercase, ALL UPPERCASE, and Mixed Case. Now Shift+F3 opens a drop-down menu, where the user can select the case.

memoQ: An unecessary drop.down menu for a simple function.

The result is the same, but the new "feature" hinders smooth typing by shoehorning in the workflow a change no user had sought. The new behavior slows a translator used to hit Shift+F3 a couple of times, until the desired case is achieved, then press the right arrow and continue typing. Changing case now often requires at least an extra keystroke; worse, it introduces an unnecessary change in a behavior that most users had imprinted in their muscle memory. And since Shft+F3 continues working as before in other programs, the irritation caused by the change will not fade away as you form new habits.

Unlike with the Studio example, there is no workaround: the only thing you can do is return to memoQ 2015, abandoning any useful feature added in version 8.

I imagine that if Kilgray introduced this new feature, someone must have either asked for it or thought it was a brillant idea. Instead, just like SDL's disabling smart quotes in change tracking mode, it is a bad programming decision.

Special free software offer


As I mentioned before I use a short AutoHotkey program to enter smart quotes and apostrophes in Studio. The program lets me enter "smart" single and double quotes, curly apostrophes, "French"double quotes, and also, when I need them, "straight" double and single quotes.

This works for me and would work for other Italian translators as well. If you need a copy of this utility, let me know, and I'll be happy to send it to you "as is".

I can customize (for a small fee) this utility to use different sets of single and double quotes. If you are interested, please write me (you can use the contact form in this blog).

Thursday, October 05, 2017

Belt and Suspenders

Some of us may have a tendency to panic, when faced with some unexpected computer error (and such incidents generally occur when little help is available, or very close to deadlines, or both), but there are steps we can take to defend ourselves from the worst effects of such mishaps.

On Sunday, my partner's computer froze: suddenly neither keyboard nor mouse responded. We tried disconnecting and reconnecting keyboard and mouse, but without result. The last thing left to try was a hard reboot. We did that, and, after restarting in safe mode and then again in normal mode, the computer seemed to be working right: all programs responded as expected.

Until, that is, my partner tried to launch Studio 2017 to continue a project she was working on. At that point the Studio splash screen briefly appeared, only to be followed by an ominous error message: "Not found".


We clicked on the Knowledge Base Community link, but to little avail: no useful help there for this particular error message, so we opened a ticket with SDL's support. Of course, since it was Sunday, the earliest we could expect to hear from support was the following day... and my partner's deadline was rapidly approaching, so we needed to find another way to continue work on her project.

We had two options: either copy the project's files and memories to her backup computer (a laptop), where we still had a copy of an earlier version of Studio, or work on the project with a different translation tool.

We chose the latter option. Getting the sdxliff file to continue work was a simple question of copying it from the SDL 2017 "Projects" folder to a different working folder, but since we couldn't launch Studio, we had to use a different tool to export the most up to date copy of the translation memory: we used Xbench to load the TM and then export it in TMX format. It was then a simple matter of creating a new project in memoQ, add to it the partially translated sdxliff file, create a new memory, and import into it the TMX file we had created in Xbench.

My partner was then able to continue her translation.

The next day, Monday, we received instructions from SDL support. We were told first to try re-installing the program; when that didn't solve the problem, we tried renaming the "projects" XML file, and then various other SDL files and folders. Nothing seemed to work, and the SDL support technician was stumped. She said she'd need to escalate the issue to a more experienced engineer, but since the second-level engineers work out of the UK office, that would have to wait until the following day.

On Tuesday, we were again on a support call, this time with the second-level engineers. They suggested various other remedies, finally succeeding in restoring Studio 2017 to life -- the culprit turned out to be an obscure Windows file (BTW: kudos to SDL's tech support -- it's well worth the money we pay for it, and they are generally patient, thorough, and professional).

In the meantime, my partner had been able to complete the translation of the project in memoQ, and she then proceeded to finalize it in the newly-repaired Studio. So, a happy ending to our short tale of technical issues.

But it got me thinking that such happy endings don't just happen: they require preparation and planning:

  • If we had relied on a single computer, and a single CAT tool, my partner would have been unable to continue working until SDL support had solved the problem;
  • If we had not installed Xbench, we would have been unable to export the data from Studio's memory;
  • If we had not paid for SDL support, our only recourse would probably have been to take the computer to a repair shop, or perhaps ask for advice in the various online forums available, and hope for the best;
  • In this case, there was no damage to the files or to the computer's hard drive, but if such damage had occurred, we would have been prepared also: we regularly back up our files both to external hard drives linked to our home network, and to online storage.

Technical problems happen, but if you plan for them, you can minimize the damage they cause.

Tuesday, September 27, 2016

memoQ fuzzy match blues

In the past, I've criticized SDL and its programs for offering as "fuzzy matches" sentences that were far from helpful.

But the worst I've seen from SDL doesn't even compare with some absurd fuzzy matches that memoQ is suggesting. See for example:


I cannot understand how the matching engine in memoQ is suggesting as a 98% match for "Legal Entity" the translation for "CALL 1-800-555-5555".

Wednesday, June 08, 2016

Quick Tips: How to translate a MemSource project using memoQ

Recently a major customer of ours changed from using SDL Trados Studio to using MemSource, an online CAT tool. Our customer probably has good reasons for switching to the new tool, but for a translator accustomed to more powerful CAT tools, using MemSource has a downside: many of the functions we have come to rely on are missing.

I will probably write more about MemSource in the future. For now a quick workaround if you find yourself having to translate a project in MemSource but would much rather use memoQ instead - for instance, because you find that MemSource lacks some feature you love in memoQ, or more simply because you find that MemSource is slowing you down.
  1. Log in to the MemSource cloud, accept your project, pretranslate it, and download it as a bilingual .mxliff file (just as you would if you wanted to translate using the MemSource desktop editor).
  2. Open your .mxliff file in the MemSource desktop editor. Join or split all segments that need to be joined or split (Important: do this in the MemSource editor - don't wait to do this operation in memoQ: you might end up with a translated file that doesn't load cleanly in MemSource). Save your file.
  3. Open memoQ. Create a new project, and add to it your .mxliff file. When adding your document select "All files" (don't select "All supported files" or "XLIFF files": memoQ doesn't yet recognize the .mxliff extension, but correctly handles .mxliff files once loaded).
Select "All files" to import the .mxliff file
Select "All files" to import the .mxliff file
  1. In Document Import Options, change the filter from "Unknown" to "Xliff".
Select "XLIFF filter"
Select "XLIFF filter"
  1. At this point you'll have successfully imported your file in memoQ, but you'll see that all the MemSource tags are unprotected. You need to use memoQ's Regex Tagger to protect them.
  2. First, identify all types of MemSource tags in your document. You can do that by simply filtering your source text searching for the character "{". Once you have identified your tags, clear your filter (otherwise the Regex tagger won't work).
  3. Go to the Preparation ribbon. Select Regex Tagger. In Tag current document you'll have to add the rules to correctly protect the MemSource tags. The rule for protecting the {b> (begin of bold text) tag, for example, will be \{b>. A more efficient rule that works for {b>, {bu>{i> and {u> would be \{[a-z]{1,2}>. Repeat, adding all the different types of tags you have in your document. 
Use Regex Tagger to protect the MemSource tags
Use Regex Tagger to protect the MemSource tags
  1. Save your configuration (to tag future projects). 
You are done. You can now translate your MemSource project in memoQ. At the end export your translation, test it by loading it in the MemSource Desktop editor, and from it upload it to the MemSource cloud server.

Bear in mind that if you choose to translate your MemSource projects this way, you won't have access in memoQ to the translation memories and termbases added to the project by your project manager: you'll be working exclusively with the local memories and termbases you have added yourself in memoQ.

Weather that is an acceptable solution for you (and for your client) is up to you.

Friday, August 28, 2015

Unhelpful help

I've often criticized SDL for writing very opaque documentation, and I have occasionally said Kilgray's help files are more useful.

That is not always true:

Unhelpful help screenshot

Either Kilgray is saying that to create your first memoQ project you have to enter some text in the help system, or they forgot to write that text themselves.

The most likely explanation is that this is an obsolete section title that should not have been included in the help system, of course - it does not appear in the online help. It does look funny, though, and could stump a beginning translator.