Globalyzer i18n Process

From Lingoport Wiki
Jump to: navigation, search

Introduction

Lingoport has both products and services for internationalization (i18n) and localization (L10N) automation.

  • For service engagements, an initial step is the process of discovery: the customer and services team dive into the repository to uncover the important issues about the software including programming languages, databases, libraries used, resource file types and structure, and directory structures. This process normally includes discussions with a customer's architect that can help explain the structure of the software, inter-dependencies of the modules, what is in or out of scope, and the first priorities. Finally, there is a discussion around “deprecated code” as well as other development priorities that might lead to re-writing or replacement of sections of the code. The analysis may or may not include the prioritization of the sequence of refactoring to align with the timing of customer/market needs.
  • Companies that are new to Globalyzer (and/or Localyzer) will likely want to have Lingoport assistance for at least the first few i18n iterations, be it with the code refactoring itself or how to set up the first iterations. Lingoport has over 18 years of experience with this discovery process and is familiar with the complexities that accompany large software projects.


Overview Diagram

Globalyzer Iterations.PNG

Before starting with Globalyzer, make sure to verify the IT setup, and which iterations to start with before going on to the next iteration. I18n project may have to address thousands of issues and development teams may be overwhelmed.

Lingoport recommends addressing issues in a step by step way and keep the i18n work manageable for all involved.

An iteration can be based on a module, a set of user facing screens, a type of issues, a repository.

Before starting with Globalyzer, make sure to have an identified iteration.

IT Check

The first step is to make sure the IT setup is correct and complete.

Lingoport provides a checklist to help with this process, and a script to check that the software installation was done correctly. Before any other step, please make sure to have the checklist (mail support at lingoport dot com if that is not the case), and that each prerequisite checklist step is completed before going to the next step.

Programming Language

An application typically consists in many layers, each with its own programming language. Each may require a specific Globalyzer rule set (how to scan the code) and refactoring approach. One iteration may focus on a programming language in the application.

Basic Files Check

The next step is to run a utility to Count Lines of Code (CLOC) that is available from this link https://github.com/AlDanial/cloc. The CLOC reveals the types of programming languages and size of modules. It is a quick way to get a first look at the complexity of the code.

Globalyzer File Inspection

In addition to the Basic File Check, if Globalyzer scanning is part of the on-boarding, use the Globalyzer File Inspection to get a sense of what kind of possible rule sets to apply. From the Globalyzer workbench:

  • Project->Run Project Files Inspector
  • Browse to select the Excel Output file. Click Save.
  • Click Generate to generate the report.
  • The Console tab in the Workbench will tell you when/where the report was generated.
  • Look at the File Inspection report to determine what scans this code base needs

Module

Basic Code Check

Next is a first look at the code and the repository structure. The repository files can guide some of the on-boarding. For example, a repository named ‘jquery’ is highly likely to contain third party libraries that would be considered out of scope.

In Scope Check

The next step is a meeting or series of meetings with architects familiar with the code. These are busy people so the meetings are typically brief and to the point. The goal is to understand how the code works, what the components are, how they interact, what is user facing, and what is in scope and what is out of scope. Depending on the i18n requirements, out of scope code can include

  • deprecated or dead code,
  • application configuration modules,
  • ALM settings,
  • third party libraries,
  • generated code,
  • SQL dump files,
  • Compiled code,
  • Test code,
  • Infrastructure,
  • Other code not created by the dev team.

These meetings provide substantial insight into the eventual Globalyzer setup.

Logical Grouping Check

Globalyzer projects need to be set up by logical components of the source code, especially in large applications where components are developed according to different frameworks, coding style and their specific libraries, often developed with different skill sets.

For example, a Globalyzer project would be done for Android and another Globalyzer project for iOS, even if the repository contained both. Each of the logical components can then be configured as a Globalyzer project and may have its own Globalyzer Rule Sets. Use Globalyzer File Inspector on the project to double check the content of the module.

In particular, identification of a module around a user facing functionality may lead to clear and immediate feedback post refactoring and redeployment of the application.

Include/Exclude Check

The Globalyzer iteration configuration is will have the updated include/exclude list for directories and files in the repository.

i18n Issue Type

An iteration may address only certain i18n issues, for instance Embedded String, or Date Format issues. A Globalyzer project based on the target issue will focuses the iteration, allow to refine the rule set specifically for that issue type, and the i18n team can go through the issues with the same refactoring approach, for instance externalizing Embedded Strings using a utility or refactoring Date Format issues with the proper method for the programming language.

For instance:

  • What method(s) do you use for debug? (strings passed to those methods need to be filtered out)
  • What is the default severity of i18n scanning you'd like to start with?
    • P1, possibly P2, to start - recommended
  • Do you want to scan for everything i18n, or limit scans to:
    • Strings
    • Concatenations
    • Certain locale sensitive methods, like date/time

Iteration Check - Addressing i18n Issues

It is recommended to scan a small subset of the code known to be in scope to get a feel for the types of i18n issues that are most common and to get a sense for the scope of rule set refinement that will be needed. It also success tests the pathways to make sure the eventual full scans can be executed and the proper ports and access permissions are invoked properly. Each iteration is faster and can be validated more quickly. Validation of each iteration with a member of the development team is recommended, and the final configuration should be reviewed by an architect if possible.

At the end of each iteration, the i18n issues need to be addressed. This can be done in many ways:

If the issues are not addressed, going to the next iteration will only add issues and may overwhelm the development and the localization team

Globalyzer in IDE for Developers

Developers should use Globalyzer in IDE in order to fix or ignore issues. Please see:

Dashboard for Managers

Managers should track progress of the i18n project using Dashboard. Please see:

Globalyzer Workbench for i18n Experts

I18n experts should configure and refine rule sets using Workbench. Please see:

Tying it all Together

From Workbench to Dashboard to Globalyzer in IDE, how things are tied together:

Retrieved from "http://wiki.lingoport.com/index.php?title=Globalyzer_i18n_Process&oldid=96532"