[I18n-sig] Re: pygettext dilemma

[François Pinard]

[Barry A. Warsaw]

> No hurt taken [...]

Thanks!  It would have much saddened me otherwise.

> IIRC, gettext suggests binding N_() to gettext_noop()

I was not overly happy with N_(), even if it comes from me as well, but
given gettext_noop() are less frequent than gettext() in the experience
we accumulated at the time, it was bearable.  But I never really liked it.

> Hmm, maybe we should add "N_" as one of the default keywords?

This would be kind of natural from someone educated with C gettext, and
looks much better to me than redefining _().  Much much better! :-)

Of course, I considered it, a while ago already, but rejected it for my
own use for two reasons.  I'm not sure how solidly those reasons would
stand today.  Here there are nevertheless.

The first is that N_() is completely pre-processed out in C, while N_()
would stay executable in Python.  To go as far as calling a function,
as a side-effect of marking, was looking to me like a high price to me.
Conceptual price, of course; I'm not thinking about sparing the CPU, here.

The second is a mere consequence of the first.  Python would not let us
use N_() for docstrings.  And I consider that Python is very right here,
in telling me I'm wrong, because N_() is much more than a marker, while
it should be nothing more than a marker, and have no other significance.

> That points out a general philosophy I have that pygettext.py should
> mimic xgettext as much as makes sense for the difference between C and
> Python.

I understand what you mean here, and I mostly agree.  However, I would like
to warn you against going too far in trying to follow `gettext'.  It would
be difficult for me to go in details now, but overall, I feel that `gettext'
is a bit short-sighted.  At the origin, this was really on purpose, as the
initial goal was to put out something simple, and allow many years (I knew
it has to be more than a few) so the idea of internationalization spreads
and gets a wider acceptance in the field of free software.  I think the idea
has grown solid enough to not die by now, but if we want to be objective,
there is still much, much to accomplish even with the initial design.

However, I would guess that it would not take many more years before we
get ready for another leap, and I fear `gettext' might not be fully ready
for it, as it is getting somewhat encumbered by opinions, more than vision.
I was hoping that Python might be the vehicle for that step.  And for this
to occur, Python needs being able to keep some distance and autonomy.

> [...] are you saying that ''"""Text""" should be used for both the
> runtime translating and the extraction marking?

No.  Only for marking, when nothing more than marking is meant.

> Wouldn't it be wonderful if I only needed to type them once:
>     _('No such list %(listname)s found on host %(hostname)s')

Yes, it would be wonderful.  Also notice that we could eventually go a lot
further than merely exchanging the order of the variables.  Many languages
use morphological flexing of surrounding words according to various
properties coming from inserts themselves, or even more important changes.

> The trick is that the function _() isn't gettext.gettext() but a
> wrapper around that library function that's unique to Mailman.

As much as possible, think Python, not only Mailman. :-) Yet, I quite
understand one has to start somewhere.

> But there is another problem: for some fonts in some IDE's it can be
> challenging to discern ' from " or even ` and having something like
> ""'''...''' makes it even more difficult to visually pick out.

Please, do not merely let random fonts or editors design decide of your
vision.  Things start to go wrong when each actor is trying to take all
the problems of the world on his/her shoulders.  I could speak with length
and conviction about a few bad moves in the area of fonts, in these days,
especially with Unicode around.  Just let's not dive into that, and rather
hope that reason (or horse sense) will finally prevail.  The most productive
attitude is that everyone identifies his/her share, and do well with it.

> For the handful of cases where you need to defer translation, I prefer
> using a technique as similar to the common way as possible, instead of
> introducing an entirely different convention.  But I wouldn't cry foul
> if you encouraged N_() markings for deferred translations.

No doubt to me, N_() is vastly superior to locally redefining _().
And _even_ if vastly superior, it is still not that good. :-)

> The more I think about it, I think a magic comment in front of the
> docstring is the way to go.  I'm not yet sure whether something like

>     # noextract
>     '''This is a docstring that need not be translated.'''

> or

>     # extract
>     '''This is a docstring that should be translated.'''

> is better, or whether there's some other better comment keyword to
> use.  This would be worth experimenting with a bit.

It seems like a good idea.  This is surely legible and neat, and probably
better than the other things we saw so far, from both of us! :-)

I have a slight fear that it might become tedious if we have long
sequences of translation-delayed strings, as it will likely happen in some
applications.  (I've linguistic applications in mind: as my associate is
a linguist and we often work together, I saw such things a few times.)

>     FP> I would not want to crusade inordinately over this

> A good, lively debate.  Thanks!

Oh, you know, I do not want it too lively.  As much as I like friendly
exchanges of ideas, as least because they convey friendship, I hate debates
and conflicts.  I dare to think I'm a peaceful man...

For the Translation Project, Martin von Löwis and Karl Eichwalder took the
torch and accepted to face the music.  I'm extremely grateful to them, yet a
bit sorry, thinking about some stubbornness out there which will undoubtedly
hit them.  For one, I'm too old and tired for fighting it anymore. :-)

> Let's not conflate what we're talking about.

Oops!  I do not know the word "conflate", and do not find it in my
English-French dictionary.  I'm a priori ready to "not conflate" if it
pleases you :-).  But then, what should I do, or avoid to do? :-)

                                        Keep happy!

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard