Subscribe to our blog

Your email:

Lionbridge Translation and Localization

Current Articles | RSS Feed RSS Feed

Multimedia Translation and Localization: Upcoming Lionbridge Webinar

 | Share on Facebook Facebook | Share on Twitter Twitter | Share on LinkedIn LinkedIn 
 

Please welcome guest blogger, Jeffrey Constantin, Lionbridge Localization Engineer from our Montreal office. Jeffrey specializes in Publishing, Engineering and Multimedia, and will be sharing his expertise this Thursday (March 18) during the Lionbridge webinar, Going Global with Multimedia: Practices and Process for Localizing Multimedia.


I've just been looking at some files that were sent to us last Friday by a new client for a request to localize a multimedia eLearning portal into 5 languages: Simplified Chinese (Mandarin), Czech, German, European Spanish and Latin American Spanish.

There is always a little thrill when looking at new projects and trying to scope out the size of the project. I got excited when I saw the ZIP file was 900 MBs and once unzipped, the folder contained nearly 2,000 files ranging from Flash files, to markup language files (HTML, XML), Captivate files, Images and PDFs.

First question that came to my mind was "Okay, where do we start?"

There are so many components which need to be considered both individually and as part of the entire project. From a localization perspective, it's important to look at the content, but also the container. Which is why when you get a project with 2,000 files, you may be a bit overwhelmed:

  • Is there audio?
  • What is the audio synchronized against: video, PPT, Flash, etc.?
  • Do I have the source files to edit the Flash animations?
  • Do the images in JPG and GIF format require localization?
  • What are the deliverables for this project?

These are some of the basic questions that came to mind. To get a better appreciation of the different components, I launched the actual eLearning product and saw all the components come together. And more questions came to mind:

  • Will the text fit on-screen once translated?
  • Was a Unicode font which supports Asian and Eastern European characters used within the Flash?
  • Do we really need to use a new voice for every module, or can we work with 1 male and 1 female voice talent?

After this first glance, I wrote back to our Project Manager and suggested we get on a call with the client to discuss the project and get a better understanding of their needs for the localized versions.

Register NowHave you also recently been looking into localizing some multimedia content? If you have and you'd like to get a better grasp on your projects, please join us on Thursday for our webinar, Going Global with Multimedia: Practices and Process for Localizing Multimedia. Needless to say, I've also invited our client for this new project. :)

Six Tips to Help You Manage Multiple Small Translation Projects

 | Share on Facebook Facebook | Share on Twitter Twitter | Share on LinkedIn LinkedIn 
If you're trying to manage lots of small translation projects simultaneously, try some of these strategies...    

If you're trying to manage lots of small translation projects simultaneously, try some of the strategies in this post from Tracey...


You cannot help but notice these days that information is coming to us faster than ever before and in smaller chunks! Just look at the way Facebook and Twitter have transformed the way we share and process information, personally and professionally. In the world of translation and localization, we see this impact in the number of smaller projects which is growing exponentially.

What are some tips to help successfully manage the growing number of small chunks of information that need translation? Here are a few that are working well for some of our clients and for us:

  1. Streamline and standardize the handoff process.
    Establish simple, clear guidelines for handoffs from all your stakeholders to your translation partner. On small projects, you cannot afford to have a lot of back-and-forth over handoffs or it will become inefficient very quickly!
  2. Use technology to help.
    Many of our customers, for example, submit projects directly through our Freeway portal. This helps them standardize what they are sending and then allows them access to project information in a centralized location, instead of archived in someone's email.
  3. Group small projects together when possible.
    If you can send 10 smaller jobs together, rather than sending each one separately, then you are going to save time in tracking one handoff rather than 10, which often results in chaotic e-mail activity.
  4. Look for ways to avoid costly administrative tasks.
    Any time you or your translation partner has to touch a small project, it is costing you money. So agree on ways to avoid this. Consider standard pricing to make quoting easier. Use blanket POs instead of individual POs. Set up invoicing on a monthly, rather than on a project basis.
  5. Standardize whatever you can.
    Try limiting the file formats you use. Make handoffs the same time every day or every week. Any way you can standardize will allow for more efficient processing of small projects.
  6. Work together with your translation partner to continually improve process.
    As you process more small projects, you will have a good opportunity to find new ways to improve processes together.

Don't let the small projects overwhelm you. These and other strategies can really help you keep up with the changing nature of information flow we face daily.

Six Translation Lessons Learned from Conducting a Multilingual Survey

 | Share on Facebook Facebook | Share on Twitter Twitter | Share on LinkedIn LinkedIn 
Even though Lionbridge is all about translation and localization, we learned some new lessons specific to conducting multilingual surveys.    

On February 19, Jeffrey Henning from Vovici blogged about survey translation, and referred to something I'm always saying about the difference between translating and localizing.


He also brought up several great points to consider when you create a multilingual survey, and in doing so, inspired me to share a few lessons my team and I learned while we conducted our recent Social Media Survey. We offered ours in about 20 languages, and even though Lionbridge is all about translation and localization, we learned some new lessons specific to conducting multilingual surveys:

  • Lesson #1: Keep it simple. You're going to translate and localize, review, check, fix, re-check, and test the survey in every language before you even launch it. You're going to communicate, remind and be available to answer questions in every language during the survey period. You're going to compile and analyze the results in every language when the survey is closed. You see what I'm getting at, right? Keep the survey as short as it can be, and make sure every individual question is succinct and offers a precise, defined set of possible responses. Which brings me to the next lesson...
  • Lesson #2: Avoid offering open-ended responses if possible. Unless you have a data analysis team with skills in every language you offered the survey in, you have to translate open-ended responses back into one language in order to compile the results. So if you offer an Answer Option in a list like, "Other (please explain)" - just remember that you'll get all those "Others" in-language. And you know what that means... back to translation before you can begin compiling and analyzing. Which brings me to the next lesson...
  • Lesson #3: Remember you're essentially creating 20 different surveys. If you offer your survey in 20 languages, you'll end up with 20 data sets which need to be compiled into one, assuming you want to analyze and publish aggregate results. Even with the best process in place for this step, there are important things to know, and that brings me to...
  • Lesson #4: If you re-order the answer options in each language, your results won't correlate. I know this doesn't sound like something a sane person would do, but say for example, a set of answer options consisting of 224 countries in response to a question like "where do you live?" For the participant's sake, you really should alphabetize this long list. But in the end, the numerical data values are probably going to be assigned in the same order the answer options were listed, which means you can't assume data value 1 for "where do you live" correlates to the same data from one language to the next (see table below for an illustration). The lesson here is NOT that you shouldn't alphabetize a long list of answer options. The lesson is that you need to build in time during the analysis phase to accommodate the issue, and take steps to line up the data points when necessary.

    How Data Values Change
  • Lesson #5: Plan to localize the survey's whole lifecycle. Promoting a multilingual survey most likely necessitates promoting it in those languages. And that means not just localizing the Survey Invitation email, but also the follow-ups and reminders, and of course the landing page you might be driving participants to. In other words, if you promote the survey by driving participants to an initial (localized) landing page that says, "Please click here to take our survey," then that landing page eventually needs to be updated (and localized) to say, "Our survey is closed now, thanks anyway." The lesson here is that you have to consider the full lifecycle of a survey when planning your localization effort. And that might also include reporting the results, especially if you've told your multilingual audience that you will share the survey results with them.
  • Lesson #6: Be sure what you're asking applies in your participants' world. Before even beginning translation, you need to know if the content of the survey is applicable in other parts of the world. Like, for instance, we asked participants to rank their use of "the four most popular global social media platforms," and provided MySpace, LinkedIn, Facebook and Twitter. But those are not the four most popular in every country. (We knew that going in, but should have been clearer in our question, by saying "these four popular global social media platforms," or we should have offered the four most popular ones by language-speaking region.) This underscores Jeffrey's point about perhaps needing to create "different editions of the questionnaire for different markets."

Gathering and analyzing data from around the world is challenging, but very important and well worth the effort. If you're working on any similar projects and would like to chat, please contact me at kathleen (dot) bostick (at) lionbridge (dot) com.

A Bit of Competition in the Language Technology Market Goes a Long Way

 | Share on Facebook Facebook | Share on Twitter Twitter | Share on LinkedIn LinkedIn 
So after being bashed this week for daring to charge for our technology, turns out that competition is a good thing.    

Read Nic McMahon's response to yesterday's announcement over at SDL...


So after being bashed this week for daring to charge for our technology, turns out that competition is a good thing. SDL announces a few days after our release that they will now follow suit and offer a subscription, in fact 2 euro less that Lionbridge's!  If nothing else, this proves that a little competition in the language technology market might not be such a bad thing after years of the Trados monopoly after all.

They also announced that they would open up their SDK to developers. Now, this is a much more interesting move for a company that has traditionally pursued such a closed-loop content ecosystem. But if they follow through, I have felt for a long time this strategy offers significant value indeed; it is the fundamental basis for many of our channel relationships with CMS providers such as Ektron, Sitecore, AuthorIT, Interwoven and Clay Tablet, to name but a few.

Full blown TMs solutions have proven a very hard sell and have in reality only a very narrow market opportunity. Do you really want to duplicate your CMS/KMS process with a TMS? Language workflow has its place, but I think content is ultimately always going to be owned elsewhere and allowing direct connectivity to the language engine makes sense. Luckily, as this is not the tablet or cell phone market, I am not even going to sue them for IP infringement. ;-)

So good moves in the main, the only area I struggle with is that changing the pricing and even opening the doors does not address the sheer lack of core functionality around emerging TM benefits, it doesn't make Trados any more MT friendly, it doesn't make it live or interactive. In short, it doesn't make it a different product than the core product it was, and has been, since being developed 10 years ago. Where are the standards based API's? Where is the collaborative cloud-based working environment?

Competition (even where it creates a charge for use) is a great thing: it drives innovation and helps our industry to mature. The changes SDL announced yesterday show they finally feel the burden of competing for your money, but of course they are going to have to compete much harder to keep up with the real functional changes that we, MemoQ and other companies are finally bringing to this sector of our industry.

What is Localization Engineering?

 | Share on Facebook Facebook | Share on Twitter Twitter | Share on LinkedIn LinkedIn 

Jim Compton takes a stab at explaining the field of Localization Engineering...


Throughout the many years in which I've been professionally involved in the field of Localization Engineering, I can't remember how many times I've been asked the question, "so, what exactly is it that you do again?" Some of my closest friends have stopped trying to understand...

For some, the term evokes certain expectations based on the role of traditional software engineering, and in the context of a software localization project, one may understandably ask the question, "My product has already been engineered, why is localization engineering necessary? Don't I just need translation?"

I hope the following explanation will help clarify the role of Localization Engineering and help you to obtain the maximum benefit from this function.

The Localization Engagement

The professional translation industry is in many ways a world unto itself, comprised of its own unique characters, history, practices, pricing paradigms, expectations and idiosyncrasies. In a word, it has a culture. When a company developing a globally-targeted product engages in business with the translation world, it brings to the table its own culture, and more often than not - unique requirements. 

Localization services (like those provided by Lionbridge) focus on this intersecting space between a company's language needs and the services provided by the translation world, an area that I call the "localization engagement." The primary mission of the localization engagement is to make sure that the company's requirements for language-related services are satisfied.

Localization Engagement

Like snowflakes, localization engagements are unique - coming in as many different shapes and sizes as there are different kinds of customers. From a technical standpoint, each localization engagement can bring with it a unique set of logistics that must be successfully managed. This is where Localization Engineering kicks in.

Logistics, Logistics, Logistics

There are some logistics which are are common to most localization engagements: Content that is targeted for translation must make it into the hands of translators in a format in which they can do their work using CAT (computer assisted translation) Tools, such as translation memory and online glossaries (a process typically called "pre-processing"). After translation, said content must be converted, in translated form, back into the format from which it originated (this is typically called "post-processing").

Simple Project Cycle

Here's an example: Let's say that we have a single English html file that needs to be translated into French and Japanese. That file would be converted into a format that works with the translation tool we'll be using across the project - let's say XLIFF. The process of conversion involves a parsing step which chunks-up the file into categories of content, most importantly translatable content and non-translatable content (such as the html code itself).

The XLIFF file is distributed to French and Japanese translators who return the XLIFF in bilingual format. The bilingual files are then rendered back into their native html format, but with all English UI now in French and Japanese.

Sounds simple enough, but with the huge variety of software types, publishing formats, and other forms of content - each with different syntax rules, content length restrictions, levels of support for encoding, techniques for storing translatable text, etc. - there are actually lots of details to address. Now multiply these logistical considerations with those that originate on the translation side: different character sets, behavior of translation tools, translator operating environments, linguistic rules, etc. and things can start to get complex, even on a "straightforward translation project."

Add the additional activities of synchronizing updates, testing localized content, and (choke) modifying formatting to accommodate the inevitable text-expansion, and the oversight of an expert becomes important. The Localization Engineer is that expert. It is his/her job to make sure that these logistics are taken care of.

If you've engaged in localization before and have never experienced corrupted text, broken code, untranslated content, the manifestation of post-translation functional issues, or user interface that just doesn't seem to make sense anymore, that's great! It means that the Localization Engineering function was performing as intended.

Invoking the Innovator

While managing technical logistics at the project level is important and necessary, the true power of the Localization Engineering function is realized when it is applied at a higher level. That is, the more you can involve such an expert in your overall plans and give them visibility into the processes and requirements within the "blue circle" of your global endeavors, the more that person will be able to develop the most streamlined, cost-effective, and risk-proof engagement strategy possible for you. Involve them early, and hold them accountable for constant improvements; that's what engineers do best!

Lionbridge has the good fortune of having many of the best and most experienced Localization Engineers in the industry. If you want to put their expertise to work for you, give us a call.

As always, your feedback is encouraged and appreciated!

13 Tasks a Language Service Provider (LSP) Performs

 | Share on Facebook Facebook | Share on Twitter Twitter | Share on LinkedIn LinkedIn 

Anja Schaefer, Lionbridge Director of Solution Development, continues today by describing the specific tasks performed by Language Service Providers...


As previously discussed in Five Important Things a Language Service Provider Provides, an LSP works with you to enable the launch of your products into your target markets. An LSP has access to multiple professional resources. (Lionbridge works with nearly 22,000 qualified translators.) Only an LSP has the breadth of resources and scale to tackle a large, multi-language project. 

To begin a project, you submit the necessary files to your LSP, along with instructions about the required languages and final file format. The LSP asks if there are any specifications or references that should be used, such as a style guide, glossary, or translation memory, and may suggest creating these things prior to localization. A kickoff meeting helps ensure that all key project details are exchanged between you and the LSP.

13 Tasks an LSP Performs

  1. File preparation. Extracting text from an application so that translation tools may be used; preparing translation memories.
  2. Localization kit preparation. Creating a set of instructions for the translator.
  3. Translation. Rendering the source text into the target language.
  4. Edit. Ensuring translations are accurate, and contextually and culturally appropriate.
  5. Post-translation engineering. Clearing protective meta-tagging from the files returned from translation and putting the translation back into its original format (source application).
  6. DTP or build. Performing desktop publishing (for documents) and/or engineering (for help, web, UI/software, etc.) to recreate the deliverable in the target language.
  7. Proofread / linguistic QA. Verifying that the finished job conforms to client instructions on format, presentation style, and content.
  8. Graphics localization. Translating graphics text and resizing, if required.
  9. Facilitation of in-country client review. Guiding in-country partners' review of the translation.
  10. Implementing review comments.
  11. Final QA. Reviewing the final translation, using a linguist other than the original.
  12. Testing. Ensuring that the translation is accurate, that there are no typos or grammatical errors, and that all formatting is correct.
  13. Final production and delivery. Creating the final deliverable, such as a .PDF, a website, an application, etc.

Three Things to Remember About LSPs

  1. LSPs work with professional translators. A professional translator, with expertise in the field and in the language, will save your company time and money, and help maintain your brand.
  2. An LSP will handle all the tasks peripheral to translation.
  3. An LSP will help you build a program that eventually saves you time and money, improves your quality, and helps you sell your products abroad.

Translation FAQRead the full FAQ
For more information, read our Translation FAQ: "Why Should I Use a Language Service Provider?"


Lionbridge publishes Translation FAQs regularly, so:

Global Infrastructure Demands Global Business Buyers

 | Share on Facebook Facebook | Share on Twitter Twitter | Share on LinkedIn LinkedIn 

Nic McMahon continues today with more on the value of global infrastructure and in particular, the buyer's role...


In last week's post (Emerging Global Infrastructure Solutions), I noted how the larger CSA ranked vendors are creating cloud based infrastructures that allow globally distributed resources to be deployed cost effectively in local markets. As an extension of this, I think there is also a call for maturity on the part of buyers.

In the 1.0 world, vendors were selected because of their ability to deal with the size and quality demands of a project. When I started, we talked about hundreds of employees in a handful of global locations. A buyer needed more than one organization to make sure they could handle the requirements. But localization has been a good business, and this purchasing model is just out of date with the developments of infrastructure and global capacity that have been achieved by the CSA Top 20. Almost all of those companies talk to 2,000-3,000 resources on average - accessible through their infrastructure. There is not one magic translator that sits behind a logo churning out perfect work 100% of the time.  Quality has become a process and a standard - it has evolved beyond the specific individual at an enterprise level.

MLVs bring management, infrastructure and process maturity and control, as well as risk and legal protection to a brand - this is the real value brought to the table. The ability to identify, record and correct challenges with linguists, DTP, engineering, interpretations or any other global services is a multiple per day reality far outside the errors that do seep through to the end client.

If process efficiency, consistency and cost reduction are the ultimate goals of the business, then I would love to know why adding multiple processes, approaches, technology foundations, personalities and financial complexities answers this demand in any realistic way. I think it is an old fashioned hold over from when no one vendor had the resources or infrastructure to handle the thousands of resources every CSA ranked Vendor can now bring to bear.

In the current environment, it is like demanding that PWC, Deloitte and KMPG all do parts of your annual audit just to make sure you have multiple vendors on every deal. Do you think they would have process and quality issues that might hamper overall productivity goals?

8 Considerations that Impact a Global Company's Multilingual Blog

 | Share on Facebook Facebook | Share on Twitter Twitter | Share on LinkedIn LinkedIn 

Today Kathleen Bostick shares her thoughts about what to consider when publishing a multilingual blog.


I find Alan Pelz-Sharpe's article "Content" technology predictions for 2010 (KMWorld, Feb 1) extremely interesting, particularly the second trend he identifies: "Multilingual requirements will rise to the fore." According to Pelz-Sharpe, "Of all the trends I have observed in 2009, that is the strongest by far."

From a translation/localization service provider perspective, this is certainly good news! I run Lionbridge's global marketing efforts, so I empathize with other marketers when I consider all the things under the marketing umbrella that we need to consider for translation. One example that comes to mind is this blog. There aren't many multilingual blogs out there yet, but I believe this will be the year that many more global companies head this way. Lionbridge may be one of those companies, and we're taking some time to be strategic, by considering the following 8 issues:

  1. Where does the content come from? Do you translate the blog posts from English, do you recruit in-country bloggers for each of your key languages to post original content, do you take a hybrid approach?
  2. How do you determine which existing posts to translate and in which languages? Do you just do them all even though some content may not be relevant in certain locales?
  3. How do you get your in-country team members excited about blogging and creating local content? Do you translate this local content into all the languages also?
  4. What kind of quality is acceptable for blog translation? Will readers forgive less than perfect quality? Does Machine Translation provide "understandable" with no human review?
  5. Who moderates the comments on all the blog posts, especially those non-English posts?
  6. Where do you host the blog? For SEO purposes, we know hosting a blog in-country certainly helps in the rankings, but do you really want to decentralize and have independent blogs?
  7. How do you present the "choose language" option on the blog?
  8. What about other resources on the blog, including webinars, white papers and videos blog posts?  That opens up a whole new can of worms.

We'll be wrestling with these questions this year as we evolve our blog to be more global, with input from our colleagues around the world. I don't have the answers yet, but we'll start the process and see what works and what doesn't, and we'll share that with you.

We value your comments and feedback, and we hope to be a resource for you as you follow this trend in 2010 and expand your own communications into multiple languages.

Five Important Things You Get from a Language Service Provider

 | Share on Facebook Facebook | Share on Twitter Twitter | Share on LinkedIn LinkedIn 
If you want your translated information to have a professional presentation - one that reflects the caliber of your business - you will also need desktop publishing, file engineering, and project management to coordinate all the steps.    

Anja Schaefer joins us again today, with an introduction to our newest FAQ, "Why Should I Use a Language Service Provider?"


Your company needs to translate its products, documents, or web content, and it may seem like the easiest solution is to find a bilingual person in your department to do the translations. But is that the best strategy? A bilingual co-worker typically doesn't have the time or skills to properly translate your content. Not to mention, it will be next to impossible to find a polyglott who speaks all the different languages you may require! A typical translation project involves much more than just translation.

If you want the translated information to have a professional presentation - one that reflects the caliber of your business - you will also need desktop publishing, file engineering, and project management to coordinate all the steps.

A Language Service Provider (LSP) works with you to enable the launch of your products into your target markets. This process is known as localization.

Localization includes:

  • Translation by a native speaker of the target language, located in the target market, so you can be sure your message will be understood as you intend
  • Cultural assessments, adaptation, and transcreation - the creative adaptation of marketing copy
  • Desktop publishing
  • File preparation and preparation of instructions and reference materials for the translators
  • Preparation and use of "assets," including translation memories, style guides, and glossaries that optimize the translation process to ensure quality and reduce your costs
  • Engineering - returning a translated file to its original format, be it a web page, a UI, or a web application
  • Testing - ensuring that a product works in the target culture
  • Project management
  • Internationalization audits - to ensure that the source material is optimized for localization

Five Important Advantages you get with an LSP

  1. The ability to tackle your translation needs as a program, and identify cheaper, faster, and better ways of completing your translation work.
  2. An understanding of varying file formats and how to handle them.
  3. An ability to make the most of the industry's tools, such as translation memory (TM). You can use TM for future updates to reduce the number of words that need translating, saving you time and money.
  4. Language strategy consulting, which can help you understand what markets to target, which languages to complete, and which materials to localize.
  5. Scale and breadth of resources that you typically can't build or manage internally. An LSP can scale up and down as needed to meet your fluctuating volume demands. Plus, working with an LSP allows you to focus on your company's core competency and leave the translation work to others.

Another advantage?

An LSP employs professional translators. We've all seen the funny email forwards or web posts that contain horrible mistranslations. We assume these were developed by people who did not have a full command of the language. But, it is possible they were developed by bilingual people who simply did not know the cultural nuances, idioms, language conventions, and preferences of the target culture. 

Seven Key Differences between Bilinguals and Professional Translators

  1. A professional translator is a linguist, with an advanced degree in linguistics, translation studies, etc.
  2. Many LSPs require their linguists to reside in the target locale; many bilingual people are well removed from the target culture - consider a third-generation Mexican-American translating for the Mexican market.
  3. A professional translator knows the industry tools, such as translation memory, and understands how to use them to speed up work and improve consistency.
  4. A professional translator may have an area of expertise such as medical, IT, software, etc.
  5. A professional translator may be required to have at least three years of experience in the localization field to work on your project.
  6. A professional translator has successfully completed qualifying translation tests (live project tests).
  7. A professional translator knows how to use translation assets, such as glossaries and style guides, and understands their importance. He or she will also be able to contribute to improving them.

Effective translation requires that the translator understand subtleties in both languages. For example:

  • Idioms, metaphors
  • Current terminology in a specific subject matter
  • Cultural differences, especially regarding variations of the same language, e.g. Spanish

A professional translator not only considers the words that are used, but also the culturally sensitive matters, resulting in a text that is optimally acceptable and appealing to the target audience. 

Translation FAQRead the full FAQ
For more information, read our Translation FAQ: "Why Should I Use a Language Service Provider?"


Lionbridge publishes Translation FAQs regularly, so:

Emerging Global Infrastructure Solutions

 | Share on Facebook Facebook | Share on Twitter Twitter | Share on LinkedIn LinkedIn 

We're hearing from Nic McMahon today on the emergence of global infrastructure solutions in the world of localization... 


The history and infrastructure of Localization is, for all intents and purposes, no different than the small company approach first created when neither the infrastructure nor market were available on a global basis. 

Local infrastructures, local offices, local processes local local local. Even now, the global footprint of an organization is often discussed within localization circles as "number of offices globally" or "number of people." In the 2.0 era, this view of global, both from an infrastructure and deployment sense, becomes a critical failure. As pressure mounts to meet an ever increasing active and involved global audience with ever decreasing costs, 2.0 has arisen to provide the platform potential to solve the issues.

Being global now must mean: being in the cloud, globally accessible, and deployable within seconds. Being global means effectively delivering high-quality global DTP from China to any market in the world - not having DTP in every market in the world.  Content authoring, marketing and R&D belong in the market; infrastructure, assets and the process connecting globally dispersed human capital belong in the cloud.

With the scale and infrastructure maturity of the CSA Top 20 which includes our own Translation Workspace/Geoworkz, as well as Welocalize's Markeplace, SDL TMS and more, large-scale localization is realizing the value of investing in cutting-edge global infrastructure management that connects global resources through the cloud to local market demand. It is a great sign and offers a lot of hope for finally accessing the huge body of content that has gone unaddressed since the first shock wave of the first .com boom.

All Posts