 |
|||||||
 |
Welcome to the Rubric Newsletter.In This Issue: PM TIPS: Tips, tricks, and strategy from Rubric localization project managers. Welcome once again to the Rubric newsletter, where we bring Rubric's Better Localization Experience to your in-box. Past editions of the Rubric Newsletter can be found on our Web site. We encourage you to forward this newsletter to anyone interested in localization topics. If you are receiving this newsletter from a friend, feel free to subscribe to our newsletter; you will receive your copy as soon as it is published. Share Your Voice Want to contribute to the Rubric Localization Newsletter? We are actively seeking topics for either the business or technical articles, and for a new section on L10N Tips, where you share your tips and tricks for improving your localization projects. Send an email message to our editor with a proposed topic or tip and we will guide you through the rest of the process. |
|
|
||||
|
PM TIPSRubric localization project managers know the ropes, and are happy to share their top localization tips with you in every newsletter, and on the web at www.Rubric.com/pmtips.Early UI disclosure: "Always provide your English output material (i.e., PDF, Help) at the START of the project, to localization vendors. Not only is this useful for proposal and quotation purposes, it is extremely important for the actual translation. Linguists will use the output materials as reference during translation so that they can see all the text in context. If you don't provide this, do NOT be surprised that quality is affected!" — Jo Clayton, Lead Project Manager |
| |||||
|
RUBRIC NEWSSilicon Valley Localization Pro Meeting on February 13, and in Waltham Massachusetts in March: Rubric invites Silicon Valley localization professionals to meet for the spring Birds of a Feather event in Santa Clara. Past events have drawn localization pros from Adobe, Verisign, VMWare, ViewCentral, EFI and other Valley powerhouses. Photos from our last BOF event are online! Idiom Technologies is co-hosting with Rubric as we tag-team on a presentation concerning Globalization Automation Tactics. Both Rubric and Idiom have developed processes for automating localization efforts, and have gathered a huge number of tactics from their customers as well. At every breakfast event, the open discussion period brings the greatest advice directly from your peers, and this winter's Birds of a Feather event promises to provide the best discussion session yet. In addition attendees will partake in some good food, great conversation, and meaningful exchanges of ideas with their peers in the technology localization world. If you would like to be considered for an invitation to this limited-seating event, please email us for an invitation and give us your name, company, and email address. L10N Forum is now online: Rubric is sponsoring the L10N Forum (www.l10n-forum.org), a community for localization professionals. This no-advertising forum is a place for you to find and commune with other localization pros, to share tips, tactics, war stories and job postings. Though the L10N is a new forum, there are already threads on language dialects, encoding issues, web/SaaS localization, DITA and more. Drop by the L10N Forum today and join the discussion. |
|
|||||
|
LANGUAGE VERIFICATION TESTING — A WASTE OF MONEY?by Ian Henderson, CEO, Rubric |
|
|||||
|
A review by another person can be very valuable when the subject matter is highly specialized. It can be useful to team up a linguist with a subject matter specialist in cases where the likelihood of finding a good linguist with the requisite subject expertise is very low, or where subject matter specialists may not know the source language or might not be good linguists. Of course a person who does satisfy all the above criteria is preferable; but there is a high likelihood they will be fully booked as well as expensive. In order to overcome the issue of cost/availability it is established practice to have subject matter specialists help linguists create good glossaries and review translations once they are done. Rubric has used this approach for clients successfully for many years. One such client manufactures optical lens grinding equipment. This client requires highly specialized terminology, where there isn't a ready supply of linguistic talent; nevertheless, because Rubric works with the same linguists from project to project, the need for subject matter specialists has decreased over time as our linguists have become subject matter specialists themselves. Language Verification Testing, on the other hand, does not necessarily involve subject matter specialists. In some cases it simply consists of one set of linguists checking on another. The LVT team can either be a separate team of linguists at the same language services provider (LSP), or it can be a team at another LSP. Is it reasonable the client should pay to verify that the original team of linguists are "up to scratch"? As is often the case with complex questions, the answer is both "Yes" and "No." LVT is justified when the team performing LVT has more information than the team supplying the translations. In Rubric's case we have several clients who employ other LSPs to carry out verification on our translations; typically these are clients who have dozens of interconnected products. Generally there are multiple LSP vendors and they are allocated products based on their historical competence with very disparate products. The LSPs providing verification work do not perform any translations; but they have an overarching function ensuring that terminology is consistent across the entire range of interconnected products. The LSPs tying all the products together have more knowledge of the overall product range than the LSPs providing the translations. We also have clients who ask Rubric to carry out LVT as well as the translations. Again the clients typically have many different products; and the role of the LVT team, which is separate from the translation team, is to ensure there is linguistic consistency across all products. For these clients the role of the LVT teams is clearly defined as being one of ensuring uniformity of terminology across many products. The role is complementary to the work of the translation team — not supplementary; hence the justification for the client paying separately for this function. So what about cases where it is not justified to do LVT — or more precisely, not to pay extra for the LVT stage? This is where the role of LVT is to "fix" issues, a role which should have been carried out by the original LSP. I recently met an LSP at a conference. They are doing LVT for many clients. In one case they had been performing LVT services for a client for six straight years. They had no additional subject knowledge over what the LSPs supplying the translation had. LVT is usually introduced when feedback from the field indicates poor-quality translations. Instructions are given to the LVT team to bring the translations up to scratch. By all accounts, the clients are very happy with the work done; but it does make you wonder why it should be necessary to do LVT on the same products more or less continuously over many years. The client should institute changes within their primary LSP or replace them. The root problem here is that the suppliers of the translations are low-cost vendors. Economics dictates that the translation vendor use cheaper and less-qualified linguists to do the translations. The translators will be given higher daily targets, and in the process generate even more errors. The combined cost to the client of doing the translation (even at a so-called low cost), having another vendor cleaning it up, plus the additional client project management time required, certainly exceeds the cost of getting it right the first time around. The clients are in a bind, though; because the LSPs providing the translations have amassed several years of product experience, and although their linguistic quality is poor, they do have some accumulated knowledge. The clients want to continue to salvage the poor translations in order to "save" costs; hence the continued "band-aid" approach to localization. You can argue there is some logic, albeit flawed, to this approach of using "low-cost" vendors and getting somebody else to polish up the results. But this reasoning is based only on short-term results, not long-range efficiency. LVT becomes completely impractical when the LSPs do not do the job they are paid to do. We are often called upon to work on products that are supposedly ready to ship, yet have an unacceptable number of residual bugs in them. Rubric recently worked for a client who was suspicious of the quality of the delivered software, and wanted us to verify this. Unlike the "low-cost" examples above, the primary LSP involved is generally regarded as a "quality" supplier. Within 24 hours of starting, Rubric had logged several hundred residual bugs. We had no more information available than the LSP supplying the translations, so there was no justification for uncovering this number of defects. The types of bugs found were resizing issues, typos and incorrect translations in the context of the software. When pressed, the client did not know what had or had not been tested, but only that the LSP had assured them the software had been "fully" tested (whatever that vague term means). From the types of bugs we encountered it looked as if the software had been subjected to a quick set of random tests that were neither documented nor comprehensive. This example demonstrates that LVT is not only desirable, but sometimes absolutely necessary. However, our analysis is that LSPs are being squeezed so much on price, they are cutting too many corners when localizing the software. By adding LVT the problems in the product are "fixed," but the problems in the process remain. I doubt that it is cost-effective when adding internal costs to the mix, and the final quality is never as good as it could be. It is far better to engineer away the need for this type of LVT. Fortunately, there are more mature companies who adopt the approach that it is not the unit costs that need to be reduced, but rather the overall effort and hence the overall and recurring cost. When we get a project brief to "clean up" translations, we always review the materials in the overall context. Frequently the translations are in such a poor state, that "fixing" them is uneconomic. A wholesale review of the entire localization cycle is carried out and a comprehensive process put in place. Although there are some up-front costs in ditching existing materials completely, clients quickly experience significant internal savings on the engineering and project management front, as staff no longer have to deal with the intermediate "low-cost" materials. They can then move straight to working on the final product. In summary, it is interesting that the need for LVT should be expanding, much less expanding as rapidly as it is. There are a couple of reasons for this trend, good and bad. One reason is consolidation of companies and the resultant proliferation of products within the new larger companies. This situation in turn necessitates LVT to ensure consistency across the entire product range. It is good that companies are paying attention to cross-product usability in foreign languages. The bad reason for LVT expanding is the intensifying focus on unit costs rather than overall and recurring costs, which makes the provision of basic quality translations uneconomic. The so-called "solution" is to add LVT (low-cost of course) to a process which is broken, in an attempt to "fix" the problem. If clients are serious about reducing costs, they have to work with their suppliers rather than against them and be open to changing their localization process, even if it might be painful in the short term. If clients are willing to do that, they may well find that LVT was indeed a waste of money. |
|
|||||
|
SAAS ASSAULTby Françoise Spurling, COO, Rubric |
|
|||||
|
You thought localizing traditional software was a challenge! Just wait until your management decides to adopt the SaaS business model. For those of you grinding away on annual product release cycles, Software as a Service (SaaS) has rapidly redefined the software market, with strong demand from customers and vendors sprinting to deliver. Many traditional software package vendors (Microsoft, SAP, etc.) now offer SaaS alternatives to their product lines. The very nature of SaaS — multi-tenancy, online fixes, multi-version maintenance — creates new localization issues and complicates old ones. TRADITIONAL MODEL COMPRESSED Hybrid UI vs. translated UI Many SaaS (or even standard, internally used web) applications are in perpetual states of development, with updates, fixes, and even new features added as they are completed, and not bundled together into major releases. If development is truly continuous and the software becomes available more or less as soon as it is developed, then the time to localize, build, test and regress bugs is strictly compressed. What complicates the matter is that SaaS is uniquely suited suited to deliver new functionality to multiple regions on the same day ("simultaneous shipment," or SimShip, to use the old vernacular). Since localization requires some time, the only way to achieve the magical SimShip in all languages is to freeze the source UI a certain amount of time prior to going live. Executive management in the 24x7x365 SaaS world sees such delays as unnatural. In traditional software distributions, you had the luxury of delaying localized user interfaces (UI), even across full release cycles. This may be acceptable in some environments, as long as the users are aware that un-translated source text will appear in new features until such time that it is localized. However, this is not an option in a SaaS environment. Any new feature released will be in instant demand in other regions, and multinational companies that use SaaS applications cannot live with mismatched feature sets. Thus SimShip is becoming more — not less — the norm. However, it is possible to split localization of a SaaS release. A purist may wince at this idea; but it is a test model in the traditional product arena. Microsoft, for example, released partially translated versions of Windows — one completely engineered for the target market, but not yet translated. Thus, it was possible to use Windows Notepad in Thai long before the localization of the Notepad UI. Test environment In a continuous development and release environment, testing becomes as much of a challenge as localization. Release management is a critical issue in SaaS environments because you have to test against the most up-to-date software version, where the UI is a moving target. Problems arise if features are continuously added and the UI changes. When adding text to the UI, this will appear as un-translated text. Should this be reported as hard-coded text, which it might well be, or is it just that the text has yet to be localized? It is difficult for the tester to determine if it is one or the other. With one model we have seen, the tester can switch modes to see when the text was introduced. This allows the tester to see if the text postdates the cut-off date for translation. If it pre-dates the cut-off date for translation, investigations are launched to establish why the text is not translated. If the text post-dates the cut-off date, it is reasonable to assume it will be translated the next time around. Release schedules A persistent problem for localized versions of traditional software releases is that the delivery of source materials keeps slipping, without a corresponding move in the final release date of the localized product (that's never happened to you, right?). When products have long release cycles it is possible to build in margins to accommodate source material slips. In fact, when we plan our projects, we always incorporate extra time into the schedule for the unexpected. Although we do not know what the unexpected will be until we find out, at least there is time allocated to manage it. In the SaaS model, release cycles are more compressed, so delivery slippages of source materials is much harder to accommodate. One of our clients has demonstrated that it is possible to "manage" these slippages. Their executive team simply declared that there would be no more slippages, and as if by magic, all delays disappeared. It seems that when top management learns of any delays, it has a galvanizing effect on everybody involved in the development process. Management by edict has some advantages, if you are the one issuing the edicts. FEATURE-DRIVEN MODEL One of our clients is currently experimenting with a radically different model. Their model is purely feature-driven rather than time-driven. Each feature is developed, localized, tested and debugged at the time of development rather than after development is complete. Only after a feature is fully tested in every language is it released as a new feature. From a product development point of view, this is an excellent approach, which leads to a high-quality product as well as spreading out the engineering load; the drawback is the localization cost. It is a fact that 20 words cost just as much to localize as 200 (even if the pricing pressure is passed on to the localization vendor). Ten new features therefore end up costing 10 times as much compared to a model where the 10 features are localized at the same time. This is a key decision point for SaaS-focused companies: is the extra cost of feature-based localization small enough that the added value delivered to the customer makes it worthwhile? Many of our SaaS customers think so; because delivering new features rapidly, and releasing them globally, is a competitive advantage that has real value to their customers. PUTTING THE "USER" IN UI With the advent of web services it is possible to leave localization to end-users. This concept terrifies many traditional software vendors, as it removes control of the quality of the product to bands of untrained end-users. The counter argument is that end-users in native countries may well do a much better job of some aspects of localizing a product. One side effect of this tactic in SaaS localization is that it can lead to an increase in support costs as other end-users end up reporting localization errors, which are out of the control of the manufacturer. We have one client who uses this model in a semi-controlled manner, and they are getting support calls that complain about the poor quality of the translations; when it is in fact the users themselves who have modified the source language, thereby leading to confusion for the localized languages. SUMMARY We will be writing more on the topic of SaaS localization. It is a large and complex field, and the industry is still exploring new ways of streamlining the process while still SimShipping entire online platforms at once. Meanwhile, you can contribute to this body of knowledge by visiting the Web/SaaS Localization topic center at the L10N Forum to start or join a discussion about dealing with this new monster. |
|
|||||
|
|
|
|||||
