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 accomplish its purposes, 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 that API will be the command-line based environment for l20n.
For this toolchain, we have three personas in mind:
- a localizer
- release driver
Initially we want to provide four elements that will enable all of the above:
- a on-demand, activated, shell prompt customization that will provide contextual information while the localizer navigates around their l10n project,
- a bootstrap command that will help initialize a new localization sandbox for a project,
- a set of diagnosis tools like a validator, completion check, and localization status, all of which will analyze the localization project and provide detailed information on what remains for the it to be completed,
- an automated update tool that will help localizers keep the localization structure in shape, helping adding new strings, removing obsolete strings, and providing information on updated strings.
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 lose the ability to review changes made by localizers in the VCS history view if we apply changes that the localizer did not work on. Or we can hide the contextual information from the localizer by removing entities whose value has been reused in a new entity (added just next to the old one), despite the entities becoming obsolete.
All this kind of stuff has to be taken into account. We want to aim for a balance between simplifying day-to-day localization work, maintaining VCS friendliness, and the sense of control that a localizer must have over their localization project.
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 the following:
- a custom shell prompt that will aid release drivers while they navigate between localization projects,
- scripts that will make it easy to analyze the status of localization projects and validate them,
- tools that will allow release drivers to maintain the list of locales and their version, to be released with a given version of the product.
For developers, we want to make sure that it’s easy to make their code localizable and maintain it that way.
This means that we want to make it easy to spot hardcoded strings, add new entities manually, verify that they work with tests, and extract entities from code where possible (like – XML).
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 developers clean l10n files by removing strings that are no longer used in the code.
- a tool that generates a dummy test locale, enabling developers to visually find hard-coded strings.
We want to make the whole environment project independent by allowing each project to define how processes, like bootstrapping and extracting, should exactly work, where the l10n resources are stored, etc.
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.
To join in on the discussion, talk to us on the mozilla.dev.l10n newsgroup.