Re: [PATCHES] NLS changes
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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] NLS changes
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 [EMAIL PROTECTED] ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] 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) ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] NLS changes
Alvaro Herrera [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] NLS changes
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 [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] NLS changes
Alvaro Herrera [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] NLS changes
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 [EMAIL PROTECTED] ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
