While we do hope that most of the work around l20n installations will have visual, GUI web tools, we also recognize that it’s important to provide simple, robust command-line tools that will cover the entire workflow.
For the l20n workflow to happen, we want to have a complete command-line toolchain that will automate common tasks required to operate and maintain localizations.
Behind this toolchain we provide a powerful API that localization and release tools will use, but the first consumer of those API will be the command-line based environment for l20n.
For this toolchain, we have three personas in mind:
- a localizer
- release driver
- developer
Localizer
Localizer should be able to start a new localization, stay informed about the status/completeness of his localization and have easy way to learn about updates. On top of that, he should be aided in navigating through the changes like new, modified or removed entities, get help in maintaining his localization between releases and work with the build team on marking which localization version is ready to be shipped.
Initially we want to provide four elements that will enable this:
- on demand activated shell prompt customization that will provide contextual information while the localizer navigates around the l10n project
- bootstrap command that will help initialize a new localization sandbox for a project
- set of diagnosis tools like validator, completness check and localization status, all of which will analyze given localization and provide detailed information or what remains for the localization to be completed
- an automated update tool that will help localizer keep the localization structure in shape, helping adding new strings, removing obsolete and provide information on the updated ones
The latter two concepts are powerful, and we have to be very careful when we design them. Each operation may harm the system, since we can easily loose the ability to review changes made by localizers in VCS history view if we apply changes that the localizer did not work on, or we can hide from the localizer the contextual information by removing entities that became obsolete, but their value has been reused in a new entity added just next to the old one.
All this kind of stuff has to be taken into account and we want to aim for a balance between simplifying day-to-day localization work, and maintaining VCS friendliness and sense of control that a localizer must have over his localization project.
Release driver
As with a localizer, we want to provide methods to automate common tasks, like selecting locales for a release, learning about status and progress of multiple locales at once, accepting new locales from localizers and batch updating locales with changes.
In order to achieve that, we want to provide:
- a custom shell prompt that will aid release driver while he navigates between localization projects
- scripts that will make it easy to analyze the status of localizations and validate them
- tools that will allow release driver to maintain the list of locales and their version, to be released with a given version of the product
- a script that will take a small “l10n patch” like a number of new entities, or value changes, and apply it across multiple locales
Developer
For the developer, we want to make sure that it’s easy to make his code localizable and maintain it that way.
This means that we want to make it easy to add new entities manually and verify that they work with tests, that we can extract entities from code where possible (like – XML), and it’s easy to spot hardcoded strings.
For this, we plan to provide the following tools:
- a validator that outputs unit-test readable outcome statuses, so that unit-tests can be written against localizable code
- an extractor for simple extracting and maintenance. The extractor should be able to help developer clean l10n files by removing strings that are no longer used in the code.
- a tool that generates dummy test locale which enables the developer to visually find hardcoded strings
We want to make the whole environment project independent by allowing each project to define how process like bootstrapping, extracting should exactly work, where the l10n resources are stored and others.
The first set of tools will be aimed to help localizers, then we’ll work on tools for release managers and developers will come after that.
We’re in the process of writing API’s and designing the syntax for those commands. You can find the document with a proposal and the current source code here.