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!

Refactoring & Unit Tests

002The first step was to adapt the code we had been provided with so it was easier to manage.  This doesn’t mean the original code was bad, it just means that we needed to make sure it followed a more rational design pattern so that when something changed we didn’t spend hours trying to find all the places where the same code was repeated or used to handle another feature of the application.  This process of removing redundant code and adding in logical routines to ensure the app still behaved in the same way externally is called “refactoring”.  This took a little while and was the first step in making the app more flexible.

The second step, that was also a lot of work, was to add some unit testing capability to the code.  As you’ll see below, when I describe how the app works, the possible scenarios that this app is expected to verify is pretty extensive and because we want to be able to have the flexibility to add more features if needed without breaking what’s already working we wrote some code into the application that supports testing as many scenarios as possible all with different combinations of settings in a few seconds.  The more technical explanation is that we take the smallest possible testable part of the application, isolate it from the rest of the code, and test it.  If it fails we know immediately and we know exactly where it failed making it possible to fix it quickly and with less stress!  We can also add more tests into this quite easily if we missed a scenario that should be covered.

I should add in here that whilst I keep saying “we” I really mean Andrea and Romulus.  They are my app yoga gurus and they’ve added in the sort of flexibility that means the ongoing maintenance for this app will be a doddle.  Maybe we could coin a new bandha just for this process of making apps more flexible, prasrabhi bandha perhaps…. or maybe I shouldn’t even think about that, so apologies to the more serious yoga practitioners out there!

I should also add that none of this would even be possible in the first place without the flexibility available in Studio because of the APIs supporting all these ideas and changes that we’d like to see.  Great for developers!!  You can also find the source code for this app if you’re a developer and are interested in what we did.

The Number Verifier

But let’s take a brief look at the app itself.  The Number Verifier is a verification plugin that works best when you disable the builtin checks for numbers and then use this extensive plugin instead.  Why would you disable the builtin stuff?  Well, Studio has pretty strict rules for deciding what’s a number and what isn’t, most of which are based on what your underlying operating system thinks a number is.  Microsoft doesn’t really govern what your customers want or need and as a result you can find yourself having to deal with source text containing numbers that Studio doesn’t recognise, or Studio thinks should be localised in a different way to the one your customer wants.  Most of the time Studio gets it right, but when it doesn’t the verification check becomes a painful and frustrating experience.  You could create lots of custom rules using regular expressions but these too can be very difficult to write and require a degree of expertise many users don’t have.  So you switch off Number verification and use the Number Verifier instead.  This is where you find the builtin options, just on or off, so I turn off numbers and also measurements:


Then you make sure you have activated the Number Verifier plugin after installing it (you can get help on installation of sdlplugins here if you need it) by checking this box:


That’s it, now you’re ready to start verifiying your numbers with this clever plugin.  Your new options look like this:


Looks a little bewildering at first glance, but read through them carefully and you’ll start to see there is a simple logic to it.  There is quite a good help installed with the app so I’m not going to go into this in detail, rather I’d like to explain the main principles I think are important.

First of all you decide what it is you want to check, and you can select all, none, or any combination inbetween;

  • report added numbers
  • report removed numbers
  • report modified numbers
  • report modified alphanumerics

Then decide whether you wish anything to be excluded from the check:

  • exclude locked segments
  • exclude 100% matches
  • exclude tag text
  • exclude untranslated segments
  • exclude draft segments

Then tell the app how you want the  numbers to be handled, so whether you wish to enforce localization to a particular format or ensure the numbers are kept exactly the same.  Once you’ve done that you simply check the boxes for the source text and the target text to suit what’s allowed or intended, so what kind of thousands separator.  No complicated rules to write, and a pretty good flexibility over how you wish numbers to be verified.  You don’t have this flexibility out of the box.  So for example, take this segment for example.  Out of the box Studio reports this:


The requirement here is that the target should actually be the same as the source.  It’s not uncommon for a company dealing with many numbers in their documentation to require consistency across all languages.  To do anything else could easily lead to confusion or something going wrong.  However, Studio reports an error and tells us that the number is incorrectly localized because it wants to change the separator from a comma to a period.  So it reports a false negative telling us that a copy of the source is incorrect when it’s actually correct.  This is irritating at best but at least we can see them and ignore them.  Now imagine this:


This time we have a false positive where Studio says everything is fine, but it’s actually not.  This sort of error is time consuming at best, costly at worst.  Costly for your client if the errors make it through to the finished document and possibly costly for you for failing to pick it up.

The Number Verifier allows you to cover a scenario like this correctly so the false negative is not reported as it’s actually correct and the false positive is picked up like this (I set this to show a warning rather than an error, could be whatever you like):


This is obviously a simplified example but I think it illustrates the point.  Out of the box Studio does not have a way to easily manage scenarios like this without customising the rules for verification using regular expressions.  The Number Verifier makes it easy!

There are also two modes of error reporting, brief and extended.  The extended provides a lot more information which is often very helpful as the segments get longer and the problematic numbers are somewhere in the segment.  So for example here you can immediately in the extended message see that the problem is the target contains 25 when it should be 15.  This is much harder to see in the brief description:


I’d recommend you take a look at this plugin if you haven’t already and if you find anything it reports incorrectly post into the community in the appstore forum and we can fix it!  We can fix it because we are flexible… in body, mind and the Studio platform😉


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

001I don’t know if you can recall these games from when you were a kid?  I used to spend hours trying to find all the differences between the image on the left and the one on the right.  I never once thought how that might become a useful skill in later life… although in some cases it’s a skill I’d rather not have to develop!

You may be wondering where I’m going with this so I’ll explain.  Last weekend the SFÖ held a conference in Umeå, Sweden… I wasn’t there, but I did get an email from one of my colleagues asking how you could see what changes had been made in your bilingual files as a result of post-editing Machine Translation.  The easy answer of course is to do the post-editing with your track changes switched on, then it’s easy to spot the difference.  That is useful, but it’s not going to help with measurement, or give you something useful to be able to discuss with your client.  It’s also not going to help if you didn’t work with tracked changes in the first place because you’d need some serious spot the difference skills to evaluate your work!

Read More

001The SDL Appstore is growing!  At the time of writing this article there are 161 apps on the store and over 220 thousand downloads from our users.  This is quite impressive and we are still only getting started as the number of APIs available for developers increases.  At the moment, in Studio alone we have APIs that allow a developer to do these sorts of things:

Read More

001Workflow” and “Automation“.  Terms that are normally used (in our world) when talking about a TMS (Translation Management System).  So when working with tools like SDL WorldServer and SDL TMS which are provide a high degree of customisation, both using the user interface and/or through the API (Application Programming Interface).  For example, in SDL WorldServer you could create a workflow that automated the process for things like this:

  1. watch a CMS (Content Management System) or a number of folders somewhere for updated files
  2. as soon as new files appear kick off a project management workflow (analyse, prepare quotes, determine due dates, assign work etc.)
  3. Start a translate/review workflow with automated assignments of the work as each bit of the workflow completes
  4. send final documents off for “in country” review and support a review process if changes are required
  5. update Translation Memories, Termbases with final changes
  6. create invoices and send find details to a payment/invoicing system

Read More

001Strong words… “Committing the Cardinal Sin“!

I can remember from my early days with SDL many interesting, and often frustrating conversations with the then Product Manager for MultiTerm.  The almost religious use of phrases like “You can’t use spreadsheets for terminology”… “It only takes a few steps to be able to create a simple glossary with MultiTerm”… “You can’t properly export a MultiTerm termbase to Excel”… and many more discussions along these lines.  Well, over the last year or so mainly thanks to the SDL OpenExchange which removes the shackles of being tied to “the way it’s always done” we have seen one tool in particular that has proven this traditional way of thinking wrong.  But not because our friendly product manager was wrong… he was mostly right.  When you think about Terminology Management in the traditional sense then Excel is not really suited to managing concept oriented databases that are designed for the terminology professional.  It has its place, but is definitely prone to error and difficult to manage as the database grows.  But what if you only want a glossary?

Read More

001If you regularly read the articles I write you may have noticed that I like to talk about the SDL OpenExchange a lot.  I write articles about some of the cool applications that are available to users of the SDL Language Platform (Studio, MultiTerm, GroupShare, Passolo etc.)  I see this platform in a similar way (albeit a smaller scale) to an I-Phone or an Android phone… the core features are already there in the products and the APIs support the ability for any developer to create more features and capabilities to do anything they like!  Things that might only be useful for a small group of users, or they might be interesting for many… or they might support the breaking of long standing traditions!

Read More


Get every new post delivered to your Inbox.

Join 3,106 other followers

%d bloggers like this: