Adventures In Digital Marketing

As with many processes in this business, using Altova Authentic as an extra step in your localisation process for Flash can sometimes seem like a drag when you first start.

There’s a lot more work to do than just cutting and pasting into a document you might think.  You have to get developer resource to initially learn how to work with it, adapt to some of the Authentic specific XML tags and so forth – and all that takes time and money.

Then there’s the time required to prepare the XML document each time you do a new project, and this again takes time to do.

Not to forget that you need to prepare the local “Altova packages” that I mentioned, the little .zip files containing the XML documents as well as a full version of the original language version of the site to distribute to the translators. That takes time as well!

All of this does add up, I agree.  But the benefits of front-loading all of this into your process and timeline reduce the risk and effort involved in moving MS Word document around or allowing direct XML source access to translators that it will completely and utterly pay for itself, in so many ways, from the very first time you use it.

You could write your own tool to do this, and I have done that as well in several different ways.  But for small jobs, jobs that generally don’t have the budget for tools development, using the method I have described is a great way to bring in a CMS style process, with the control and flexibility that it provides, to all of your Flash work where you need to translate copy using 3rd parties.

Howard
–

As well as allowing you to give translators direct access to the XML document without the need for technical skills, the Altova Authentic method that I have begun to use allows you to deliver to the translators what I refer to as “an Altova package” (I made this name up, it’s nothing to do with Altova I don’t think). 

What I mean by this is that at the bare minimum, all you really need to give to the translator is the XML file you want them to adapt, and a few other XML/XSL type documents which help Authentic know how to display the content.  But this is only half the job in a way.

When doing localisation, one of the key things to remember at all stages, especially during the design of a product, is that English is probably one of the shortest written languages in the world.  It’s tiny by comparison to many.  German, Swedish and French, for example, often come in at well over 1.5 to 2 times as long as English when translated, and what this means is if you have a restrictive design or template for your Flash work, quite often copy will “spill over” the designated area for it, and make the site unusable and unsightly. 

Whilst you can always make allowances for this during the design phase, some things will often slip through the net.  What you don’t want, therefore, is the translators merrily going about their job with no regard for the amount of space they have to work with.  If all you were to do was provide them with the XML documents to work with in Authentic, this is effectively what they would be doing – translating blind.

There is a way to get around this however. Because your Flash document works from XML, rather than any server-side scripting like ASP.net, you can run the Flash, to a certain extent, from the harddrive directly without the need for a web server (there are a few limitations to this, such as linking to external URLs, due to the security within Flash itself, but these are minor problems compared to the massive benefits this technique brings).  Because of this, when you deliver the XML documents to the translator, you can also include a local, full copy of the English version of the product at the same time.  I normally do this as a nice, compact .zip file which they can just unzip to their own computer and off they go. 

This means that as the translator is converting to their own language, they can preview their work in real-time in a web browser and see exactly how their words will look when placed online.  By doing this, you give them the ability to make copy as long or short as required to fit the space available and flow nicely.  For me, this was a huge step and meant that a further round of amendments was not required once the XML was received back and the project published to a staging environment – effectively each and every translator had their own mini-staging server on their own harddrive as they were working – perfect!

Of course, this means that in your Flash development process you have to ensure that you have the local language version, in my case English, ready well before you want the translated copy back for you to go live.  If you’re on a tight timeline (and who isn’t!) and you don’t have the luxury of being able to wait two weeks for translations to come back (trust me, two weeks is about minimum the amount of time you need to give people) then this can sound like a problem.  I assure you though, by using this method, by giving translators direct access to the XML documents and placing their words straight into the place where they need to be, you will so drastically reduce the amount of work that you and your team will have to do later on, as well as improving the accuracy of your translations, that this process pays for itself time and time again.

Howard
–

Altova Authentic is basically an XML editor.  In many ways it’s similar to XMLSpy but with one key difference.  That difference is that it includes a web browser-style interface within it that lets you display XML on a page as actual content, removed from the underlying XML structure in which it really sits.  No need, if you don’t want to, to look at the raw code underneath.

More important than that fact alone, however, is that by using XSLT to enhance the original XML content you want to work with, you can get Altova to make the content, NOT the XML structure itself, editable – in a way that is like using Microsite Word, or filling in form fields on a web site.

In this way, it’s entirely possible to give non-technical users access to complex XML files for the editing, re-writing, translating and cutting-and-pasting of all of the text content that is contained within a document, without the need for them to ever, ever, touch the actual raw XML document itself, as they would do if they were using a text editor such as TextPad.

By using Altova Authentic therefore, it’s possible to give the translator, whoever that may be, direct access to the XML document itself and enter their localised copy straight into the code, but you completely remove the risk of them messing up the structure of the document because they will never see it.

All that is required of them is to download the free Authentic application from the Internet and install it onto their machines.  A few Authentic specific XML commands at the top of the document is all that is required to prepare it for use in the tool, and you can get one of your own developers to do that for you.

No more cut-and-paste.  No more guessing where that particularly strange looking piece of Turkish copy is supposed to go.  All of that is handled for you by the very person who is doing the translation, so you can effectively sit back and relax and wait for the amended files to return to your inbox complete, localised and ready to drop into the Flash.

Howard
–

Without a CMS, what used to happen when localising the content of a Flash site was that you and your team would end up spending countless hours bashing away in your text editor of choice (EditPlus yay!) cutting and pasting away at XML documents and Microsoft Word documents, in an attempt to get the words in the right place.

This is a tiring and loathsome exercise in it’s own right even before you take into consideration the fact that as soon as you introduce foreign languages and complex character sets into the mix, you lose the ability to even read what it is you’re supposed to be producing, meaning that at best it’s often a good guess that paragraph A is supposed to go in between XML tags B.

Trust me – I’ve been here myself (many, many times!) and, to be honest, not that long ago either! It’s not pretty, it’s certainly not fun, and it can mean late nights in front of notepad.

I spent a long time thinking about this, and basically I came to the conclusion that the best thing to do would be to get someone else to do the boring and dull XML cutting and pasting for me.

It did not take me long to come up with this plan but it did take me a while to work out how to do it.

Obviously, when localising a Flash microsite, sending a word document and an XML document to an account team or client would not be the best approach.  Not only would they not understand, most of the time, the tools needed to achieve the job, but the risk of them adjust, in error, the XML structure, is far too high.

But, as that was exactly the result I wanted – to pass off the work onto a different team, I needed something that could act as a tool for the job, in exactly the same way a CMS does.  Note that this isn’t what you should actually say!  You want to do this to make the process more efficient and streamlined, reducing risk along the way.  Everyone will know you mean to pass it off, but you don’t need to actually tell them that!

So, after toying with the idea of creating ASP.net pages that would write to a database, and pass XML back out via XSL stylesheets etc. etc. I was almost ready to give up until an XML developer I was working with pointed me in the direction of a free tool developed by a company called Altova, the makers of XMLSpy, called Altova Authentic.

Howard
–

Unfortunately, for many projects where Flash is being
used, writing a bespoke Content Management System (CMS), if you don’t already
have a nice universal one, is a bit of a drag, more than likely out of scope,
and most definitely (I would bet) out of budget.

When I think of the above, the first thing that
springs to mind for me is a microsite. Rather than something such as a banner campaign (mainly because XML
isn’t often used in banners because of their small and lightweight nature), A
microsite is often big enough to have a hefty bit of copy in it, and more often
than not they are nowadays pan-EMEA, meaning multiple localised versions. 

Many times, in the case of a microsite or similar
project, the budget stretches to the site itself and a fair amount of creative,
but not to the development of a CMS tool that will add value above and beyond
the individual campaign – and if there is one thing that CMS tools are not
intended for, it’s short term projects where the cost of building the tool in
the first place isn’t worked out in the life time of the site itself. 

So, this means that mentioning a CMS to a client,
account team, or even your own digital colleagues, is normally a fruitless
enterprise.

More tomorrow on the old school methods!…

Howard

–

Flash localisation
#1 – Flash is here to stay, you best get used to it

Flash is now over ten years old and whether you love
it or hate it (and how can you not love it!?) it’s here to stay in one form or
another.

One of the things that we, as digital marketers, are
continually being asked to do is roll out sites in flash across more than one
country – or certainly I am, along with many people I know at other agencies –
which means more than one language more often than not.

This raises the issue of content management! For example, if you were going to roll out a
HTML site into multiple languages you’d probably want to employ a Content
Management System (CMS) of some kind to help with all of the different pages
and page versions that can co-exist. Not
only does this make for a nice, reusable code-base on which to build all of
your country/language combinations, as well as reducing your own workload, but
it often gives you the authorisation and publication access rules that you need
when working with multiple stakeholders in several different countries and
languages.

With flash, however, it can often be seen to be difficult
to do this without writing a bespoke CMS for the job each and every time when,
in reality, there is actually very little difference in content managing HTML
as opposed to Flash.

The reason for this is that a few versions ago,
Macromedia (now Adobe of course) had the idea to include the ability for Flash
to read and parse XML so that text, along with almost anything else you can or
would like to load in “on the fly”, could be brought in externally from the Flash
application. Note that Flash could
already read in .txt files externally, so it wasn’t a big step for them to
include an XML engine to give it that much more power, especially as XML is, at
the end of the day, just a .txt file with structure applied to it. Exactly the same as HTML is, it’s just a
different, and arguably more useful, structure.

So, when that change was made, all of a sudden the
possibility to use Flash content with a CMS to handle what it displayed was
with us as well. This was a huge leap!
CMS here we come, no?…

…well, no. That’s not the end of the story.

In my next post on this topic I’ll go into more detail.

Howard

–