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 Toolkit
It is now time to install the Translate Toolkit 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 Toolkit.
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.
In order to create, an OpenOffice file, you also need to indicate what will the the locale for the transaltion you are doing. You must include in the command the name fo the locale for which you are translating.
po2oo -i <folder-with-po-files> -t en-US.sdf -o <name-of-GSI-format-file> -l <Locale-name>
In our example, as we are translating for Khmer, this could look like:
/dev/tools/po2oo -i po -t en-US.sdf -o oo-2.0-km-GSI.sdf -l km
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.
扫一扫
467
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
