001Wow… how time flies!  Over three years ago I wrote an article called AutoCorrect… for everything! which explained how to use AutoHotkey so you had a similar functionality to Microsoft Word for autocorrect, except it worked in all your windows applications.  This was, and still is, pretty cool I think and I still use autohotkey today for many things, and not just autocorrect.  Since writing that article we released Studio 2015, and in fact Studio 2017 is just around the corner, so it was a while back and some things have moved on.  For example, Studio 2015 introduced an autocorrect feature into Studio which meant things should be easier for all Studio users, especially if they had not come across autohotkey before.

At least I thought it would be easier!  I was reminded yesterday with a comment to my earlier article that if you wanted to edit and maintain the autocorrect  list somewhere else, somewhere it might be more accessible then the process is not so simple.  Yes there is a import/export feature for autocorrect which you can find here:


But this list is not a simple text file… rather it’s XML.  This of course is not insurmountable, but it’s not immediately obvious as the comment to my previous article made clear.  So here’s one way to tackle it using regular expressions and excel.  I used this combination because after playing around with excel for a little while I realised that getting the word lists from the XML was far easier with regular expressions, whilst reconstructing the XML from Excel was a fairly simple task.  So one more reason to learn a little more about how to use regular expressions!

I have created a 14 minute video below that covers the whole process from start to finish.  But for those of you who just want a hint, or just want to check whether this is new to you or not, here’s what I did in a nutshell:

What we needed to get from the XML?

When you export the autocorrect file from Studio you will have a number of entries like this which you’d really rather have as text without the XML syntax:


All the autocorrect entries sit between the <AutoCorrectEntries> node.  The text you’re interested in is inside the attribute entries for the incorrect entry, src=“abbout”, and the correct entry, trg=“about”.  The easiest way I found to get these as simple text entries was to use regular expressions which you can apply in Notepad++, or EditPad which I use for example.  So I searched for this (slightly different in the video as I used \s here in case you wanted to copy paste and didn’t realise you needed the spaces at the start, which you do):

\s\s\s\s\s\s<Entry src="(.*?)" trg="(.*?)" />

Then replaced with:


This gave me the “incorrect entries” as a list.  I then undid the results of the search replace operation and immediately searched again with:


004That gave me the “corrected” entries.  I pasted them both into excel so now I have something like the image on the left with a separate column for each entry in the autocorrect list.

That’s it for the regular expression part… pretty straightforward I think but if you want to learn a little more there are plenty of resources available on the web in addition to a few articles I’ve written in the past specifically on the use of regular expressions for Studio.  It might be helpful to see where you can use these sorts of techniques in Studio if you need more of an incentive to learn.

So now you have your Excel spreadsheet which you can use to add/edit/amend the entries as you see fit.

What we have to do to get the Excel back into XML?

The task now, once you’re ready to re-import your Excel into the autocorrect settings in Studio, is to get your XML syntax back.  So to do this I just laid the Excel sheet out like this:


This is all text.  Note that my autocorrect entries are now in column B and D.  The other columns contain the syntax that makes up this line in XML:

<Entry src=abbout trg=about />

To put this back together I just concatenated the cells with this expression in cell G1:


Looks complicated but it’s actually very simple as you’ll see in the video.  I can copy this formula down the spreadsheet and I then have all the text items expressed in the correct XML syntax so they can be copied back into the XML file.  It’s a good idea to keep a copy of the original XML export and don’t mess around with that just in case you break something and can’t import your entries back in, or corrupt the autocorrect file itself.

That’s it, not too tricky, and it will allow you to work on your autocorrect entries in a more productive environment than one at a time in Studio.  The full end to end process is in the video below… hope this is useful!!

001… and hundreds or thousands of heads are better than two!!

I wrote an article a little while back called “Vote now… or have no say!” which was a follow up to the SDL AppStore competition SDL ran for a few months.  I wanted to remind everyone to go and vote if they wanted to have an opportunity to see an app developed that would be useful for them.  Well the competition is over now and we have a winner, so now we can move onto the task of creating it.

The winning idea from Marta, a Spanish freelance translator, was the “Quick Wordcount” idea and we have encouraged all users to contribute to this so it’s as useful as as we can make it for as many users as possible whilst ensuring we deliver the intent of the original idea.

Read More

002Over the last year or so I’ve been asked by quite a few translators whether SDL Trados Studio supported using Antidote as a spelling and grammar tool.  To be honest I’d never even heard of them but duly looked them up and discovered that this great sounding name for a correction tool was a plugin for Word and various other applications aimed mainly at French speakers, although they do offer a “Module Anglais”.  They also have an API, but it’s not made public on their website… so this is where our fun starts!

Read More

001This year seems to be the time our voices can be heard.  There’s been some pretty big decisions on the table already this year that have produced some very surprising results.  Brexit… who knew the majority of people in the United Kingdom would vote to leave the European Union.  Who knew it would be called Brexit… guess UKexit  was too hard to pronounce!  Who knew Donald Trump would become the Republican Presidential nominee; who knew Bernie Sanders would not fare so well for the Democrats?  If you live in these countries then these were all big decisions that you may have had a hand in even if you didn’t vote.  If you’re unhappy with the result, you should have voted; if you think now they were bad decisions then perhaps more could have been done to help ensure you were better informed?

Read More

001We all know, I think, that translating a PDF should be the last resort.  PDF stands for Portable Document Format and the reason they have this name is because they were intended for sharing with users on any platform irrespective of whether they owned the software used to create the original file or not.  Used to share so they could be read.  They were not intended to be editable, in fact the format is also used to make sure that the version you are reading can’t be edited.  So how did we go from this original idea to so many translators having to find ways to translate them?

I think there are probably a couple or three reasons for this.  First, the PDF might have been created using a piece of software that is not supported by the available translation tool technology and with no export/import capability.  Secondly, some clients can be very cautious (that’s the best word I can find for this!) about sharing the original file, especially when it contains confidential information.  So perhaps they mistakenly believe the translator will be able to handle the file without compromising the confidentiality, or perhaps they have been told that only the PDF can be shared and they lack the paygrade to make any other decision.  A third reason is the client may not be able to get their hands on the original file used to create the PDF.

Read More

001aThis time a couple of weeks ago the image on the left was me, doing something I’ve never done before… Yoga.  I’ve never seen this as anything I’d ever do but agreed to a Yoga holiday in Portugal with the family (There are no photos!).  Even though I was reasonably determined from day one that this would be something I would do on holiday and never again, I have to say I do feel better for it, and have even been caught activating my uddiyana bandha in the morning and enjoying a little meditation when I thought nobody was watching!  But now I’m back to work… so where’s the link?

Well, it’s all about flexibility and the importance of having this if you want to weather the demands of daily life.  In the weeks running up to my holiday my team, Andrea in particular, took on the challenge of updating the Number Verifier app with a couple of bug fixes and a few new bits of functionality asked for by various users.  This is a brilliant little application preferred by anyone who has problems with false positives and negatives when dealing with numbers for verification.  However, this task was not as easy as it should have been and every little change broke something else that worked before.  The original app wasn’t developed by our team so we inherited the code, and this can be quite tricky when you have to change it as unexpected things can often happen.  This app in particular has an expansive array of options and the array of possibilities in terms of number formats is even greater.  So being able to be flexible with this app in particular is very important, so this is what my team (Andrea & Romulus) did… Yoga for apps!

Read More

001a“Tags” are something we normally like to avoid, whether it’s graffiti or documents prepared for translation in a CAT tool,  and you can find articles and forum threads all over the internet about how to avoid them.  But what if you want them… the ones in a CAT tool?  Let’s say you receive a project from your client in a package, and they didn’t prepare the files as well as you would have liked, leaving you to deal with strings you’d rather have protected as tags, or even tags you don’t want to have to tackle at all.  In a nutshell, if you’re using Studio you’re stuffed!  You can prepare the files again as you like (possibly), translate them in your own project, and then pre-translate the real project afterwards from your TM, correcting any tag differences before returning the package to your client.

Read More

%d bloggers like this: