Thread: ecpg localization
Hi, One of the few parts of the core that is not localized is the ecpg. Attached is a patch that builds the basic infrastructure to make it possible. Besides that I worked on some strings to make them conform with [1] but I didn't do for all of them. When I was doing the clean up I realized that an overhaul of ecpg_log, ecpg_raise, mmerror and base_yyerror functions is necessary. I'll give it a try later. [1] http://www.postgresql.org/docs/8.3/static/nls-programmer.html -- Euler Taveira de Oliveira http://www.timbira.com/
Attachment
Am Samstag, 26. April 2008 schrieb Euler Taveira de Oliveira: > One of the few parts of the core that is not localized is the ecpg. > Attached is a patch that builds the basic infrastructure to make it > possible. Besides that I worked on some strings to make them conform > with [1] but I didn't do for all of them. > When I was doing the clean up I realized that an overhaul of ecpg_log, > ecpg_raise, mmerror and base_yyerror functions is necessary. I'll give > it a try later. Looks good for a start, but what is missing in this patch is that mmerror and the other functions actually call gettext. So currently this patch doesn't achieve a lot. I suggest you keep working on this, and we will reconsider a more complete patch at a later date.
Peter Eisentraut <peter_e@gmx.net> writes:
> Am Samstag, 26. April 2008 schrieb Euler Taveira de Oliveira:
>> One of the few parts of the core that is not localized is the ecpg.
>> Attached is a patch that builds the basic infrastructure to make it
>> possible.
> Looks good for a start, but what is missing in this patch is that mmerror and
> the other functions actually call gettext. So currently this patch doesn't
> achieve a lot.
Well, it was only advertised as infrastructure, not a completed feature.
I'm wondering whether it would be appropriate to apply now despite being
incomplete. The patch touches enough places in ecpg that code drift is
likely to be a serious problem if it has to sit around for long.
Ultimately Michael's opinion is the one that matters most for ecpg
stuff, anyway. Michael?
regards, tom lane
Peter Eisentraut wrote: > Looks good for a start, but what is missing in this patch is that mmerror and > the other functions actually call gettext. So currently this patch doesn't > achieve a lot. > I don't know if I understand what you want to say by "call gettext". A quick look at the l10n of backend proves that it calls gettext everywhere. Could you ellaborate? Based on your feedback I'm working on the second part (overhaul of ecpg output message functions). > I suggest you keep working on this, and we will reconsider a more complete > patch at a later date. > Thanks for your feedback. I agree with Tom that it's is a in-progress-work. I'll send another revision of the first patch later. -- Euler Taveira de Oliveira http://www.timbira.com/
Euler Taveira de Oliveira wrote: > I don't know if I understand what you want to say by "call gettext". A > quick look at the l10n of backend proves that it calls gettext > everywhere. Could you ellaborate? In nls.mk, you mark mmerror as containing arguments for translation, but mmerror doesn't call gettext anywhere, so nothing would get translated at run time. To pick up your backend example, we mark arguments of errmsg() for translation, but then errmsg() calls gettext.
Tom Lane wrote: > I'm wondering whether it would be appropriate to apply now despite being > incomplete. The patch touches enough places in ecpg that code drift is > likely to be a serious problem if it has to sit around for long. We could do that, as soon as the author understands where the patch would need to go, as discussed elsewhere in this thread.
On Fri, May 02, 2008 at 07:19:00PM -0400, Tom Lane wrote: > Ultimately Michael's opinion is the one that matters most for ecpg > stuff, anyway. Michael? Sorry for the late reply, real life constraints. I talked to Peter about the patched before he sent out his first email. In fact I agree with both of you, as soon as there's a common understanding of needs to be done and a willingness to do it I'm fine with committing the patch as is. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!
Peter Eisentraut wrote: > I suggest you keep working on this, and we will reconsider a more complete > patch at a later date. > This is a second try. Fix some issues pointed by Peter. It's a little fatter 'cause I worked on almost all of the strings. I attempted to mimic the postgresql style but I think that those strings need more work on as I pointed out in the first e-mail. Again, It is necessary to overhaul the ecpg emit-some-message-functions. For example, some of them have tips in it, other ones is just-for-information message, and so on. I don't have in mind what is a good draft for those messages. Suggestions? -- Euler Taveira de Oliveira http://www.timbira.com/
Attachment
Euler Taveira de Oliveira wrote: > This is a second try. I forgot to say that this patch doesn't include nls support to ecpg files automagically. If you guys think that it's is a Good Thing to do, we need to hack the preproc.y to hardcode the locale stuff; if you decide that it isn't necessary, we need to document that the nls support can be achieved by using the locale stuff. Comments? There is a bogus fprintf message at ecpg_gettext(), please remove it. -- Euler Taveira de Oliveira http://www.timbira.com/
Am Samstag, 10. Mai 2008 schrieb Euler Taveira de Oliveira: > This is a second try. Fix some issues pointed by Peter. It's a little > fatter 'cause I worked on almost all of the strings. I attempted to > mimic the postgresql style but I think that those strings need more work > on as I pointed out in the first e-mail. Committed.
Am Sonntag, 11. Mai 2008 schrieb Euler Taveira de Oliveira: > I forgot to say that this patch doesn't include nls support to ecpg > files automagically. If you guys think that it's is a Good Thing to do, > we need to hack the preproc.y to hardcode the locale stuff; if you > decide that it isn't necessary, we need to document that the nls support > can be achieved by using the locale stuff. Comments? I don't understand what you mean here.
Peter Eisentraut wrote: >> I forgot to say that this patch doesn't include nls support to ecpg >> files automagically. If you guys think that it's is a Good Thing to do, >> we need to hack the preproc.y to hardcode the locale stuff; if you >> decide that it isn't necessary, we need to document that the nls support >> can be achieved by using the locale stuff. Comments? > > I don't understand what you mean here. > I mean that you need to put <locale.h> and setlocale(LC_MESSAGES, "") at .pgc so you get localized messages from ecpg program. -- Euler Taveira de Oliveira http://www.timbira.com/
Euler Taveira de Oliveira wrote: > I mean that you need to put <locale.h> and setlocale(LC_MESSAGES, "") at > .pgc so you get localized messages from ecpg program. That seems perfectly reasonable.