commit access

Bjoern Voigt bjoern at
Fri Nov 2 11:39:30 EDT 2007

Luke Schierer wrote:
> Sean has decided to give translators full commit access, so that you all
> can commit your own translations.  
> Please email your mtn key to elb at  If you need help generating a key, I believe there is
> some information in the wiki.
Thank you. This is good news.

Probably it's important to say, that each commit of an updated 
translation increases the size of the Pidgin-Monotone database. 
Currently my Pidgin Monotone database is 231MByte.

I checked this with the internal Subversion repository for the German 
Pidgin translations where Jochen Kemnade and I synchronize our 
translations. If we update the translation around every 4th day, than 
each single commit was about 150kByte!

The reasons for this relatively big commits come from the design of 
Gettext. Gettext translations contain the original strings, the 
translated strings, the source file names and the line numbers in the 
source file names. While original and translated strings do not change 
so much, line numbers change very often:

For instance the string "Error" and the translation will not change over 
a long time, but the line numbers of the source files can change often.

    #: ../finch/gntaccount.c:124 ../finch/gntaccount.c:484
    #: ../finch/gntblist.c:433 ../finch/gntblist.c:446
    #: ../finch/gntplugin.c:235 ../finch/gntstatus.c:301
    #: ../finch/plugins/gntclipboard.c:115
    #: ../finch/plugins/gntclipboard.c:128
    #: ../libpurple/protocols/jabber/buddy.c:2032
    #: ../libpurple/protocols/jabber/chat.c:677
    #: ../libpurple/protocols/jabber/chat.c:688
    #: ../libpurple/protocols/jabber/jabber.c:1515
    #: ../libpurple/protocols/qq/group_join.c:328
    #: ../libpurple/protocols/qq/im.c:576
    #: ../libpurple/protocols/silc/ops.c:1460
    #: ../libpurple/protocols/silc10/ops.c:1451
    msgid "Error"
    msgstr "Fehler"

I see 3 possible solutions:

   1. If we do not commit too much, the size of the Monotone database
      does not increase so fast. Of course 1 commit per release is a
   2. We can commit as often as we need. But if we use the --no-location
      switch for xgettext. (with Intltool this is: "env
      XGETTEXT_ARGS=--no-location intltool-update XX.po") the commit do
      not get so big.
   3. We can ignore the size problem. Hard disc space is not so
      expensive any more. And the networks are fast too.

I would suggest solution 2. Everybuddy who needs source code locations 
can regenerate them with intltoop-update. Also tar balls should contain 
source code locations. Also diffs without source code locations are 
easier to check, because they are not so big and contain more or less 
only "real" changes. This could be interesting for translation teams.


More information about the Translators mailing list