Archive for February, 2011|Monthly archive page

Custom reporting by means of SQL queries in Globalsight

Friday, February 18th, 2011

One of the main advantages of our Globalsight installation is the ability to pull custom reports from the database by means of a simple SQL query. This one here, for instance, will list all currently available activities and the users that they are available to by target locale:

SELECT, As 'Job name', CONCAT(locale.iso_lang_code,'-',
As 'Target Locale',
jbpm_taskinstance.name_, jbpm_pooledactor.actorid_ As 'Available to'
FROM job, workflow, task_info, locale, jbpm_taskinstance, jbpm_task, 
jbpm_pooledactor, jbpm_taskactorpool
WHERE jbpm_pooledactor.id_ = jbpm_taskactorpool.pooledactor_ AND
jbpm_taskactorpool.taskinstance_ = jbpm_taskinstance.id_ AND
jbpm_taskinstance.actorid_ IS NULL
AND workflow.job_id = AND
workflow.iflow_instance_id = task_info.workflow_id AND
jbpm_taskinstance.task_ = jbpm_task.ID_ AND
jbpm_task.tasknode_ = task_info.task_id AND
workflow.target_locale_id = locale.ID AND
job.state = 'DISPATCHED'

There are many other examples listed in the help wiki:

This only works, because we have our own instance. 
If you are running GS as a multi-tenant service, it won't work. But if you have your own installation, 
this works fine and allows for very powerful reporting. 
(I find this ability so cool that I am even writing a blog post about it late on a Friday night.)



Our Globalsight migration – lessons learnt

Wednesday, February 9th, 2011

We have been using Globalsight as our central localisation management system in marketing for about 5 months now. The migration was completed during a two month project in summer 2010. We were looking for a system that would provide more flexibility in terms of process modeling and would have an open architecture that we can build a proper localisation platform on.

Note that this blog post is not meant as a commercial advertisement for the system. I just want to give other enterprise localisation managers in the IT industry some ideas about what was involved and what to watch out for.

The scope was something like this (as determined retrospectively):

  • SaaS- based deployment of 5 servers in fully managed data center (prod and dev/test system)
  • Creation of 44 localization profiles
  • Building 200 custom workflows
  • 49 unique file processing rules
  • Setup and training for 55 users distributed around the globe
  • Migration of over 600 MB of translation memory data
  • Terminology database population with over 8000 terms

So, what were the good, the bad and the ugly of the migration project?

  • On the plus side, I created only a rough project schedule at the start in collaboration the different people involved (system vendor, localisation vendor, procurement, web dev, IT security…), so that we would maintain the right level of flexibility and agility. We completed the project nearly on time after 2 months (ok, it was a few days late, but that’s not bad for a project with this level of complexity).
  • When the system went live, all the assets and most of the required workflows were set up, all the internal users in salesforce and all the vendor PMs were trained and ready to use the system.
  • For the purpose of training internal reviewers, I created a video that they could watch at their convenience (important when the reviewers are distributed around the globe).
  • We also ran a successful configuration workshop in the form of a 1-day face-to-face meeting. This helped us to work out the confg requirements quickly and immediately start implementing them in the system.
  • Most importantly: We had a great project team and everyone was highly dedicated and committed to the project. All the required skills and departments were represented and the determination of the team members to get things done blew me away many times.
  • Regular meetings or status calls were running smoothly, on a weekly basis initially and more frequently towards the end of the project.
  • We were able to complete the project in a globally distributed team effort, without a so-called “war room” and without people spending many late nights or working weekends.

What could we have done better? Captain Hindsight would say:

  • Allow sufficient time for testing, of both the dev/test and of the actual production system. If the overall migration takes two months, at least two weeks should be allowed for thoroughly testing the system. Make sure you have a test plan worked out and test tasks clearly assigned. Also, make sure to agree timelines with the testers for completing these tasks. The time that we had planned for testing was a bit too short.
  • Don’t train the users too soon. We trained the users several weeks before the system went into production. By the time they started working with the system, we had to retrain some of them (which wasn’t that hard, due to the video-based training, but nevertheless an inconvenience).
  • Don’t train the users too late. I had assumed that the translators and production teams at the vendor side could start using the system shortly after go-live. As it turned out, they weren’t ready quite as quickly, because they needed more time than expected to adjust to the new way of working.
  • If you have a hard deadline, make sure you have sufficient buffer time in the project plan to allow for the unforeseen to happen, especially when you are working in a complex corporate environment. In our case, we lost a few weeks due to some unexpected internal procedures (which I can’t disclose here).
  • Don’t expect things to work perfectly fine after go-live, even with enough testing. There will be a period of making minor incremental adjustments to the system, based on what you learn during the production use. There might locale pairs missing or workflows need to be adjusted slightly. This period will most likely take a couple of weeks.

Overall, I would say the Globalsight migration project was a great success and hopefully others who are planning a similar move will be able to benefit from the experience as described here.



Date set for localisation un-conference Dublin in 2011

Tuesday, February 8th, 2011

Save the date: 12th of May it is (Thursday). Details will follow soon, we are currently in the process of updating the website (



Discussion on LinkedIn

Tuesday, February 8th, 2011

Wow, has it really been this long since the last post? I should have added this to my new year’s resolutions – update blog regularly (or just shut it down again).

Just wanted to point out this here:

There is an interesting discussion going on on LinkedIn right now regarding the topic
Why is so difficult to find freelancers for technical tasks, such as file preparation, compiling, etc.?.

IMHO, it’s mostly down to economics – clients are willing to pay adequate per-hour rates for jobs like file preparation, TM management, automation by mean of scripts and utitlities etc.