commit access
Bjoern Voigt
bjoern at cs.tu-berlin.de
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 pidgin.im 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:300
#: ../finch/gntblist.c:433 ../finch/gntblist.c:446
../finch/gntplugin.c:187
#: ../finch/gntplugin.c:235 ../finch/gntstatus.c:301
../finch/gntstatus.c:310
#: ../finch/plugins/gntclipboard.c:115
../finch/plugins/gntclipboard.c:121
#: ../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:57
#: ../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
minimum.
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.
Greetings,
Björn
More information about the Translators
mailing list