One of the readers of my previous blog on Java Localization mentioned that the apostrophe (a “single quote” character) is also a very special character in a Java string and just today I got a support case dealing with exactly this issue. The question of our customer is why a single apostrophe that is entered into a string translation in SDL Passolo is written to the target Java property file as two apostrophes. Let me try to explain.

Have you noticed that the way people work has changed over the past decade? As organizations adopt a more dynamic, real time nature of business, the way individuals and teams work together is changing as well. Of course, it’s the internet that has primarily driven this change - making collaboration, sharing and communication easier.

According to Gartner, “By 2015, 40 percent or more of enterprise work will be ‘non-routine,’ up from 25 percent in 2010. [People] will work with others with whom they have few links.  Teams will include people outside the control of the enterprise.”  To address this trend, teams need solutions that enable collaboration regardless of location.

Today, SDL is launching SDL Studio GroupShare - A collaboration solution for small to medium sized translation teams who have out-grown purely desktop solutions and are looking for a better way to centrally manage translation memories, terminology and translation projects.

One of the technical aspects of .NET which can impact localization is the concept of signed assemblies. In this blog I will discuss with you what signing of assemblies is about and how to deal with them in the context of software localization.

Last week we hosted the SDL Localization Day, where we looked at the issues of delivering software on a global scale. It was made up of six sessions including, as is so often missed with these events, a customer case study from Roche Diagnostics.

For the format of the day, we ran a series of webinars “nose to tail”, meaning that you could drop in and out as needed. It seemed that most people stayed for all sessions, but as everything was virtual, we didn’t really know if you’d stepped away from your desk for comfort or tea breaks!

Last week I discussed the buzz about Agile and what this means for software localization, and I had some interesting feedback. Now I want to expand on this with some use cases for integrating agile software development with software localization.

Mixing agile and waterfall workflows

You might use agile development but only hand over material to your localization resources when the feature set has stabilized. There will be some mid-localization drops to handle. This is a valid scenario with the main difference being that by using Agile, the time between code freeze and delivery is much shorter than in the more traditional software development workflows. This can be compensated by allocating more resources to the software localization project, or by accepting an earlier but functionally incomplete drop. It is all about when the code is stable and complete enough to involve the localization team. You need to consider the potential for increased management overhead and quality risks.

Loosely coupled agility

If sim-ship is required, it makes sense to start localizing your software earlier in the development life cycle. But even in this scenario it does not necessarily mean that the localization team needs to be embedded in the development workflow and to deliver against each and every sprint (a sprint is the period of time, usually 2 weeks, during which a defined set of development work has to be delivered). The localization team needs to be able to efficiently handle mid-localization updates on perhaps a monthly or bi-monthly basis. Localization based on binary files, the usage of localization tools to maximize the reuse of translations during mid-localization updates, and project management tools can all help to improve efficiency in this scenario.

Software localization embedded into the agile development process

Here we have software localization tightly integrated with the software development process. In its extreme, this means that the localization experts become part of the scrum team as one additional stakeholder to define and drive the development. Tools can help to minimize the friction between the different workflows for development and localization.

What benefits can you expect when you integrate localization more into the agile development workflow? I see three main benefits:

1. Starting localization early in the development process can help to identify internationalization issues at an early stage. This benefit aligns very well to the goals of agile development. 
2. Getting linguists involved at an early stage can help to improve the quality and consistency of  the source language as well as the target languages, and can also bring user experience benefits.
3. If localization is a continuous process, less localization resources need to be allocated for a project and they can become product experts on the fly.

Agile software development does not force us to re-invent the proven workflows used in software localization, although adjustments in the processes and the proper use of technologies will help.  It is more about new opportunities to get more involved, and earlier involved, in the software development process to bring in the expertise about languages and software internationalization.

As a summary let me re-write one of the principles of the Agile Manifesto to underline the value we can provide:
Business people, developers and localization experts must work together daily throughout the project.

If you want to learn more about how SDL's localization tools are supporting agile software localization processes, please join us at the Virtual SDL Passolo day on 22 September 2011. We are running this in English and German and we invite you to participate in the discussion!

Agile software development is a major shift in the industry. Adopting new methodologies takes a while but we are seeing more and more companies adopt agile development. If you are using agile development, don’t you also need agile localization? And if so, what could that mean?

The buzz about Agile

You will have heard (and probably implemented) Agile for software development. Agile sounds good—we all want to be agile, not dull! So there is a danger that agile becomes a buzz word, used too often and in a misleading sense.

The Agile Manifesto (http://agilemanifesto.org) lists the principles to follow if you want to develop the agile way. Why not apply these principles to other areas, such as software localization? We all would sign off a statement like “Our highest priority is to satisfy the customer through early and continuous delivery of valuable localized software”, wouldn't we?

Do we need agile software localization?

Agile is about avoiding development of the wrong software or product. The more complex the requirements, the more likely this will happen.  The longer it takes to develop the software, the more likely the requirements have changed in the meantime. Developing successful software products takes time, is expensive and is very risky. Agile helps to reduce the risks.

The major difference between software development and software localization is that a localization project is significantly easier to define. Obviously there are plenty of significant challenges to overcome, but understanding the requirements is not usually one of the biggest challenges.

So I don’t think we need a new agile localization paradigm. What we need is a new relationship between software development and software localization which is defined by the business requirements for the product.

We will be discussing this subject and more in subsequent blogs, and during our Virtual SDL Passolo day on 22 September 2011. We are running this in English and German and we invite you to participate in the discussion!

This subject probably needs no introduction because everyone knows how to use Microsoft Word and has seen or used track changes at some point.  So this article is going to focus on how we use it in Studio 2011 and on how we have made this compatible with Microsoft Word to enhance the review process for both translator reviewer and subject matter expert in addition to being able to use this to provide consistent audit trail capability for any filetype.

Certainly this is the ideal situation for every software vendor who would like their tool to be the only one their users need... one desktop and only one tool needed..!  A couple of years ago I ran a survey to look at the different applications that a translator used and the results, whilst not entirely surprising, showed that the average translator had two different translation tools installed; and a multitude of applications you wouldn't believe..!  I imagine some of you will know quite a few who have three or even four translation tools installed, but wouldn't it be better if you only needed one?

What regex... this one of course!  You can resolve your problem easily with the following expression;

\b(0?[1-9]|1[012])[- /.](0?[1-9]|[12][0-9]|3[01])[- /.](19|20)?[0-9]{2}\b

Now, I know most of you will instantly recognise this as an expression to find invalid date formats.  But for those of you who don't, and who have heard the phrase "Just use this Regex Expression.", let's take a closer look at how they can be useful.

Language Weaver President and CEO Mark Tapling appeared on Fox Business News' "C-Suite Sit Down" segment on Fox Morning Business with anchor Jenna Lee on Friday, December 5, 2008. Mark talked about Language Weaver unique solution set and prospects for the automated translation industry in 2009: