When to Start Localizing Software in the Development Cycle

In today's fast-paced world of software development, timing is crucial. Whether you're a software developer, product manager, or localization project manager, understanding when to start localizing your software can significantly impact your project’s success. This article explores the concept of branching in software development and analyzes the pros and cons of starting localization at different stages.

Simultaneous Development with Git

Software development frequently requires several teams to collaborate on various features concurrently. Git, a distributed version control system, enables developers to effectively oversee their code. The central repository houses all project files, with developers making modifications on their individual copies. After changes undergo testing and approval, they are integrated back into the central repository. This methodology aids in sustaining a smooth workflow and upholding code integrity.

What is a Branch in Software Development?

In software development, a branch is a separate version of the main codebase that enables developers to implement new features, address bugs, or conduct experiments without impacting the main codebase. This approach to branching aids in change management, promotes stability, and fosters teamwork among different teams.

There are different types of branches:

• Main/Master Branch: The primary branch where the stable, production-ready code resides.

• Develop Branch: A branch containing the latest development changes. It’s where new features and bug fixes are merged before they are considered stable.

• Feature Branch: A temporary branch created to develop a new feature. Once the feature is complete, it’s merged back into the develop branch.

• Hotfix Branch: A branch for quick fixes to the production code. It’s created when urgent changes are needed.

• Release Branch: A branch created for preparing a new production release. It allows for final adjustments and testing before merging into the master branch.

  
  

Localizing in Feature Branch

a) Process: The localization starts once a feature is built. The translation needs to be completed before the engineer start developing the next feature on the same branch.

b) Pros:

• The localization team has more time to identify internationalization (i18n) issues.

• Translators have more time to translate compared to localizing at the main branch.

• Faster for a global launch—source language doesn't have to wait for other languages.

c) Cons:

• Source may change before release, leading to conflicts when merging multiple features into the develop branch. Additional translation may be needed for code changes.

• The admin workload is high. Localization project managers can discuss with vendors for direct intake mode and use APIs to reduce the admin work.

• Minimum fee charges by vendors for low word counts may not be cost-efficient.

• Development progress may delay if the text in the feature is small. For example, a feature with only 100 words needing translation might delay engineers waiting for 1-2 days for translation completion.

Localizing in Develop Branch

a) Process: The localization starts once the code from feature branch or release branch merged into the develop branch. The localization need to be completed before merging into the main/master branch.

b) Pros:

• Most likely to include all content needed for translation.

• Translators have more time to translate.

c) Cons:

• Source may change before release, necessitating additional translations.

• Translators must finish translation before committing the code into the main branch, potentially delaying the software development process.

Localizing in Master Branch

a) Process: The localization starts after all codes merged into the main/master branch. The localization needs to be completed before the next code merge.

b) Pros:

• It's unlikely to have any content changes at this stage.

c) Cons:

• More content to translate in one batch, potentially making translation or testing timelines tight, especially for major releases.

• To meet deadlines, vendors may need to split the job among more linguists, reducing translation consistency.

What to Consider for Localization Timing

• Merge frequency and word counts: How often would the development team merge codes to feature, develop and master branch? How many words would need to be translated for each merge?

• Life span of a branch and the translation turnaround. The feature branch should remain active until the translation is completed. If the translation takes more time than the life span of the branch, it may delay the overall process.

• Overall turnaround and budget expectations

• Quality and user experience expectation

• Separate localization branch: Creating a dedicated branch for localization can also be considered to streamline the process.