NLS changes

On Sun, Sep 14, 2003 at 02:14:22AM -0400, Alvaro Herrera wrote:

- adds .y files to gettext-files in backend/nls.mk. gram.y contains
several translatable messages that are not catched by update-po unless
the gram.c file is generated. I don't know if this is desirable but I
think it's better to have to gram.y file processed.
Maybe this part of the patch could be left out (it's the first,
trivial chunk).

I just realized that scan.l should also be included, because there are
four or five strings in there. But maybe the pot should instead be
generated on a non-clean tree so those strings are extracted from the .c
files? I downloaded the postgres.pot file from
http://developer.postgresql.org/~petere/ and those strings are not
included there.

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Tiene valor aquel que admite que es un cobarde" (Fernandel)

Alvaro Herrera <alvherre@dcc.uchile.cl> writes:

- makes more translator-friendly the messages in gram.y, because a lot
of them are only a keyword away of being equal. This avoids having
the translator process the same thing several times.

Hm, I deliberately left those the way they were on the basis of the
advice in the NLS documentation: avoid assembling sentences out of
fragments. Now I can see that the type names involved in these things
might be considered untranslatable, but could there be any problems
with, say, gender matching in some languages?

As an active translator, you probably have a better feel for this than
I do, but I just wanted to point out that there was *some* thought
behind doing it this way. I'm fine with changing it if other
translators agree it's better.

regards, tom lane

Alvaro Herrera <alvherre@dcc.uchile.cl> writes:

I just realized that scan.l should also be included, because there are
four or five strings in there. But maybe the pot should instead be
generated on a non-clean tree so those strings are extracted from the .c
files? I downloaded the postgres.pot file from
http://developer.postgresql.org/~petere/ and those strings are not
included there.

Does seem like a problem. plpgsql's .y and .l files need to be
considered also, and I think there are some ereports in guc-file.l.

Peter, which way do you want to fix it?

regards, tom lane

Tom Lane writes:

Hm, I deliberately left those the way they were on the basis of the
advice in the NLS documentation: avoid assembling sentences out of
fragments. Now I can see that the type names involved in these things
might be considered untranslatable, but could there be any problems
with, say, gender matching in some languages?

I doubt that. You could always translate them as if the orignal had been
"precision of type %s needs to be xyz". Languages that cannot handle that
without knowing the value of %s are going to have more problems than this.
(I know there are some languages where this is in fact a problem, but none
of them are likely to start a PostgreSQL translation project in the next
few weeks. ;-) )

--
Peter Eisentraut peter_e@gmx.net

Tom Lane writes:

plpgsql's .y and .l files need to be considered also

Translation of loadable modules is completely unchartered territory. If
someone wants to provide patches to include the strings of some PLs into
the backend catalog for now, I won't object, but in the future we need a
better plan.

--
Peter Eisentraut peter_e@gmx.net

Peter Eisentraut <peter_e@gmx.net> writes:

Tom Lane writes:

plpgsql's .y and .l files need to be considered also

Translation of loadable modules is completely unchartered territory. If
someone wants to provide patches to include the strings of some PLs into
the backend catalog for now, I won't object, but in the future we need a
better plan.

Agreed, in the long run it would be good for loadable modules to be able
to supply their own message catalogs. In the short run, that isn't
going to happen, so what are the odds of including src/pl (or at least
src/pl/plpgsql) in the set of files scanned to make the backend catalog?

regards, tom lane

Alvaro Herrera writes:

- adds .y files to gettext-files in backend/nls.mk. gram.y contains
several translatable messages that are not catched by update-po unless
the gram.c file is generated. I don't know if this is desirable but I
think it's better to have to gram.y file processed.
Maybe this part of the patch could be left out (it's the first,
trivial chunk).

It's better to make the distprep target a prerequisite of the "find" rule,
so that it really finds all the files in their final form. There are some
circular dependencies that I'll need to sort out. Consider it taken care
of, though.

- makes more translator-friendly the messages in gram.y, because a lot
of them are only a keyword away of being equal. This avoids having
the translator process the same thing several times.

Looks OK.

- adds a couple of comments for the translator (I had to peek at the
source code to see what the %s was about, so I guess this is needed).

OK.

Also, I've noted that psql's \h messages are not translatable. Is there
a way to make them so?

Yes, I was just about to do that.

--
Peter Eisentraut peter_e@gmx.net

Applied by Peter.

---------------------------------------------------------------------------

Alvaro Herrera wrote:

Patchers,

Here is a patch related to NLS that

- adds .y files to gettext-files in backend/nls.mk. gram.y contains
several translatable messages that are not catched by update-po unless
the gram.c file is generated. I don't know if this is desirable but I
think it's better to have to gram.y file processed.
Maybe this part of the patch could be left out (it's the first,
trivial chunk).

- makes more translator-friendly the messages in gram.y, because a lot
of them are only a keyword away of being equal. This avoids having
the translator process the same thing several times.

- adds a couple of comments for the translator (I had to peek at the
source code to see what the %s was about, so I guess this is needed).

Also, I've noted that psql's \h messages are not translatable. Is there
a way to make them so?

I have the backend messages almost done:

$ LANG= msgfmt -c -v es.po
1757 translated messages, 29 untranslated messages.

I'll submit after I resolve a couple of translations that are not clear.

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"La victoria es para quien se atreve a estar solo"

[ Attachment, skipping... ]

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073