Copyright © 1995-2011 Opera Software ASA. All rights reserved. This file is part of the Opera web browser. It may not be distributed under any circumstances.
This document lists the procedures for localization requests. For circulation within the Documenation and Localization Departments exclusively.
Translations for every project, product and platform are kept in one PO file per language. There are a few exceptions
to this rule however: Mac languages have their own PO files as do one or two projects such as Chameleon.
The Translation Module (GIT) houses the current PO files used by developers. These PO files
should always be 100% translated or as close to as possible.
We have a second external repository (SVN) for translators. Here the "translations in progress" are kept.
When projects request new string translations or change existing strings, the changes are updated in the SVN
PO files for translators to access.
Once updates are complete in SVN the PO files are transferred to GIT.
If agency updates are required rather than volunteer updates, the PO files are sent directly to the agency; SVN is not used.
It is important to remember that any changes, from bug reports for example, must be replicated in both GIT
and SVN PO files. If changes are only made to GIT when you next update GIT with SVN PO files these changes
will be overriden.
We source our translations via:
List of volunteer languages (and contact details)
And our two vendors: SDL and Moravia.
List of agency maintained languages
Before new project updates begin, often the first question is: what is the translation status for this project for X languages?
Once you have established which file generation method they wish to use (see Project Updates) the files can be generated
using the multiupdate.pl script.
PO files for localization updates are generated using one of two methods: a scope list or build.strings.
The PM should specify which method they prefer, providing a build.strings list if this method is chosen.
At this point it is advised to ask PMs if all strings for the project have been submitted in the english.db and if a "string freeze" is in place to avoid last minute additions.
PMs should also provide:
Once the specifics of the project are finalized you must decide to whom the translation will be outsourced, agency or volunteers, based on customer request and volunteer availability.
See multiupdate.pl to generate project PO files or use those already created in Translation Status.
SVN PO files must be updated with the new project strings. See repoupdate.pl for instructions.
After generating PO files (see Translation Status) run pocount for PO word count. As a
rough guide, multiply the word count by 2NOK. This amount includes VAT and agency admin fees.
Once the initial estimate quote is approved and the go-ahead is given by PMs, send job to agency. Be sure to include the project ERP code as it will be included on the quote and invoice.
After you have given the job to the agency they will sent a quote. This must be forwarded to PMs for approval; once given, give the agency the all clear to begin job.
Our "old" volunteers, those who joined the localization team before 2008, are paid for their work. The amount is always fixed and is not based on word count but rather the general "size" of the project. For example, desktop 11.50 UI: 2000 NOK and desktop 11.50 help files: 1000 NOK. This was a very small update.
List of paid volunteer languages
All new translators, those who joined after 2008, are unpaid, true volunteers.
The translations module provides the following scripts.
To see a full list of command line parameters for each script, please pass
a command line of -? or --help.
The scripts are written in
Perl.
On some platforms, you may need to explicitly state this when running the
script from the command line, by starting the command line with the word
perl.
Tip: Before running any scripts there is one golden rule:
multiupdate.pl
Multiupdate.pl is used to generate PO files for specific projects.
Command
Using scopes list:
multiupdate.pl -i scopes-list/scopes_(required scope list) [languages needed, code only i.e. de id it nl]
For example:
multiupdate.pl -i scopes-list/scopes_desktop_only.txt be bg cs da de
Using build.strings list:
multiupdate.pl -b build.strings [languages needed, code only i.e. de id it nl]
For example:
multiupdate.pl -b build.strings be bg cs da de
repoupdate.plThis script is used to update GIT with the latest SVN translations and SVN with latest english.db version; and module releases.
Command
repoupdate.pl -ia scopes.txt [active language list in txt file]
sjoin.pl
This script is used to join two translations for the same language
into one PO file. The script takes three parameters, the two
PO files to join and a POfile to create with
the resulting data. Mainly used for returned agency updates.
If there are any conflicts, i.e different translations, the translation file that was specified first on the command line takes precedence.
Any empty and fuzzy strings are discarded.
The order of strings is not kept.
Command
sjoin.pl [1st PO (favored)] [2nd PO (usually language main PO)]
[output PO]
makepot.pl
This script writes a translation template to the file
en/opera.pot based on the currently checked out version of
the string database (english.db).
This file, en/opera.pot, is used as the template for new
language.
It is not checked in to GIT.
makepot.pl -i [scopes-list] or -b [build.strings]
Before passing this file onto translators or agency, be sure to make it a PO first by simply changing the extension to .po.
makelang.pl from the
strings module.
You need both the source trees checked out to use this script.
Steps for module release:
pochecker.pl on CVS and SVN PO files - just those files that have active translators
PO files, see repoupdate.pl. Script also updates SVN files with latest english.db version.
pochecker.pl on updated SVN files; commit if all OK
pochecker.pl on updated CVS files. Remove not up-to-date files, commit rest
lngtest (Opera utility)This program creates a simple LNG file suitable for testing, containing all the strings in the PO file submitted on the command line.
kbabel (part of KDE)Kbabel is a GUI program for KDE that allows easy editing of PO files, and it can be used if editing the .po files directly feels to cumbersome.
gtranslator (part of Gnome)Gtranslator is similar to kbabel, but uses the Gnome UI.