Re: How to easy the translation process

From: Dave Page <dpage(at)postgresql(dot)org>
To: Guillaume Lelarge <guillaume(at)lelarge(dot)info>
Cc: Giuseppe Sacco <giuseppe(at)eppesuigoccas(dot)homedns(dot)org>, pgadmin-hackers(at)postgresql(dot)org
Subject: Re: How to easy the translation process
Date: 2007-07-19 08:40:44
Message-ID: 469F238C.4090600@postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgadmin-hackers

Guillaume Lelarge wrote:
> Giuseppe Sacco a écrit :
>> as a translator I find quite uncomfortable some part of the pgadmin3
>> release process. I would like to discuss if others share these
>> problems, and eventually fix them.
>>
>> The first problem is related to the stringmerge utility. Every time
>> source code is updated, with changes in strings, a manual invocation
>> of stringmerge is required. It happens that people forget it, so I
>> have to use stringmerge every time I need to update my translation.
>> I think that merging strings could be done automatically via Makefile,
>> at build time.
>
> Our current process is to update the strings when we think strings won't
> change much before release.
>
> I don't understand in which way stringmerge is related with your build
> process. Using make allows you to build the "new" pgadmin and that
> allows you to run it to check your translation. At this time, you should
> have already translated your .po file and using stringmerge won't help you.

We have intentionally de-coupled the merge & build processes:

- Virtually all translators are not developers and don't have a build
environment for pgAdmin.

- Automatically merging every time we rebuild during development would
slow down our work a huge amount.

- We only merge when we think strings are relatively stable. There are
time when, for example, I'm actively developing code and know that I'm
likely to be changing things before release. In previous releases that
meant we would only merge at feature freeze. In this release, Guillaume
has been experimenting with a more incremental approach where we've
merged occasionally during the development phase at certain milestones.

>
> But I would understand that you would like it to build pgadmin3.mo if
> your tool doesn't build it.

poEdit certainly will compile when you save if appropriately configured.

>> Updating all translations on SVN, as the current stringmerge does,
>> is useless since it just add a lot of SVN changes and commit for
>> files that still have to be translated.
>
> stringmerge help us to have statistics on the web page because it
> commits merge po files on SVN. Statistics help translators to understand
> if they still have a lot of work to do.

Exactly. And the extra SVN commit does nothing except give us an extra
point in time to roll back to if a problem is introduced.

>> Another problem with the build process is that when I change my
>> pgadmin3.po, it is not automatically compiled to .mo. This is
>> another step that could be done automatically in i18n/Makefile.
>
> I kind of agree on this one. If you want to check your translation
> before sending it to me, you need to build the .mo with msgfmt or
> another tool. We can tell the Makefile to build every .mo file which is
> not updated.

I'm happy to accept a patch to handle this.

>> I also feel a need for a string freeze period before any release.
>> I am used to update my translations on other projects while
>> developers do not change strings. Without a string freeze is very
>> difficult to keep translations update and in sync.
>
> We use feature freeze as our string freeze. They aren't totally frozen,
> they can change but we do our best not to.

Yes - the problem tends to be that translators find typos etc. in the
English versions.

>> Last problem. The po file includes all strings alphabetically sorted.
>> find very handy to have these strings not sorted; what I would need
>> is it to keep closer strings that are next in the source code. The
>> reason is that very often strings are related the same subject
>> and should be translated using the same words.
>
> I understand your problem but I don't see them sorted. They seem to be
> sorted by source file but when one string is available on two or more
> source files, they can't be at different places on the .po file.

We do seem to be using xgettext's -s option to sort the output. I didn't
set that up (Andreas, our first translator did), but if the concencus
among the translators is that that should be changed, I'm happy for it
to happen.

Regards, Dave

In response to

Browse pgadmin-hackers by date

  From Date Subject
Next Message Erwin Brandstetter 2007-07-19 12:47:41 Option to turn auto-indentation off?
Previous Message svn 2007-07-19 07:40:50 SVN Commit by hiroshi: r6457 - trunk/pgadmin3/i18n/ja_JP