# Localization Procedures

## Introduction

This document lists the procedures for localization requests. For circulation within the Documenation and Localization Departments exclusively.

### Version Control Repositories

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.

### Translation Resources

We source our translations via:

- Volunteer and freelance translators
- Translation agencies
- Internal employees (primarily for emergencies only)

At present, we have approximately 35 volunteer and freelance translators. Each are sole translators for their language, translating all Opera products.

List of volunteer languages (and contact details)

And our two vendors: SDL and Moravia.

List of agency maintained languages

## Most Common Requests

### Translation Status

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.

### Project Updates

`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:

- Project ERP code, for billing purposes
- Target languages
- Deadline

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.

#### Agency

See multiupdate.pl to generate project `PO` files or use those already created in Translation Status.

#### Volunteers

SVN `PO` files must be updated with the new project strings. See repoupdate.pl for instructions.

### Translation Quotes

#### Agency

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.

#### Volunteer

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.

## Utility Scripts for Translations

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:

- Update repository(s) BEFORE beginning

### `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.pl`

This 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 `PO`file 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.

Command

`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.

Note: This script is just a wrapper around `makelang.pl` from the strings module. You need both the source trees checked out to use this script.

## Module Releases

Steps for module release:

- Update CVS, (Strings and translations module) and SVN
- Run `pochecker.pl` on CVS and SVN `PO` files - just those files that have active translators
- Update CVS with SVN `PO` files, see `repoupdate.pl`. Script also updates SVN files with latest english.db version.
- Run `pochecker.pl` on updated SVN files; commit if all OK
- Run `pochecker.pl` on updated CVS files. Remove not up-to-date files, commit rest
- Edit module.about -> change version tag -> commit
- Tag module. Command: cvs tag [either give specific files or leave blank to tag entire module]
- Add new module. URL: spartan/modules.php
- Go to "Add new module release"
- Module name: Existing module, Translations
- Code Branch: babel_1
- Version tag: enter current tag name
- Core Version: highlight all
- Core notes (optional): Write - 'Tag has not moved'
- Description: updated to dbXXX, general release -- or mention that it is a specific product release.
- Changelog: Go to CVS -> Hit FETCH
- From: old tag (change dates to tag)
- To: new tag
- Format: Compact normal
- Hit SHOW
- Paste changelog in Spartan and clean up
- ADD NEW RELEASE

## Other translator utilities

### `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.

## References

- Strings module
- Locale module