Difference between revisions of "User:JanIversen/jan test"

Revision as of 21:46, 16 October 2012

Introduction

This document is based on and extents Localization_for_developers. The document is work in progress showing the result of a detailed technical analysis of the current process (version 3.4.1) . As such this document should be seen as a replacement of Localization_for_developers.

The l10n process only concerns itself about localizing defined supported languages. Adding a new language is a i18 process. This document is further restricted to the ongoing translation process and closely related build process. In case of external happenings, like e.g. Germany changing rules of spelling, it should be covered with i18 procedures.

The document will hopefully spark a discussion so it can be updated with other views from the ooo-L10n@incubator.apache.org.

It is important to understand the current process before we start discussing detailed changes, so this is the main purpose of this page. Once all the open issues at the end of document have been discussed as solutions agreed upon, a new document will be made describing the process as it should be in the near future.

Thanks to all those persons who contributed to Localization_for_developers that has been a great starting point for this document.

File:L10proc.pdf

Overview

Localization, often abbreviated as l10n, defines the process to make a software package available in local languages, different to the language of the developer.

Localization is from the perspective of the involved person a multi-step process that involves a variety of tools and procedures. Most importantly the 4 main categories of involved persons have quite different and to some extent conflicting views and requirement, therefore the process should be a real “best of all worlds” approach.

The current process is more or less purely developer oriented, contains a lot of different tools and depends a lot on the responsibility of the involved people. It seems to be a process that has grown out of necessity more than a planned road.

Most of the tools used as well as the central data format (SDF) are specific to AOO and not used anywhere else even though both source (c++, resource, UI files) and target (po files) are standard file formats.

Only a part of the workflow are integrated in the build system. Much of it requires manual steps to be taken. Some of the tools involved are not part of the OpenOffice SVN and, due to a hard disk crash of the old pootle server, are lost.

Translations are done with the help of a pootle server. The localization work flow can very short be seen as:

• extraction messages from source files.
• uploading message to the pootle server.
• translating messages on the pootle server.
• downloading messages from the pootle server.
• merging messages into source files.

If you are looking for information about how to contribute translations then Localization gives an overview.

The document has 5 parts:

• a relative non-technical overview of the process,
• a detailed technical overview of the process,
• a detailed technical data flow/storage view,
• a detailed technical view of the tools used with parameters etc,
• an open issues list,

Actors and Systems

The l10n process can and should be viewed with respect to 4 different categories of people who access the process through 2 different systems. The translator consider pootle server to be repository whereas the others consider SVN the main repository.

Note: this view only relates to the l10n procedure, the picture for the whole project is a lot more complex.

The red lighting indicates that the pootle server only works indirectly on the SVN server.

The red lightning indicates that data is being copied:

• to/from pootle server, which requires manual intervention during the build process
• to tester which is quite normal, since a tester normally get an install-set.

Developers

Developers construct the actual program, using dedicated development tools.

Developers will as part of the development process embed messages (errors, warnings …) in the source code and/or build UI. The embedded texts are defined to be in English but the source code are in different programming languages, making extraction a challenge.

Developers are fluent in their language (C++, java, python etc.) but for sure not in all the native languages supported by AOO therefore localization is needed.

Developers uses solely SVN as their repository.

Translators

Translators add texts in the local native language, relating (translating) to the original message. In a release there is a 1-n relation between the original message and the supported languages, where n is the number of supported languages.

Translators does in principle not need to have programming knowledge because in essence they are presented with a list of texts extracted from the source and delivers the translated text back.

Translators work solely with the pootle server which today has no direct connection to SVN but work in parallel with SVN and are updated manually with regular intervals.

Integrators

Integrators initiate and control the build process.

Integrators does in principle not need to have programming or translation knowledge, because they are basically doing administrative tasks.

Testers

Testers check the total system and do a quality assurance of the behavior.

Testers need a deep knowledge of the behavior of the system, but deep technical knowledge is not needed.

Today testing seems to be very limited and not formalized in respect of the l10n process.

System: SVN

The sub version server is the actual repository and ideally all systems should work directly on this server.

All source files, documents etc. are stored in SVN.

System: pootle server

The pootle server provides an environment for translators to work in.

Today the pootle server contains all the translations and are updated from SVN and are as a consequence not synchronized and without version control (during the translation process).

Furthermore many translators work offline without any control.

L10n workflow high altitude view

The workflow seen from the outside is quite simple, but still some of the shortcommings should be very obvious.

The workflow is designed as a waterfall, but one of the good norwegian ones where water is pumped back up at night time. Idealy for each release each section is done only once (waterfall), but in real life two things happen (norwegian night pumping):

• Some sections happens in parallel (e.g. Translators start working with early code)
• Some sections are repeated due to problems found in later sections

This is quite normal and normally not a real problem provided the process is automated and has a number of quality gates.

However the current process there is only a single automated quality gate which are pure technical (solving: “Can the product be built without errors?”) the rest is left to us humans.

The workflow only concentrates on the l10n process which is only a subset of the total lifecycle process.

SVN pootle server