Re: ab/i18n (What's cooking in git.git (Feb 2011, #05; Wed, 23))

Jonathan Nieder [off-list ref] writes:

The commit message for the second one seems to have been mangled:

	i18n: add GETTEXT_POISON to simulate translated messages unfriendly translator

Yeah, I think I was fooled by the header folding while fixing things up
inside the mailbox.

I still don't like the #-sign business in this commit.  Couldn't it
be split into a separate patch, not to be applied until just before
the strings in commit/tag/wt-status are marked for translation?

That might be a sensible thing to do.   Ævar what do you think?

There is also a patch out there to make this use rot13, which I am
somewhat fond of.  Unfortunately, it leaks (because it is not clear
how long translated strings are supposed to last).

Yeah I would imagine it would leak.  Also blindly running rot13 to turn %d
into %q is probably not what you want.

I'd be happy with renaming use_poison() to gettext_poison() or
similar.  I suppose that is not urgent.

I would prefer to be able to merge the first handful to 'master' sooner
rather than later to minimize the damage to in-flight topics, though.

Thanks.

On Thu, Feb 24, 2011 at 02:16, Junio C Hamano [off-list ref] wrote:

Jonathan Nieder [off-list ref] writes:

quoted

The commit message for the second one seems to have been mangled:

      i18n: add GETTEXT_POISON to simulate translated messages unfriendly translator

Yeah, I think I was fooled by the header folding while fixing things up
inside the mailbox.

quoted

I still don't like the #-sign business in this commit.  Couldn't it
be split into a separate patch, not to be applied until just before
the strings in commit/tag/wt-status are marked for translation?

That might be a sensible thing to do.   Ævar what do you think?

It could, but I don't want to spend time on it. I think it's fine that
the choice of string is documented in the commit that introduces it.

quoted

There is also a patch out there to make this use rot13, which I am
somewhat fond of.  Unfortunately, it leaks (because it is not clear
how long translated strings are supposed to last).

Yeah I would imagine it would leak.  Also blindly running rot13 to turn %d
into %q is probably not what you want.

Gettext gives you a pointer to the string inside a mmaped .mo file,
effectively, so the caller doesn't have to care about it. So you can't
write something that doesn't leak memory unless you preserve that
characteristic.

But it's a debugging mode, it doesn't matter IMO if it leaks memory.

Anyway, to be blunt I really don't see the point of fiddling around
with this bit so much. Whether it's a `"GETTEXT POISON"` constant or
`rot13(msgid)` the same tests will fail. So it's not functionally
changing what the feature was for in the first place, just adding more
complexity.

Of course there might be cases where a test will fail because it's
supposed to end in \n but the poison string doesn't, but since none of
them did I didn't worry about that.

And even if one did I'd probably just mark it as C_LOCALE_ONLY
anyway. Since the intent is to make the person doing the i18n work not
break plumbing, not to perfectly annotate our test suite. I'd much
rather have a few more tests skipped under this poison mode than 20
extra lines of C code that effectively give us nothing to maintain.

If someone else wants to do the work I don't care. I just think
there's more important things to worry about.

Ævar Arnfjörð Bjarmason wrote:

Anyway, to be blunt I really don't see the point of fiddling around
with this bit so much. Whether it's a `"GETTEXT POISON"` constant or
`rot13(msgid)` the same tests will fail.

Because with rot13 you can decode the message and find the problematic
code?

If someone else wants to do the work I don't care. I just think
there's more important things to worry about.

I already wrote a patch.  I imagine you don't intend it this way, but
I keep on hearing "we shouldn't do what you've already done.  It's too
much trouble.  You wasted your time."

Ævar Arnfjörð Bjarmason wrote:

On Thu, Feb 24, 2011 at 02:16, Junio C Hamano [off-list ref] wrote:

quoted

Jonathan Nieder [off-list ref] writes:

quoted

quoted

I still don't like the #-sign business in this commit.  Couldn't it
be split into a separate patch, not to be applied until just before
the strings in commit/tag/wt-status are marked for translation?

That might be a sensible thing to do.   Ævar what do you think?

It could, but I don't want to spend time on it.

That doesn't answer the question, does it?  The question is whether
you'd be okay with the change (in which case we should do it --- it's
not like there's a shortage of people willing to write a one-line
patch) or not (in which case we shouldn't).

quoted

Yeah I would imagine it would leak.  Also blindly running rot13 to turn %d
into %q is probably not what you want.

The rot13 patch turns %d into 5q (and 5q into "d).  I think that
aspect can wait for later, of course --- a fixed string is not
actively bad or confusing.

Of course there might be cases where a test will fail because it's
supposed to end in \n but the poison string doesn't, but since none of
them did I didn't worry about that.

Right, that's a downside to the rot13 patch --- it takes \n to \n so
it wouldn't catch such cases.  Easily fixable, though.

I'd much
rather have a few more tests skipped under this poison mode than 20
extra lines of C code that effectively give us nothing

No disagreement here.  I think some cases (e.g., adding '# ' before
each line of the translated status hints) would give us something,
namely protection against hard-to-debug translation bugs.

Sorry for the grouchiness, and hope that helps.
Jonathan

On Thu, Feb 24, 2011 at 04:14, Jonathan Nieder [off-list ref] wrote:

Ævar Arnfjörð Bjarmason wrote:

quoted

Anyway, to be blunt I really don't see the point of fiddling around
with this bit so much. Whether it's a `"GETTEXT POISON"` constant or
`rot13(msgid)` the same tests will fail.

Because with rot13 you can decode the message and find the problematic
code?

quoted

If someone else wants to do the work I don't care. I just think
there's more important things to worry about.

I already wrote a patch.  I imagine you don't intend it this way, but
I keep on hearing "we shouldn't do what you've already done.  It's too
much trouble.  You wasted your time."

I don't mean it that way at all, I just mean that as a comment to
*this* particular patch series I don't think it's something we have to
worry about.

I.e. if you look at this in context we have a 170 gettext patch series
to trickle in gradually. Right now we have 70 pending with only the C
translations. Hopefully we can fast-track this to have around 150 of
those in in the next month or so.

What I want to focus on is getting this right for users of Git, and I
think it's already good enough for that purpose. I'm not worried about
an embedded debug testing mode that to my knowledge only you and I
have used so far.

If it has some changes for improvement I think they can be dealt with
later, doing it at this point means more code to review. Right now the
C code in the series is around 10 lines, doing something like the
rot13 implementation would at least triple that, making in not leak
memory (and hence have automated tools complain) would be even more
code.

Again, don't get me wrong. I really appreciate your work. I just don't
think this is something we need to worry about now.

Ævar Arnfjörð Bjarmason wrote:

I don't mean it that way at all, I just mean that as a comment to
*this* particular patch series I don't think it's something we have to
worry about.

Then we're in violent agreement, I suppose.  I don't think anyone
meant to imply that rot13 or anything of the kind should be snuck in
here.  Rereading my message, I see how it can be read that way ---
sorry about that.

I had only meant to give a heads up about something coming in the
future.

Ævar Arnfjörð Bjarmason wrote:

I don't mean it that way at all, I just mean that as a comment to
*this* particular patch series I don't think it's something we have to
worry about.

This is really tiring and unpleasant.  I don't want to stand in the
way of a translated git happening or to take on the project myself
so I can't just decree "it will be like so".

It's your and Junio's (and lots other people's, of course) code.  But
that means that for me to be able to help, I need to be able to say,
"here's a suggested change" and get an "okay" or "no, here's what's
wrong with that and how you can improve it".

And that just doesn't seem to be happening now.  I don't know how to
fix it, but I thought I should explain why I am probably so
frustrating to work with right now.

Sorry about that.

On Thu, Feb 24, 2011 at 12:00, Jonathan Nieder [off-list ref] wrote:

Ævar Arnfjörð Bjarmason wrote:

quoted

I don't mean it that way at all, I just mean that as a comment to
*this* particular patch series I don't think it's something we have to
worry about.

This is really tiring and unpleasant.  I don't want to stand in the
way of a translated git happening or to take on the project myself
so I can't just decree "it will be like so".

It's your and Junio's (and lots other people's, of course) code.  But
that means that for me to be able to help, I need to be able to say,
"here's a suggested change" and get an "okay" or "no, here's what's
wrong with that and how you can improve it".

And that just doesn't seem to be happening now.  I don't know how to
fix it, but I thought I should explain why I am probably so
frustrating to work with right now.

First off, I really appreciate having your input and help on all this,
really. And I didn't mean to cause frustration.

As for whether your code looks good, I've found it to be better than
the stuff I've come up with.

Sorry about not being more clear about that, and giving "ok"'s etc. I
think the improvements you've made are great, and if you're willing to
re-submit a better version of the series that would be even better
(depending on the status of the current one wrt Junio etc).

My apprehensiveness about adding extra things and fixing up the series
has really been about one thing, and one thing only. Which is that I
don't often have time to spend on git.git anymore, and haven't
submitted the series since October of last year.

I was hoping that I could get it into a form that would be acceptable
for fast-tracking. I.e. I could make a tiny patch at the tip of the
series, prove that it was OK, then the other 50 C/Shell etc. patches
could get in quickly.

Anyway, with the timeline Junio has in mind *that* probably won't be
possible. I'm rapidly approaching a time where I again won't have time
for Git.

But just getting this in would be great, I can submit more stuff later
when I have time, and it'll be less to juggle at once since there'll
already be something in git.git:master.

And if someone else wants to pick it up and shepard it along that
would be fantastic as well.

Ævar Arnfjörð Bjarmason wrote:

First off, I really appreciate having your input and help on all this,
really. And I didn't mean to cause frustration.

The series seems to be un-stuck now, so frustration gone.  Sorry, I'm
no good at this sort of thing.

Thanks for translated git, gettext poison, "prove"-able tests and
other assorted neat toys. :)