Thread: NLS changes
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
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