Обсуждение: 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/

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/

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.