NLS

From PostgreSQL wiki
Jump to navigationJump to search

PostgreSQL National Language Support

This page contains some information about the PostgreSQL National Language Support effort. Please read the information about NLS in the PostgreSQL Documentation for background and technical information. Some of the information on this page may eventually be migrated there as it stabilizes. There's also the GNU Gettext Manual, which is only partially relevant for us, but it might be good to look at anyway.

Status

The status tables shows which areas of the PostgreSQL source are prepared for translation, and the progress of those translations. There you can also download freshly baked PO files that are merged up against the latest program sources. No PostgreSQL source tree is needed for translation work.

Communicating

If you have any questions about the PostgreSQL translation project, including

  • you want to start a new translation or continue an existing one and you want to avoid duplicating your work with someone else,
  • you're looking for other people who want to work with you on translating,
  • you're having technical questions about tools, the source tree, the meaning of terms, etc., then write to the mailing list mailto:pgsql-translators@lists.postgresql.org (you might want to subscribe.)

You can peruse the archive of pgsql-translators.

Howto

Here is how to get set up for translation work. It is assumed here that you already know your way around gettext message catalogs. If you're new to this, read the chapter on NLS in the PostgreSQL Documentation.

Translating

  1. To continue an existing translation, download a new PO file by following the links in the status tables. Fill in the file as much as you want.
  2. To start a new translation, download a POT file by clicking on one of the catalog names in the left column of the status tables. First, fill in all the fields in the header and remove the fuzzy flag. Particularly, the character set information is very important and must not be left out! Then fill in the rest of the file as much as you want.
  3. When you are done editing, check the file for errors. If you're using the Emacs PO mode, press V. From the command line, run msgfmt -o /dev/null -v -c yourfile.po. Or copy the file into the main PostgreSQL source tree and run gmake maintainer-check-po. If you don't do this, your file might contain bugs that cause program crashes, which will quickly disenchant users from PostgreSQL and internationalized software in general.
  4. Submit the resulting file to the Patch Tracker. Please observe the following guidelines about issue submissions, to make it easiest for the person handling your submission:
    • Do not send patches; send the whole file.
    • The files should be named something like postgres-de.po or pg_dump-fr.po, not just de.po or fr.po. Those are the same names as you download them from the status page, so just keep those names.
    • If you are sending multiple files, create several attachments to the same issue.
    • Specify in the issue which branch your file is for (see below about branches). Preferrably, create separate issues for submissions to multiple branches. (That keeps the file names in the attachments separate.)
  5. One of the registered developers will install your file into the source code repository. People who have contributed for a while will be registered as developers and are able to commit their files into the source code repository by themselves.

Tools

Please don't edit the PO files with a plain text editor. You're making your life unnecessarily hard. There are several tools that make editing PO files really easy.

  • Emacs has a PO editing mode.
  • KBabel is for those who like KDE-based tools.
  • Poedit is yet another tool, which even works under Windows

Team Building

If you are new, please check on the status tables whether your language is already being worked on. If so, look into the translation files near the top to find out where to contact the last translator or the translation team. Please contact them about contributing. If the last translator cannot be reached or if it has been a long time since the last update to the file, you can just take over. But remember that communicating first avoids duplicate work later.

Tips

Check out the home of the GNU Translation Project. There you can find out about mailing lists, web sites, and other resources for translation efforts to your language. Some of these resources are GNU-oriented, but others are not.

There is a git repository with the current status of the translations.

Release Management

You can work in several branches. There is a current branch and several back branches.

The back branches belong to past releases of PostgreSQL. It is usually a good idea to finish translations for the recent back branches first, because those are the ones that people currently use. When a new back branch release is made (something like 9.6.5 or 10.1), updated translations will be included.

By contrast, the current branch is often under heavy development, meaning that error messages change, and translation work done today might become obsolete tomorrow. Therefore, translations in the current branch should normally only be done during the beta phase or after a release if no new branch for the development release has been made yet. (The status page informs about the status of the branches.)

Information about release schedules and so on will also be posted to the mailing list mailto:pgsql-translators@postgresql.org (see its archive), which you are encouraged to read.

Minimum Translation

A PO file must have at least 80% of its strings translated before it is considered for inclusion in a PostgreSQL major release. This is to prevent presenting users with a strange mix of English and non-English messages. This criterion will be regularly evaluated in the time before a major release, in particular during the beta phase. Files that do not meet this criterion will not be included or removed if they have previously been included.

If a file drops below the threshold after the major release during the maintenance period of a branch, it will not be removed because of that.