Sybase is an industry leader in delivering enterprise and mobile software to manage, analyze and mobilize information for business intelligence. Sybase’s SQL Server was the first client/server database on the market. SAP acquired Sybase in 2010. Founded in 1984 in Berkeley, California, Sybase now has 4,000 employees in 60 countries. Steven McDowell is based in Waterloo, Canada.

Thicke: First of all, after interviewing Greek, Irish, American and Argentinean Enterprise Innovators over the last year, I’m happy to welcome a fellow Canadian to the club. How is it that Sybase, headquartered in California, has a director of engineering located in Canada?

McDowell: My position at Sybase is a continuation of my career that started with Watcom in 1982. Sybase acquired Watcom, a spin-off from the University of Waterloo Computer Systems Group, in 1995. Watcom SQL became SQL Anywhere, one of the database products in the Sybase portfolio. SQL Anywhere engineering is based in Waterloo. I have been with the SQL Anywhere team since 1992.

Thicke: What do you do as director of engineering?

McDowell: I am responsible for three teams: sustaining engineering, localization and documentation.

Thicke: Those are very different teams. How and why did you take on these roles?

McDowell: Originally, I was a software developer. I’m pretty picky and love fixing things and helping people, so I jumped at an opportunity to start the sustaining engineering team, which is the engineering side of customer support — we fix the bugs. This grew into a management role and included talking to customers and staff around the world. I particularly enjoyed helping international folks, and that interest led me into the localization role. We formed a team with two localization managers and a program manager. A few years later, the SQL Anywhere documentation team was seeking a new manager. I had experience with writing documentation and I knew that documentation was the dominant part of our localization costs and efforts. The documentation and localization teams were already cooperating well, but I could see a fascinating opportunity to take this cooperation to a new level, so I offered to manage the documentation team. With my technical experience, I was soon drawn into the tools and production aspects of creating documentation.

Thicke: Isn’t it challenging handling such different teams?

McDowell: Yes and no. It can be challenging to switch between localization, authoring, tools and customer support. But the teams are a manager’s dream, with highly-motivated, talented individuals who love to work collaboratively. They are constantly innovating. This article is really about them!

Thicke: But they are separate teams, right?

McDowell: Yes, but Sybase has a strong culture of collaboration that is particularly strong in the SQL Anywhere team. It’s one of the best things about working here. With the three teams, I encourage collaboration at every opportunity. I believe that it makes for stronger teams, better results and a more enjoyable job, and it creates opportunities for some interesting cross-functional roles.

Thicke: For example?

McDowell: One of our sustaining engineers works on fixing customer bugs in several of our important application programming interfaces (APIs). He also writes the programming documentation, including the API documentation. While working on fixing bugs, he also checks the corresponding documentation and corrects any defects that he finds. While he is working on the documentation, he finds and corrects defects in the code. This is an unbeatable combination for the documentation team, for engineering and for our customers. Our localization engineer handles the engineering side of localization and internationalization. He handles the export/import/validation processes for software resources. He also finds and fixes localization and internationalization bugs in the code. He is also responsible for DocCommentXchange (http://dcx.sybase.com), our website for comment-enabled documentation that is now our primary documentation delivery system for five languages, and for our Eclipse documentation format. He is also responsible for integrating the context-sensitive help into the software, so that clicking Help in a dialog opens the web-based or locally-installed documentation. One of our technical writers came to us with a joint degree in software engineering and English, a rare and valuable combination. Along with the software developers, he co-authors code comments in software source files that are used to generate our API documentation. He works with our localization engineer on the automated generation of the API documentation using Doxygen and XSLT. Currently, about 45% of our 13,000 topics are generated. We believe that we can drive this percentage higher. Our localization manager for European languages researched and developed the production infrastructure for our documentation, using XSLT and XSL/FO among others. She has implemented machine translation (MT) for German using the PangeaMT solution based on the Moses engine. She is our primary contact for the TAUS Data Association, and she is currently working with the documentation team to investigate a commercial tool to help improve our source documentation with a benefit of improving translation. Our localization program manager is currently investigating Sybase terminology and its management. She is working with Sybase localization and documentation teams, considering how to consolidate terminology in software and documentation in all languages, and to develop common terminology processes, guidelines and structures that work with all tools and formats that are being used at Sybase and its vendors. With all of this innovation going on around me, sometimes I think my greatest contribution is staying out of the way!

Thicke: How does the cross-functional nature of your teams impact localization?

McDowell: The localization and documentation teams discuss localization and authoring issues jointly. They each have excellent insight into the other team’s worlds and they work together to minimize adverse effects on the other team. The authors often anticipate changes that might have an adverse effect on localization, and before going ahead with the change, they contact the localization managers directly to ask about the effect on localization. With a little back-and-forth negotiation, the teams usually identify a way to achieve the documentation team’s goal without a big localization hit. After each localization project we have a project post-mortem (bad name!) to discuss what went right and what went wrong. The results are shared with the documentation team, which reviews processes and tools to improve the source for the next project. An example of their cooperation is a style change to index entries. Thousands of entries were affected. The translation cost of this change was potentially high ($30K for all languages). The localization team raised the issue with the documentation team, and some adjustments were made to the source so that the localization team could easily adjust the translation memories. The indexing change went ahead with no increase in translation costs. All of this happened with zero intervention by me. I found out about it after it was done. That works for me.

Thicke: Does localization feed back into the documentation source?

McDowell: Yes. Since our European localization manager wrote the XSLT production processes, she knows our XML markup inside out. Now the localization team can make very specific suggestions on how to adjust the XML markup and content to make the documentation easier to localize. The documentation team usually jumps right in and implements changes quickly because they truly understand the impact that their authoring has on localization. An example is identifying text that should not be translated, such as code, keywords, and option names and values. The localization team asked about tagging these examples clearly. The documentation team implemented a translate=”no” attribute and deployed it widely throughout the source.

Thicke: Sybase is one of the early integrators of MT. Can you tell us where you are with this?

McDowell: The localization team had been discussing MT for years, but it always seemed to be five years away from being practical. Free online translation tools and their humorous translations seemed to prove the point. A few years ago, we started hearing success stories about statistical machine translation (SMT). At the 2009 Localization World conference in Berlin, our localization manager met a person from Pangeanic, a Spanish language service provider (LSP), who offered to do a proof of concept using their Moses-based MT engine. We were a bit skeptical about how it would work for us, but our manager researched Moses MT and concluded that it was worth a try. She worked closely with Pangeanic, translating documentation from English to German. The results were very good (BLEU score of 50). She recommended that we proceed with implementing it. The MT engine was running internally within a month and our first project was completed within six months.

Thicke: And what results have you seen?

McDowell: We were expecting to go through a few translation projects and MT engine training iterations before saving money. However, we saved money on the very first localization project, even allowing for the purchase and setup cost of the MT engine.

Thicke: Tell me more!

McDowell: MT with post-editing was applied only to new words. Even after paying for the MT engine training, we saved about 20% on this first project. We’re expecting even better results after additional MT engine training.

Thicke: How do the translators feel about post-editing?

McDowell: Some like it, and some think it is less efficient than human translation. We like it because we saw an average productivity increase of about 50%. For some documents, we saw a 100% increase. To help the translators move to a more positive attitude toward post-editing and become even more productive, we are working to filter out the really poor parts of the MT output. It’s another example of how we approach collaboration, this time with our vendors and their translators.

Thicke: Are you considering expanding your use of MT?

McDowell: Absolutely. After such a successful first project, we are looking to extend MT to French and Simplified Chinese.

Thicke: Full disclosure: you have spoken to us about Japanese MT. What issues do you see with MT in that language?

McDowell: Japanese is such a challenging language for translation. From research we feel that SMT probably won’t work very well. We are starting a proof of concept for Japanese MT using a SYSTRAN hybrid setup. We talked to a customer who used this setup and claimed excellent results. We are very excited by this project since Japanese is our most expensive language in terms of time, effort and cost.

Thicke: How do you integrate multilingualism in your customer support?

McDowell: DocCommentXchange is localized and has supported localized documentation for a couple of years. An upcoming version of DCX has a new capability that allows a reader to switch between languages while staying on the same topic. I think it’s a cool feature, and we know it will be useful internally for localization testing and review projects. We don’t know if customers will find this useful, but I am optimistic that they will. One reason for implementing it is because of a long-held belief, almost a mantra: “English is just another language” — a sign on my wall says it. We want to show our customers that the localized documentation is the same content with equally high quality. They should not think that they must use English to get a first-rate experience.

Thicke: How else do you show that “English is just another language”?

McDowell: SQL Anywhere software is identical for all supported languages. There is one set of executables at release, and our bug fix releases are also for all languages. The software decides when it starts what language to show, based on operating system and user settings. If you don’t like the default behavior, we provide a simple utility to change languages. The SQL Anywhere database server is multilingualized, simultaneously supporting connections using various languages and character sets.

Thicke: How do you manage to release all languages at the same time? Isn’t there pressure to get the latest release out the door?

McDowell: Yes, there is pressure to get the software released, but we have excellent support for localization from senior management and throughout the engineering team. The engineers take internationalization and localization seriously, building it into our software at every stage. Management allows some extra time to complete localization. I’d like to make a plug for XLIFF. If you’re not using it now, you should be investigating it. We have 15 or more software resource formats. Our localization engineer implemented filters to convert them to and from XLIFF and integrated their automatic export/import into the daily software build process. The process takes care of new, changed and deleted resources across languages so that the software build doesn’t break because of something that we did during translation. It really saves us much effort, time and money. I can’t count how many times our localization managers have said “thank you” and “it’s great.” We are investigating XLIFF for documentation, too.

Thicke: Do you simship the documentation too?

McDowell: No. We did simship several versions ago, but pressure to get the software released quickly caused us to revert to releasing English documentation simultaneously with the multilingual software. German, French and Chinese documents come two to three months later. Our Japan office releases SQL Anywhere on an independent schedule, so we coordinate the release with them. Fortunately we don’t ship documentation on CD anymore. DocCommentXchange is online. For people who want locally installed documentation, we provide downloads for HTML Help, Eclipse and PDF formats. If localized documents are not yet available, the software help system opens the English documents. Once the localized documents are available, the software starts using them automatically.

Thicke: Going forward, what advances in localization technology and emerging methodologies in the industry do you hope to capitalize on at Sybase?

McDowell: MT seems to be here for real now, so we are continuing to invest in that area. We have scheduled more training for the German MT engine. We are developing a plan for MT for other languages. MT is a big factor in our future. We have managed our processes without translation management or globalization management systems, but those are on our radar. We are evaluating authoring tools to improve our source for both English readers and for translation. We’re moving cautiously on these tools because of the acquisition of Sybase by SAP. We’re learning about what SAP has in-house and are interested in working with our SAP colleagues to bring in the best tools and solutions. I have no doubt that SAP will bring a new energy and focus to what our teams do. It’s an exciting time for us.