SEO

Hi all,
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.
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.

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 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.

Last problem. The po file includes all strings alphabetically sorted. I 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.

Any comments?

Bye,
Giuseppe

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

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.

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

> 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.

> 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 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.

> Last problem. The po file includes all strings alphabetically sorted. I 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.

I would like to know what other translators think about these issues.

Regards.


--
Guillaume.
<!-- http://abs.traduc.org/
http://lfs.traduc.org/
http://docs.postgresqlfr.org/ -->

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

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

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match