Gnome is a Linux graphical desktop environment. The project has quite an
established localisation initiative.
ReadingPlease familiarise yourself with these before proceeding:
* Gnome localisation style guide (These are actually Sun Solaris style guides)
* Localisation Guide
* Localisation section in the developers website
* Gnome Translation Project
Useful URLs* Status Page
* Resources Page
TranslatingThis is a roughly sequential outline of the steps you need to take to translate
Gnome into your language.
Joining the mailing listSubscribe to the gnome-i18n mailing list:
Gnome GlossaryStart with this to create consistency across future Gnome localisations.
Latest versions of the CSV glossary:
Use the csv-to-pot.sh script to convert the .csv to a pot file. The layout is
slightly different from the layout created by po2csv so you cannot convert the
created POT file to a Translate Toolkit style CSV file.
If you need to translate using CSV rather edit the GnomeGlossary.csv and
manipulate it into a PO file later.
What files firstAdvice from Christian Rose on the Gnome team.
gtk+ 1126 (toolkit, very largish, but many messages are
developer-oriented and can safely be ignored to begin with, but some few
messages here are very visible to the end user)
libgnomeui 305 (many user-visible menus and stuff)
gnome-mime-data 350 (user-visible file type desc. etc)
gnome-vfs 80 (file size formatting etc)
yelp 71 (help browser)
gedit 640 (text editor)
nautilus 1449 (file manager, also very largish, but not all
messages here are immediately visible to the end user, even though many are)
gdm2 629 (login manager)
eog 170 (image viewer)
... and then the rest in desktop + developer-libs.
TODO: use podebug to get a better targeting on these files.
Getting a CVS accountYou will need a CVS account to commit translations:
Most probably you will only get one if you have supplied translations already
or are a new team leader.
You will need to read this to ensure that you commit correctly to CVS:
The steps are well laid out and very clear, you can't go wrong if you follow it
carefully. So old time users of CVS you must read it.
Your translated PO files are placed within the package in GNU style, ie in the
po/ directory unlike the KDE system of all languages in one module. This means
that you will have to checkout and add files to the various modules that you
use. Eg to add translations of gnome-mime-data you will need to checkout the
module by that name.
Targeting a releaseGnome follows a regular 6 monthly development cycle with even numbered stable
releases and odd number development releases.
You can see the release schedule here:
If your team is moving quickly it might be good to target a stable minor
release. This will also be the platform that most users will be on. It also
presents the chance to have multiple releases as you move through each minor
Translation Status PageYour languages translation status page at http://l10n-status.gnome.org/ will be
updated as soon as your first file is committed to CVS.
Setting up your Bugzilla ComponentYou need a Bugzilla component so that users of your language can report errors.
Instructions for setting one up are here:
This information courtesy of Christian Rose. You should return these details
to him at: menthos at gnome oeg.
You need to supply:
* language code
* language name (in English)
* language name (spelled in the language itself. We actually don't
use this info in Bugzilla but on the http://www.gnome.org/i18n/
page. Please replace non-ASCII characters with proper HTML escape
sequences. See the HTML source code of that page for examples)
* default owner (must be a valid bugzilla account)
The default owner is the person who should be assigned the bugs by
default. If he or she doesn't have a bugzilla account, he or she can
create one at http://bugzilla.gnome.org/createaccount.cgi.
* default qa contact (must be a valid bugzilla account)
The default QA contact is usually the person who should make sure
the bug was fixed properly by the assignee. If the qa contact person
doesn't yet have a bugzilla account, he or she can create one at
http://bugzilla.gnome.org/createaccount.cgi. This field is optional,
you don't need to decide on a default qa contact if you don't want
* component description
Usually of the form "Here you can place your bugs about
$LANGUAGENAME [$LANGUAGECODE] translations". Example: "Here you can
place your bugs about Swedish [sv] translations".
If you have the possibility, try also to translate this into
ASCII-only English, and we'll use the translation as well.
You have the option of assigning this the bug reports to a mailing list:
If you want, there's also the possibility to use a mailing list instead
of an individual for the default owner and/or default qa contact fields.
It's a bit more complicated; among other things you need access to the
mailing list configuration. Here is what you should do if you want a
mailing list in one or both of the fields above:
1) Create a bugzilla account for your mailing list, i.e. a Bugzilla
account with your list's address as account name.
2) Subscribe the bugzilla deamon address
(email@example.com) to your mailing list, but also
disable *ALL* mail from the mailing list to this address (If it's a
Mailman mailing list you can change firstname.lastname@example.org's
mailing list options to NOMAIL).
Application SpecificThere are some applications that need specific treatment. These are those:
The login manager needs patches to gui/gdmlanguages.c and config/locale.alias to
add your languages. Email your patch to "George"
Suggested bug report and related email for adding English (Canadian), use as a reference:
Also Arabic issue highlights how it all fits together:
Actual CVS diffs to add Afrikaans, Northern Sotho and South African English
Translating Documentation On the Gnomr-i18n mailing list Christian Rose says, "At the moment,
we don't translate documentation the same way we translate the user
interfaces (i.e. with "po" files). However, we hope
to do so at some point, since po files provide several essential
advantages compared to maintaining translations of plain XML. One such
advantage is that it divides documents into smaller pieces (messages),
allowing you to see exactly what parts have an inconsistent translation
and need updating."
"For the moment, what you may want to do is to use the "xml2po" utility
in the "gnome-doc-utils" package/module. This will allow you to
transform the XML/DocBook source of a document into a pot file that you
can translate and maintain. Also, it allows you to reverse the process
and create a translated XML file out of the po file later on."