Of the
OpenOffice software itself
(messages)
The
translation of the OpenOffice software can be easily
done using simple specialized translation editors that
are also Open Source. Learning how to use one of these
editors should not take more than half a
hour.
The
translation can be equally done in either the Linux or
the MS Windows environments.
The
messages that appear different parts of OpenOffice
(menus, screens, error messages) have been extracted
from the source and placed in files that are easy to
handle and to translate. These files are called "PO
files" and their format is used for the translation of
many Open Source applications.
A
PO file is just an structured list of messages that
contains, for each message, the English original
message text (msgid) and the translation to the target
language (or an empty string that will be filled by
somebody with the translation of the message). If the
file still does not have any translations (all the
translated string are empty), it is called a PO
template file, and usually given the .POT extension,
instead of the traditional .PO extension of PO files.
Once a translator starts to translate a .POT file, he
will save it with the .PO extension. PO are text files
in UTF-8 format, so they can also be seen and modified
with a normal text editor that can handle UTF-8 format
(most text editors can).
But let's start
from the beginning, step-by-step.
1) You need to know
exactly what version of OpenOffice you want to
translate.
If you are not sure about what version to
translate, it is always a good idea to ask in the
dev@l10n.openoffice.org
mailing list. Most often you will translate the
latest stable version of the program.
An exception of this rule is when there is a new
important milestone coming soon, in which case you
will have to translate the upcoming version. For
example, at the time this document is written,
version 2.0 of OpenOffice is expected within the next
four to six months, and it is no longer interesting
to attempt translation of a 1.1x version, even if
they are the last stable versions.
If the inclusion of your language in OpenOffice
requires changes in the code (patches, locale file,
etc.), you will have to work towards the next version
that will be released within the branch that you want
to translate. For example, if the last released
version is 2.1, this means that 2.1 is closed (no
changes can be done for 2.1), so you can only work
towards 2.2, if the necessary changes are integrated
in 2.2. As 2.2 PO files will probably not be
available when you start, you can always translate
the PO files for 2.1, and then, when the PO files for
2.2 become available, you can upgrade to 2.2 (use the
information stored in the 2.1 PO files to
automatically fill the identical messages in the PO
files of 2.2), translate the few additional messages
that there might be in 2.2... and follow the process
explained below.
2)
Get the POT files and the GSI format file for that
version
The file that you need for the translation are
under:
ftp://ftp.linux.cz/pub/localization/OpenOffice.org/devel/
If you point your browser to that address, you
will find a folder for each active branch of
OpenOffice (each active OpenOffice project). Each
branch has a name or number: 645 for version 1.1.x of
OpenOffice and 680 for 2.x. You should get the files
from the folder that correspond to the version that
you want to localize. If you are working on the
latest branch, you should look into the directory
POT. In case of doubt, ask in the list.
In whichever directory you look, you will find at
least two files:
You need to download both of them. For the moment
you do not need the en-US.sdf file, but you will need
it when you finish the translation and need to
convert the PO files to the OpenOffice format. It is
important that - in that process - you use the
version of the en-US.sdf file that is associated to
the POT files that you downloaded. That is why we ask
you to download it, label it and store it now, to
avoid confusion later.
3)
Get a PO file editor, if you do not already have
one.
There are PO editors for both Linux and Windows,
you should use the one that best fits the working
environment of the translators that will be using the
editor.
In Linux the most used PO editor is probably
KBabel,
associated to the KDE user interface (*** REVIEW ***
describe KBabel).
In the Windows environment, poEdit does the job
quite well. Besides being simple and doing everything
that is expected of a PO file editor, it has its own
"translation memory": each time a PO file is saved,
the editor automatically saves all the messages of
that file and their translations in a database (this
database is your translation memory). When you open a
new PO file (normally this happens when you are
upgrading to a new version), you can ask the editor
(just click a button) to search in the translation
memory database for the messages that are in that PO
file, and - if it finds any - to place the
translation in the correct place of the PO
file.
poEdit also runs on Linux, and we do
recommend it as a good tool.
4)
Translate.
Translating the OpenOffice suite is not an easy
task. OpenOffice 2.0 contains roughly 22.000
messages. It is not too far off-the-mark to consider
that it requires a full-time translator for about 12
months to complete the task, given that he has the
right glossary.
Prior to starting the translation of OpenOffice,
you should have a glossary of computer terms
(user-interface terms) for the target language,
otherwise you will be stopping all the time to figure
out specific translations for different terms, and
your translation will be inconsistent, specially if
it is done by several translators working together
(which is a good idea). Besides your computer
terminology glossary, you will also need
mathematical, statistical and accounting
terminologies, to translate many names of functions
used by Calc.
You should consider (depending on your
resources), how many translators you want to assign
to the task of translating the OpenOffice software.
This will depend on the overall task that you set for
yourself. Will you also translate the help? Will you
translate documentation? Training materials? You
should also consider how long you want your
translation to take.
In our experience, in the case of translation
being done professionally, a team of three or four
translators can work very well, having each team
member translate his part and double-check
translations made by another team member. With a
three person team translation of the software can be
accomplished in four months (of course it can be
three or five, depending on speed, enthusiasm and the
quality of the glossary, but four is a good
reference to start with).
You should also develop translation guidelines
for translators, regarding length of messages, how
you should translate certain things, how to deal with
variables, etc. (*** REVIEW*** talk some more about
OpenOffice variables here)
5)
Installation of Translate Project
tools
It is now time to install the Translate
Project tools in your computer (either Linux or
Windows). These tools are used to check your messages
and to convert your PO files pack to a format that is
clearly understood by the OpenOffice
software.
(*** REVIEW *** installation of PO
tools)
6)
Check your PO files
Once you have finished translating and made a
back-up copy of your PO files, it is a good idea to
check if the are correct is some technical aspects,
such as making sure that if a given variable is in
the original string, the same variable is also in the
translation, or that if some message starts or
finishes with a blank space, so that the translation,
having similar capitalizations in original and
translation (for scripts that have capital letters),
etc...
The checking process consists on checking your
translated PO files for inconsistencies or possible
problems, filter to new files all the problematic
translations, work on them, and then merge them back
into the original files. As complicated as this might
sound, it is quite simple, by using the Translate
Project tools.
a) Filtering
The tool from the Translate Project that does
this check is called POFILTER, and it should
be used from the console (Linux) or from the command
prompt (Windows). We assume that you have followed
the instructions in the prior section and that the PO
tools correctly installed in your
computer.
POFILTER analyses a whole tree of PO files,
searching for possible errors and problems in the PO
files one by one. It creates as output another tree,
identical in structure to the tree in which your PO
files are, and in this new tree, in the same place
that the original PO files in the first tree, it
creates PO files in which only problematic messages
are included. For example:
-
If in your PO file tree you have a file
called po/sfx2/source/menu.po, and that file has
a problem in one of the message.
-
And you run POFILTER, specifying "checks" are
your output tree.
-
A file with path checks/sfx2/source/menu.po
will be created, which will include only messages
from the file po/sfx2/source/menu.po which
POFILTER considers that you should check again by
hand.
In order to run POFILTER, you should use in the
command line the following syntax:
pofilter --openoffice <your-po-file-tree>
<tree-where-checks-will-be-stored>
Of course, we assume that the pofilter
program is in your path or that you write the whole
path for it. For example, as in the case above, all
your files are in a directory called po, and
you want the output to go to a directory called
checks, and (for this particular example) we
assume that you are working on Windows and that your
Translate Project tools are in the \dev\tools\
directory, you should use the command:
\dev\tools\pofilter --openoffice
po checks
Sometimes - depending on your language - POFILTER
can give you a lot of false positives (find as
possible errors translations that are correct).
POFILTER, for example checks by default if
capitalization in the original and in the translation
is similar. This - of course - does not apply to
Indic languages, which have no capital letters. Also,
by default, POFILTER checks if all messages have been
translated. In some cases you might do test or
partial transaltions, so you do want this test
deactivated.
IT is possible to indicate to POFILTER which test
you want to deactivate when using it. The most useful
tests that POFILTER uses are:
·
escapes
- Checks whether escaping is consistent between the
two strings
·
endpunc
- Checks whether punctuation at the end of the
strings match
·
unchanged
- Checks whether a translation is basically identical
to the original string
·
untranslated
- Checks whether a string has been translated at
all
·
variables
- Checks whether variables of various forms are
consistent between the two strings
·
whitespace
- Checks whether white spaces at the beginning and
end of the strings match
To see a complete list of tests, please run
pofilter with the -l option, or go to the
Translate Project Reference Documentation.
(***REVIEW*** must be a link to the
documentation).
The excludefilter option is used in the command
line to exclude specific filter(s). As an example, if
you want to run POFILTER while deactivating the
capitalization check and the check for untranslated
(empty or identical to the original), you should use
the command (following with the same
example):
\dev\tools\pofilter --openoffice
--excludefilter=untranslated
--excludefilter=unchanged --excludefilters=simplecaps
po checks
b) Correct
Once you run POFILTER, you need to use your PO
editor to check all the files that are in the
checks directory, until you are sure that they
are all correct.
c) Merge corrected messages back.
The next step is re-integrate the corrections in
the original PO files. This is done with the
Translate Tool program POMERGE. Before you do it, we
recommend that you make a new back-up copy of your
po and checks directories, then you can
run:
pomerge -i <folder-with-corrected-files> -t
<folder-with-original-incorrect-po-files> -o
<folder-for-corrected-files>
If we use that we have been following, and we
want to just over-write the incorrect files in the
po folder with corrected files, we should use
the command:
\dev\tools\pomerge -i checks -t po -o
po
At this point you can just go ahead, or run again
pofilter, to see if all the problems that you
had detected have disappeared. If pofilter gives new
positives, you have to repeat the whole checking
process again.
7)
Create an OpenOffice file that contains your
translations
Now the files are ready to be converted back to a
format that OOo likes. You can do this conversion
using the po2oo tool from Translate Project .
For this you need to remember were you put the
original en-US.sdf file that you downloaded together
with the PO files, because you need to include the
path to it in the po2oo command.
po2oo -i <folder-with-po-files> -t
en-US.sdf -o
<name-of-GSI-format-file>
In our example, this could look like:
\dev\tools\po2oo -i po -t en-US.sdf -o
oo-2.0-km-GSI.sdf
which would produce as output the file
oo-2.0-km-GSI.sdf, the final product for which
you have been working for all this time, and which
will be integrated in the sources of
OpenOffice.
8)
Create an issue in OpenOffice
Create an issue for the
Localization (L10n) project. To submit an issue you
first need to login into the OpenOffice website, then
hit File Issue on the left hand menu… go
to proceed in the next page… click in
the component l10n in the next one… are
you are ready to file it. Select version
current, subcomponent code, type
ENHANCEMENT, Summary GSI file for
language…., and hit Submit. The
system will ask you if you want to attach a file and
what type. Attach the oo-2.0-km-GSI.sdf file (or whatever you have
called it) and… submit
it. You are done.