Software localization is often an afterthought instead of being embedded into projects from the start. In 2017, we started a localization project for the software-fulfillment process in our Tokyo office. The regional team had approached us because partners and end customers were having a “broken” user experience—from commerce applications to fulfillment process—because some applications were in Japanese, others in English.
In 2014, we had launched a corporate extended relationship management (xRM) project, which included localizing major partner and customer-facing applications. The project had a multi-language data foundation. However, constant updates to the software and newer projects were causing us to fall behind. In addition, we faced challenges in getting partners to align with our software subscription business strategy mainly for a localized user experience. For most projects, localization support was added long after the release of the application or new capability.
Since the Tokyo project, we’ve brought localization into the initial phase of software development. Here are the six guidelines we follow.
The time and resources spent on localization can be hard to justify in quantitative terms because outcomes can be subjective and difficult to evaluate. For the Tokyo project, we measured success based on:
◈ Establishing strategic self-sufficiency by addressing/removing customized localization work-arounds by various users.
◈ Providing a smooth user experience between commerce and fulfillment applications.
◈ Storing consistent user language preferences and sharing user language preferences across applications.
◈ Making it as easy to add a new language during software product planning as adding a new user story.
◈ Accelerating go-to-market.
◈ Giving us a competitive advantage in international markets.
Our original localization initiative tried to address the problem after new applications and features were released. Our analysis of the software-fulfillment process in Tokyo showed that this approach led to production stoppage, re-engineering, and increased resource requirements to identify customer impacts and application dependencies. Thinking about localization from the initial phase of software development avoids these risks. To achieve this, we re-engineered the architecture to be ready for internationalization. According to Wikipedia, internationalization (i18N) is the process of designing a software application so that it can be adapted to various languages and regions without engineering changes. Localization (l10N) is the process of adapting internationalized software for a specific region or language by translating text and adding locale-specific components.
Assessing localization requirements requires an understanding of all stakeholder groups, which often have a wide variety of backgrounds. Regional teams drove the discussion, but the Cisco IT architecture framework team was also involved because they owned the application platforms. There were many stakeholders like Japan sales operations, Japan strategy & planning, corporate business team, corporate IT team, global translation services team, and the architecture framework team. To achieve our localization goals within the target timeframe, we took the following steps:
◈ Aligned the business outcomes with the country’s go-to-market strategy
◈ Established a partnership with the architecture framework team to enable scalable internationalization
◈ Scheduled regular team meetings to enable dynamic collaboration across all functional teams responsible for software business adoption
◈ Implemented a phased approach to localization, starting with the highest-priority applications
The localization process is complex and requires commitments from business leaders as well as engineers. To obtain these commitments, we:
◈ Established dynamic teams, consisting of members from across the globe including various stakeholders who could participate in reviews and take necessary actions.
◈ Educated upper management about the importance of dynamic team sync up meetings on a regular basis.
◈ Assigned dedicated teams to re-engineer the architecture to be internationalization (i18N) ready.
◈ Encouraged dynamic team collaboration by scheduling regular meetings at times that worked for team members in different time zones.
◈ Analyzed application dependencies during the project to ensure smooth project sign-off to avoid release time surprises and re-work.
Localization is more than simply translating existing web properties. More broadly, it’s adapting content and applications for regional or local consumption. This sometimes requires modifying the flow of the user interface or requires changes to the source language (English for instance) itself and other site elements to match the user’s cultural expectations.
To ensure the quality of localization, we:
◈ Aligned the user interface to follow same user preferences across different user applications
◈ Localized every possible user interface flow
◈ Asked linguists to review application screens
◈ Utilized appropriate change management to review with teams so that no gaps arise when changing the user interface in one language, impacting the core (English) user interface flow and vice versa.
This guideline applies whether you’re building a website, customer application, or partner application. In a Harvard Business Review study, 72% of consumers said they’d be more likely to buy a product that’s in their own language and 56% said this was more important than price.
Progress to-date
Globalization and internationalization are becoming a standard for every Cisco IT project (Figure 1). Once the projects get realized, if the project has gone through localization, it can increase the business opportunities among international customers. The data gathered with a localized user interface can give clear visibility for data analysis.
We are working to make localization a business priority in other regions. To support that effort, we are building a strategic and holistic operating model and framework for localization across products, IT platforms, technical support documents, and channel programs portfolio
Since the Tokyo project, we’ve brought localization into the initial phase of software development. Here are the six guidelines we follow.
1. Define success
The time and resources spent on localization can be hard to justify in quantitative terms because outcomes can be subjective and difficult to evaluate. For the Tokyo project, we measured success based on:
◈ Establishing strategic self-sufficiency by addressing/removing customized localization work-arounds by various users.
◈ Providing a smooth user experience between commerce and fulfillment applications.
◈ Storing consistent user language preferences and sharing user language preferences across applications.
◈ Making it as easy to add a new language during software product planning as adding a new user story.
◈ Accelerating go-to-market.
◈ Giving us a competitive advantage in international markets.
2. Realize that localization is foundation work, not an add-on
Our original localization initiative tried to address the problem after new applications and features were released. Our analysis of the software-fulfillment process in Tokyo showed that this approach led to production stoppage, re-engineering, and increased resource requirements to identify customer impacts and application dependencies. Thinking about localization from the initial phase of software development avoids these risks. To achieve this, we re-engineered the architecture to be ready for internationalization. According to Wikipedia, internationalization (i18N) is the process of designing a software application so that it can be adapted to various languages and regions without engineering changes. Localization (l10N) is the process of adapting internationalized software for a specific region or language by translating text and adding locale-specific components.
3. Know the stakeholders and key partners
Assessing localization requirements requires an understanding of all stakeholder groups, which often have a wide variety of backgrounds. Regional teams drove the discussion, but the Cisco IT architecture framework team was also involved because they owned the application platforms. There were many stakeholders like Japan sales operations, Japan strategy & planning, corporate business team, corporate IT team, global translation services team, and the architecture framework team. To achieve our localization goals within the target timeframe, we took the following steps:
◈ Aligned the business outcomes with the country’s go-to-market strategy
◈ Established a partnership with the architecture framework team to enable scalable internationalization
◈ Scheduled regular team meetings to enable dynamic collaboration across all functional teams responsible for software business adoption
◈ Implemented a phased approach to localization, starting with the highest-priority applications
4. Obtain buy-in from key stakeholders
The localization process is complex and requires commitments from business leaders as well as engineers. To obtain these commitments, we:
◈ Established dynamic teams, consisting of members from across the globe including various stakeholders who could participate in reviews and take necessary actions.
◈ Educated upper management about the importance of dynamic team sync up meetings on a regular basis.
◈ Assigned dedicated teams to re-engineer the architecture to be internationalization (i18N) ready.
◈ Encouraged dynamic team collaboration by scheduling regular meetings at times that worked for team members in different time zones.
◈ Analyzed application dependencies during the project to ensure smooth project sign-off to avoid release time surprises and re-work.
5. Know the difference between machine translation and localization
Localization is more than simply translating existing web properties. More broadly, it’s adapting content and applications for regional or local consumption. This sometimes requires modifying the flow of the user interface or requires changes to the source language (English for instance) itself and other site elements to match the user’s cultural expectations.
To ensure the quality of localization, we:
◈ Aligned the user interface to follow same user preferences across different user applications
◈ Localized every possible user interface flow
◈ Asked linguists to review application screens
◈ Utilized appropriate change management to review with teams so that no gaps arise when changing the user interface in one language, impacting the core (English) user interface flow and vice versa.
6. Speak directly to the customers in a language they understand
This guideline applies whether you’re building a website, customer application, or partner application. In a Harvard Business Review study, 72% of consumers said they’d be more likely to buy a product that’s in their own language and 56% said this was more important than price.
Progress to-date
Globalization and internationalization are becoming a standard for every Cisco IT project (Figure 1). Once the projects get realized, if the project has gone through localization, it can increase the business opportunities among international customers. The data gathered with a localized user interface can give clear visibility for data analysis.
Figure 1
We are working to make localization a business priority in other regions. To support that effort, we are building a strategic and holistic operating model and framework for localization across products, IT platforms, technical support documents, and channel programs portfolio
Posts
0 comments:
Post a Comment