Latest Turkish translation updates
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
These are the latest updates:
http://postgresql.gunduz.org/translation/PostgreSQL-8.0/PgSQL-DilDosyalari/initdb-tr.po
http://postgresql.gunduz.org/translation/PostgreSQL-8.0/PgSQL-DilDosyalari/pg_config-tr.po
http://postgresql.gunduz.org/translation/PostgreSQL-8.0/PgSQL-DilDosyalari/pg_ctl-tr.po
http://postgresql.gunduz.org/translation/PostgreSQL-8.0/PgSQL-DilDosyalari/pg_dump-tr.po
http://postgresql.gunduz.org/translation/PostgreSQL-8.0/PgSQL-DilDosyalari/postgres-tr.po
http://postgresql.gunduz.org/translation/PostgreSQL-8.0/PgSQL-DilDosyalari/psql-tr.po
BTW... Peter, we see some errors on postgres-tr.po file, on nlsstatus
page
(http://developer.postgresql.org/~petere/nlsstatus/po-current/postgres-tr.po.err)
po/postgres-tr.po:9383: number of format specifiers in msgid and msgstr
does not match
We can't reproduce it with msgfmt -v. How do you get those errors?
Regards,
- --
Devrim GUNDUZ
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.tdmsoft.com http://www.gunduz.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQFB6R/ltl86P3SPfQ4RAlB9AKCeg25NvhQlnYeT8YG/ZuDI16o1JACgxTRK
A+52hU+WAZ0KQTK8U4q9wTc=
=uvlT
-----END PGP SIGNATURE-----
Devrim GUNDUZ wrote:
These are the latest updates:
Installed.
BTW... Peter, we see some errors on postgres-tr.po file, on nlsstatus
page
(http://developer.postgresql.org/~petere/nlsstatus/po-current/postgre
s-tr.po.err) po/postgres-tr.po:9383: number of format specifiers in
msgid and msgstr does not matchWe can't reproduce it with msgfmt -v. How do you get those errors?
The scripts that produce these tables do not use the standard gettext
tools; they use hand-crafted Perl scripts. In some cases, these catch
more errors. In all cases that I have analyzed further, this was
because %m was not identified as a format specifier by msgfmt.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
Wow,
Turkish seem to be the first translation to report 100% translation
completion for 8.0 release. Congratulations for great work! And thanks
to Peter for being patient with us all this time.
We can't reproduce it with msgfmt -v. How do you get those errors?
The scripts that produce these tables do not use the standard gettext
tools; they use hand-crafted Perl scripts. In some cases, these catch
more errors. In all cases that I have analyzed further, this was
because %m was not identified as a format specifier by msgfmt.
Could you share these scripts with us? Many update submissions
we made were beacause of these %m errors.
Also would it be easier to you Peter if we give you login to our CVS
poject (on sf.net) so that you just run "cvs up" every time
you package a new update and not bother with emails.
Thank you all folks for your efforts.
I will open a bottle of chamgne tonight to celebrate 8.0.
Peter Eisentraut
http://developer.postgresql.org/~petere/
Best regards,
Nicolai Tufar
On Mon, Jan 17, 2005 at 01:40:40PM +0200, Nicolai Tufar wrote:
Wow,
Turkish seem to be the first translation to report 100% translation
completion for 8.0 release. Congratulations for great work! And thanks
to Peter for being patient with us all this time.
There were several on 100% until some more messages were marked for
translation. Doing that days before release was not a good idea IMO.
Also would it be easier to you Peter if we give you login to our CVS
poject (on sf.net) so that you just run "cvs up" every time
you package a new update and not bother with emails.
Maybe we should have a pgfoundry project where all translations were
kept, and from which the main CVS could be updated semi-automatically.
Then we wouldn't have Peter checking out and committing all the time.
--
Alvaro Herrera (<alvherre[@]dcc.uchile.cl>)
"Et put se mouve" (Galileo Galilei)
Alvaro Herrera wrote:
There were several on 100% until some more messages were marked for
translation. Doing that days before release was not a good idea IMO.
Yeah, I though so too, but if you think about it, it doesn't harm anyone
except your statistics. :)
Maybe we should have a pgfoundry project where all translations were
kept, and from which the main CVS could be updated
semi-automatically. Then we wouldn't have Peter checking out and
committing all the time.
That sounds like a fine idea. My only concern would be the
"not-maintained-here" syndrome, which occurs every time some CVS tree
contains a file that is actually maintained by an external group, thus
blocking the maintainers of the former CVS tree from applying necessary
fixes at times. Nevertheless, I think this is a winner. Let's
consider it when we start the 8.1 cycle.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
Alvaro Herrera wrote:
Maybe we should have a pgfoundry project where all translations were
kept, and from which the main CVS could be updated
semi-automatically. Then we wouldn't have Peter checking out and
committing all the time.Peter Eisentraut wrote:
That sounds like a fine idea. My only concern would be the
"not-maintained-here" syndrome, which occurs every time some CVS tree
contains a file that is actually maintained by an external group, thus
blocking the maintainers of the former CVS tree from applying necessary
fixes at times. Nevertheless, I think this is a winner. Let's
consider it when we start the 8.1 cycle.
It is definitely a winner. And I don't think anyonwone from
core group will object since Peter will be the only one who updates
main CVS tree. Just appoint a maintainer or two with cvs commit
priveleges for each language. It will ease your routine workload greatly.
Best regards,
Nicolai
Peter Eisentraut wrote:
Maybe we should have a pgfoundry project where all translations
were kept, and from which the main CVS could be updated
semi-automatically. Then we wouldn't have Peter checking out and
committing all the time.That sounds like a fine idea. My only concern would be the
"not-maintained-here" syndrome, which occurs every time some CVS tree
contains a file that is actually maintained by an external group,
thus blocking the maintainers of the former CVS tree from applying
necessary fixes at times. Nevertheless, I think this is a winner.
Let's consider it when we start the 8.1 cycle.
OK, is anyone opposed to this idea? I would register a pgfoundry
project (name suggestions? "translations"?), give most established
translators commit access, and move the statistics pages there. Also,
some translation groups seem to have their own mailing lists or web
pages, which could optionally also be hosted there.
We could then sync the translations either regularly (e.g., once a week)
or only at release time. Of course we would need to mirror all the
branches there.
Comments?
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
On Thu, Jan 20, 2005 at 02:08:20PM +0100, Peter Eisentraut wrote:
Peter Eisentraut wrote:
Maybe we should have a pgfoundry project where all translations
were kept, and from which the main CVS could be updated
semi-automatically. Then we wouldn't have Peter checking out and
committing all the time.That sounds like a fine idea. My only concern would be the
"not-maintained-here" syndrome, which occurs every time some CVS tree
contains a file that is actually maintained by an external group,
thus blocking the maintainers of the former CVS tree from applying
necessary fixes at times. Nevertheless, I think this is a winner.
Let's consider it when we start the 8.1 cycle.OK, is anyone opposed to this idea? I would register a pgfoundry
project (name suggestions? "translations"?), give most established
translators commit access, and move the statistics pages there.
Sounds good. Maybe the name is too generic; what about
"server translations", or something like that?
--
Alvaro Herrera (<alvherre[@]dcc.uchile.cl>)
"�C�mo puedes confiar en algo que pagas y que no ves,
y no confiar en algo que te dan y te lo muestran?" (Germ�n Poo)
Hi Peter,
Peter Eisentraut wrote:
Maybe we should have a pgfoundry project where all translations
were kept, and from which the main CVS could be updated
semi-automatically. Then we wouldn't have Peter checking out and
committing all the time.That sounds like a fine idea. My only concern would be the
"not-maintained-here" syndrome, which occurs every time some CVS
tree
contains a file that is actually maintained by an external group,
thus blocking the maintainers of the former CVS tree from applying
necessary fixes at times. Nevertheless, I think this is a winner.
Let's consider it when we start the 8.1 cycle.OK, is anyone opposed to this idea? I would register a pgfoundry
project (name suggestions? "translations"?), give most established
translators commit access, and move the statistics pages there.
Also,
some translation groups seem to have their own mailing lists or web
pages, which could optionally also be hosted there.
Great idea. Name? maybe 'pgtranslation'.
We could then sync the translations either regularly (e.g., once a
week)
or only at release time. Of course we would need to mirror all the
branches there.
Maybe the sync could be made every time someone changed the version of
the po, ie, commit it (some script can handle this stuff). It'll
reduce the number of unnecessary commits.
=====
Euler Taveira de Oliveira
euler[at]yahoo_com_br
__________________________________________________
Converse com seus amigos em tempo real com o Yahoo! Messenger
http://br.download.yahoo.com/messenger/
Import Notes
Resolved by subject fallback
On Thu, 20 Jan 2005 14:08:20 +0100, Peter Eisentraut <peter_e@gmx.net> wrote:
Peter Eisentraut wrote:
Maybe we should have a pgfoundry project where all translations
were kept, and from which the main CVS could be updated
semi-automatically. Then we wouldn't have Peter checking out and
committing all the time.That sounds like a fine idea. My only concern would be the
"not-maintained-here" syndrome, which occurs every time some CVS tree
contains a file that is actually maintained by an external group,
thus blocking the maintainers of the former CVS tree from applying
necessary fixes at times. Nevertheless, I think this is a winner.
Let's consider it when we start the 8.1 cycle.OK, is anyone opposed to this idea? I would register a pgfoundry
project (name suggestions? "translations"?), give most established
translators commit access, and move the statistics pages there. Also,
some translation groups seem to have their own mailing lists or web
pages, which could optionally also be hosted there.We could then sync the translations either regularly (e.g., once a week)
or only at release time. Of course we would need to mirror all the
branches there.Comments?
Perfectly fine. Please go ahead.
--
Peter Eisentraut
Nicolai Tufar
Turkish Language Translation Team.