Posts

Crowdsourcing for Software Localization

GettyImages_164455698Leveraging the power of the crowd to provide translation is an increasingly popular way to satisfy some organization’s translation and localization requirements for different content types such as user generated content (UGC).

This can also apply to some content associated to software. With global software products, there is quite often a wealth of associated lower impact content such as blogs, wikis, knowledge bases, user forums and other less formal content types that may qualify for crowdsourcing translation. Some of these content types are published by the software companies themselves, some content is published by the users and developer community.

Social media can also be very active around the software community with forums discussing and reviewing new product features. Quite often, this content falls outside of the main software localization program, where there is greater emphasis on the higher impact content like UI strings, product literature, support and marketing materials.

One way companies are addressing the real-time translation for high volume content types is with the power of the global crowd. It can help with product adoption, around-the-clock translation in real-time, market expansion and user experience.  As Joaquin Soler, Welocalize Vice President of Supply Chain at Welocalize, wrote in his blog, What is Crowdsourcing?,Crowdsourcing has become an iconic concept of the new collaborative, truly global economy.”

In the world of software localization, crowdsourcing is more frequently used for supporting material and content types. The question some are asking now, can crowdsourcing be used to localize the product itself? The world’s largest wiki, Wikipedia, uses crowdsourcing to create and translate the articles; however,  it is the user generated content (UGC) that is crowdsourced and not the product itself.

For open-source software, crowdsourcing is being used to localize the product. Mozilla is an example where software development takes place using the crowd. 40% of Mozilla’s work, from coding to brand development, is completed by volunteers or as we would refer to as a crowd.

Mozilla has an array of localized software. Mozilla Firefox is one of the most localized web browsers with 90 languages localized in its latest release. Mozilla Firefox is an open source application and the company has a global team of volunteer translators who use web-based localization tools like Pontoon, Verbatim and Narro to input and localize the product. Mozilla has extensive resources online informing their volunteer “localizers” on patching localization bugs, writing localization code and how to use their web-based localization tools. Mozilla frequently uses external talent pools who donate their time and skills to assist localization and product development.

For commercial and licensed software, there are notable risks when using the crowd for product localization — primarily with challenges related to quality.  Beyond usability, a failure to accurately translate a string could actually create a product launch failure in a certain language or software bug that would disable users completely.

No software company can afford to risk a new release based on a badly translated line of code. In fact, it would be unheard of for most global software enterprises to directly release software post-crowd translation.  Volunteers may be used to translate aspects of the product code; however, there are several follow-up steps that in a proven software localization workflow to get a product market-ready. The code doesn’t just need translating, it also requires rigorous testing, quality assurance and engineering to confirm all linguistic applications are accurate and secure. This level of quality and expertise are not easily applied to a crowd situation.

The power of the crowd, when managed correctly, can be of tremendous value and benefit.  The role of crowdsourcing in software localization is far more successful for supporting content, like UGC, wikis, forums and social media, rather than the product itself.

What are your opinions on crowdsourcing for software localization?

Role of Quality in Four Stages of Software Localization

479077975Based at the Welocalize office in Beijing, China, Judy Chen is Technical Services Director. In this blog, Judy shares her thoughts about the role and focus of quality during software localization.

During our routine work in the localization industry, we live and breathe quality every day, everywhere. What is quality? ISO 8402-1986 standard defines quality as “the totality of features and characteristics of a product or service that bears its ability to satisfy stated or implied needs.”

How do you satisfy stated or implied needs? For software product localization, final localized versions must be bug-free for final product sign-off. For any software localization program, as well as the software product itself and for each software launch, patch and new feature, there will be a range of supporting materials including marketing materials, internal training and communications. All require different levels of quality.

In this blog, the following details the quality focus used during the software localization process for all content types.

There are four main stages to every simple translation project or complex software localization project requiring translation, software engineering, testing, document engineering, multimedia, DTP and art work: Project Scoping, Project Planning and Preparation, Production Execution and Product Delivery and Sign-Off:

Stage 1: Project Scoping

This stage is to fully understand quality expectations, customize quality standard depending on client requirements. It is the foundation to help client to best utilize their localization budget and set localization plans in place.

  • Perform evaluation about source content
  • Define work types
  • Figure out localized languages and workload
  • Raise any source bug queries
  • Provide localization suggestions and quotation

The main input for all of the above activities is understanding the client quality expectations. If the client quality requirements are understood, we can carry out appropriate scoping: neither over scoping nor under scoping. Based on different purposes of localized materials, we can customize different quality standards.

Using some of the local terminology we have in Beijing, here are some examples of how quality expectations differ, depending on content type and impact:

  • If the localized materials are for company internal staff training, we can set quality requirements as “accurate translation, simple DTP/engineering.”
  • If the localized materials are for marketing or online customer support, we can set quality requirement as “accurate and beautiful translation, fine DTP/engineering.”
  • If the localized materials are for localization of product code, we can set quality requirement as “technically accurate, debugged, full of beauty for DTP/engineering.”
  • If the localized materials are high impact to the brand, like company slogans or taglines, we set the quality requirement as “perfect transcreation, full of beauty for DTP/engineering.”

Stage 2: Project Planning and Preparation

This stage is the process that transforms a client’s quality expectations to a series of production activities and measurable KPIs.

  • Workflow Customizing
  • Environment and Tools Deployment
  • Quality Measurement (SOPs and Checklist)
  • Work Scheduling
  • Risk Evaluation (Risk Factors)
  • Resources Reservation and On-boarding
  • Training of Involved Resources

All planning and preparation activities are based on exact quality requirements and those stated purposes confirmed at the scoping stage. Based on different quality requirements, we can customize different workflows, choose different resources and work out different quality matrices. For example, aiming at the quality requirement, “accurate and beautiful translation, fine DTP/engineering,” we can use standard translators and engineers to complete the work. We can arrange one cycle translation, DTP/engineering work with quick QA cycle.

If we are aiming for the quality requirement of “perfect transcreation, full of beauty for DTP/engineering,” we need to on-board experienced translators and engineers with specific skills and arrange more reviews and QA cycles to ensure final quality.

Stage 3: Production Execution

An integral part at this stage is the LSP management system, which must manage and track production activities for software localization activities, including a quality tracker and bug management system. This means all quality information can be extracted and checked for the following main activities:

  1. Production Process Control – All procedures are monitored to ensure that work is being handled according to customized workflows and using reserved resources.
  2. Inter-Operation Management – Constant team interaction to ensure no breaking within consequent work steps and processes. Client information is fully shared with all involved parties to ensure everyone is on the same page and aware of all targets and deadlines.
  3. Risk Management – Based on risk evaluation, routine checks are performed at the risk points with appropriate remedies used, if necessary. Version control method and bug management systems are put in place.
  4. Results Checking – Any work results are checked based on the defined quality measurement. Any non-conformity item should be evaluated and handled before delivering to client.

Stage 4: Product Delivery and Sign-Off

In theory, at this stage you have a bug free localized product. During this stage, final checks are performed and the product is prepared for sign-off. If in the unlikely event of bugs being found, careful risk evaluation is undertaken, especially for complex software localization projects. Each bug case is evaluated case-by-case and communicated with the client to decide whether to fix or defer. In stage 4, achieving quality means to deliver an acceptable product without introducing significant risks to users.

During each stage of localization, there is a different quality focus. By further strengthening our quality consciousness and achieving a deep understanding of the quality focus during our routine work, we will work smarter, more agile and produce quality levels that exceed our software client’s expectations.

Judy

Judy.chen@welocalize.com

Based in Beijing, China, Judy Chen is Technical Services Director at Welocalize.

For more information about software localization and bug-fixing, read Welocalize White Paper: A Bug is a Bug in Any Language.

A Bug is a Bug in Every Language

515722227Welocalize specializes in QA and Testing for software and technology.  Recently, MultiLingual Magazine published the Welocalize Whitepaper Multilingual A Bug is a Bug In Any Language. The informative paper outlines the impact of software bugs and the considerations for languages and localization.  Read the entire whitepaper for tips and advice on how to avoid bugs in the localization process.

Here are a few excerpts from the whitepaper or click here to read the complete whitepaper.

It only takes one bug to make a software application fail, in any language. According to research conducted by Cambridge University, software developers spend 50% of their programming time finding and fixing bugs. Bugs can be very expensive.

The same research found that the annual cost of fixing bugs is over $300 billion. Last year, a software bug in the securities order system of an Asian brokerage firm led to errant orders in the system valued at $3.8 billion. The incident was reputed to have caused losses totaling $32 million to the brokerage, which was also fined $90 million by Chinese regulators.

When any software product or update is released to the global market, it must be adapted to the linguistic, cultural, legal and technical requirements of each target locale. Bugs and defects cause programs to crash whether in the source or local language versions. Localization software testing evaluates and assesses the quality of the product – measuring given input against expected output.This process includes testing for bugs occurring during the localization phase and eliminating them before any global product launch.

Moving Software Localization & Testing Upstream

The best way to avoid bugs is to eliminate them before they arise. The process of localization should begin early in the development cycle. Using an upstream testing model, it is possible to eliminate many localization bugs (up to 80%) before any real investment in translation begins.

Localization of Mobile Apps

The localization of mobile applications presents a number of additional, unique challenges. Mobile platforms and devices present new areas for bugs to be introduced. Screen size, abbreviations and style guides are important considerations and can result in an influx of bugs.

Which Software Development Approach: Agile or Waterfall?

Many software developers and manufacturers are under increasing pressure to reduce the time-to-market and cost when introducing new products and features. Compressing software development cycles and accelerating new product launches are critical. To speed up the development process, many software developers are switching methodology from the traditional waterfall approach to an agile model. A key driver for implementing agile is to bring software products
and updates to market faster. Waterfall development follows a linear approach in terms of planning, budgets and timelines and can be rigid and inflexible.

Agile Development Requires Agile Localization

In many ways, agile forces the localization effort and the development effort to become meshed. It also changes the philosophy on how a quality deliverable is defined. Put simply, there is a window to test, a window to report and action bug fixes, and everything that falls outside this window joins a queue.

Welocalize Software Localization and Testing Services

Welocalize has a global testing team, based at two key locations, Jinan, China, and Portland, Oregon. Both testing laboratories have the relevant skills and expertise to perform user acceptance, functional and localization UI testing for a wide range of platforms and devices. 24/7 testing for operating systems, mobile devices and applications, browsers, web solutions, virtual, desktops and servers, e-learning and cloud-based solutions.

Read the entire whitepaper here Welocalize Whitepaper Multilingual A Bug is a Bug In Any Language.

If you would like additional information about Welocalize Software Localization and Testing Services, visit www.welocalize.com/quality-assurance-testing-services or contact us today at marketing@welocalize.com.

How to Plan a Software Localization Testing Strategy

Judy_chenBased at the Welocalize office in Beijing, China, Judy Chen is one of Welocalize’s senior localization managers. In this blog, Judy outlines the key steps to developing a software localization testing strategy.

We fully understand that software testing is very important step during the whole localization process. Localization testing is testing of localized products and capturing defects which are introduced while localizing a product: identifying and reporting issues, which can be fixed by localization software engineers.

A good testing strategy can help software providers to quickly release local versions of their software products and applications, supporting them to occupy and grow local markets successfully.

Based on different software developing models, there are different focuses when you want to localize into multiple target languages.

How do you plan an excellent testing strategy which exactly aligns its purposes with the client’s real needs and expectations?

First, we need identify the test scope. What is our main focus? What are the target languages? Which platform required? What aspects should not be included? For example, for software performance testing, stress testing should not be included into localization testing scope.

When we develop a testing strategy for a specific software product, we cover the following areas: Testing Scope, Test Case Development, Testing Execution Arrangement, Test Cases and Defect Management.

Testing Scope

Testing scope includes identifying the languages, testing platforms and test case coverage, the scope of new and specific features and components.

Test Case Development

Test case development is based on the scope of new and specific features and components and which are available and required for localization quality assurance (QA) to validate. Test case development should cover below aspects:

  • Verification of installer and uninstaller process
  • Verifying the user interface (UI) problems caused by localization, such as missing, untranslated, or mistranslated text, broken, duplicate or missing hot keys, text truncation, incorrect and missing icons and so on
  • Verifying functional issues caused by localization
  • Verification of the consistency of localization of all documentation, online help, multimedia, interface resources, command-key sequences and others
  • Verification of adherence to system, input and display environment standards
  • Checking for some internationalization (I18n) elements, such as:
    • Support multiple character types
    • Support appropriate fonts
    • Support reading and writing of external files
    • Render text correctly (GUI)
    • Display data appropriate in GUI

Testing Execution Arrangement

For a typical localization testing, we set up build verification testing, normal testing, regression testing and final sign-off.

  1. Build verification testing is a small subset of functional testing which is executed before QA starts with any detailed testing.
  2. Normal testing is the step to run the normal test cases and find log defects during execution.
  3. Regression testing is defect regression process to ensure the defect is fixed while there is no impact of fixed defects to surrounding areas.
  4. Final Sign-off is to perform final checking on the build before delivery to the client.

It is not unusual to run these test processes more than once, depending on different requirements and software products.

Test Cases and Defect Management

Test cases should be well maintained on a centralized management platform for easy management and recording of all test results.

Defects can be categorized as localization bugs or global and core bugs. Localization bugs are those bugs produced during localization process and should be fixed during the localization process. Global and core bugs are those bugs which can be reproduced on multiple target language versions, indicating the possibility of coding error in the source which might affect localization process and should be fixed by the client’s software development team.

Localization bugs should be recorded in the defect tracking system and communicated by localization engineers. Core and global bugs should be recorded in the defect tracking system to be communicated by client development team.

Additional Testing Solutions: Automation Testing

For some software localization projects, we also consider automation testing solutions. Although automation testing solutions may not be feasible for all software localization projects, for some big software localization projects which have huge repeat testing requests, automation testing may be good solution for long-term cost saving considerations. This method is typically used in projects which have lots of legacy features and functions and where there are high volumes of screen capturing workload for each release. Automation testing is commonly used for the screen shooting, UI testing and functional testing, which can all be adopted to both web testing and normal software testing.

Here are the main steps within a typical automation testing strategy:

  • Choose suitable automation testing tools
  • Distribute a workable automation testing framework
  • Obtain a feature scope which include test cases’ steps: typically from the manual testing team
  • Transfer the steps to executable scripts
  • Execute the scripts and collect the results
  • Analyze the results and report defects

During the testing period, automation testing should work together with manual testing, to ensure no coverage is missed. Automation testing is an additional testing solution but if it can be used smartly, the testing efficiency will improve dramatically.

If you want to find out more about Welocalize’s testing services, then take a look at our Welocalize QA and Testing Overview.

Judy

Judy.chen@welocalize.com