You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "Peter N. Lundblad" <pe...@famlundblad.se> on 2004/07/27 22:02:15 UTC
Re: svn commit: r10429 - branches/1.1.x/subversion/po
On Tue, 27 Jul 2004 dionisos@tigris.org wrote:
> Author: dionisos
> Date: Tue Jul 27 13:17:16 2004
> New Revision: 10429
>
> Modified:
> branches/1.1.x/subversion/po/de.po
> branches/1.1.x/subversion/po/es.po
> branches/1.1.x/subversion/po/nb.po
> branches/1.1.x/subversion/po/sv.po
> Log:
> Merge translation updates.
>
> Merge trunk revisions
> r10254,
> r10282,
> r10409,
> r10412,
> r10415,
> r10418,
> r10423,
> r10426.
>
>
Some of these (the changes to es and sv) include formatting strings and
require voting per hacking. Maybe this was discussed when you were away...
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r10429 - branches/1.1.x/subversion/po
Posted by Erik Huelsmann <e....@gmx.net>.
> > Log:
> > Merge translation updates.
> >
> > Merge trunk revisions
> > r10254,
> > r10282,
> > r10409,
> > r10412,
> > r10415,
> > r10418,
> > r10423,
> > r10426.
> >
> >
> Some of these (the changes to es and sv) include formatting strings and
> require voting per hacking. Maybe this was discussed when you were away...
It was. (discussed while I was away)
Since we restart soaking, which partially resets to the point where we were
when starting the branch, I thought that this is an allowable move. I'm off
to work now, but I can add it to STATUS this evening.
bye,
Erik.
--
NEU: WLAN-Router f�r 0,- EUR* - auch f�r DSL-Wechsler!
GMX DSL = superg�nstig & kabellos http://www.gmx.net/de/go/dsl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r10429 - branches/1.1.x/subversion/po
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Thu, 29 Jul 2004, Erik Huelsmann wrote:
> Let me start by saying that I think the rule should *not* be relaxed. I
> think that I caught attention too late to get the translations up to date. I
> know what to do next time we hit a release branch point.
>
> However: Since (and this is an exceptional situation I hope) we will be
> restarting soaking with the release of RC2, I figured that puts us back to
> the point where the branch is created. Next to that, I run the status mailer
> script daily on the branch until we hit 1.1.
>
Yes, I've seen that and I'm +1 without questions.
>
> Given the above two facts and the fact that what I recognise that what I did
> can *never* happen after the start of the soaking has started, I hope that
> I'm forgiven this once.
>
No problem. Just wanted to bring the changes to HACKING to your attention.
> It would be truely a shame to have to do with the quality of the
> translations pre-10429 for the next half year or more...
>
Yes. And we can merge changes even in the soak period with voting. To make
life easier for myself and others, I've made non-formatting-string updates
in a separate commit just during the branch period so that I can do most
of the merging without others needing to bother. (See r10320) That might
be a good idea for others too.
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r10429 - branches/1.1.x/subversion/po
Posted by Erik Huelsmann <e....@gmx.net>.
> On Wed, 28 Jul 2004, Max Bowsher wrote:
>
> > Erik Huelsmann wrote:
> > >>>> Log:
> > >>>> Merge translation updates.
> > >>>>
> > >>>> Merge trunk revisions
> > >>>> r10254,
> > >>>> r10282,
> > >>>> r10409,
> > >>>> r10412,
> > >>>> r10415,
> > >>>> r10418,
> > >>>> r10423,
> > >>>> r10426.
> > >>>>
> > >>>>
> > >>> Some of these (the changes to es and sv) include formatting strings
> and
> > >>> require voting per hacking. Maybe this was discussed when you were
> > away...
> > >>
> > >> I thought by that we meant you couldn't change the argument ordering,
> > >> add any arguments to a message, or change the types of the arguments.
> > >> Not that you couldn't touch something that was used as a format call.
> > >> Now if you change a %d to %ld then you'd be violating that. But I
> don't
> > >> think adding:
> > >>
> > >> +msgid "Unsupported FS loader version (%d) for fsfs"
> > >> +msgstr "Aplique RA binariamente incompatible (versión %d) para
> ra_dav"
> > >>
> > >> violates thats. Am I missing some case where adding that would be
> bad?
> > >
> > > I'd love it to mean that. I think the idea is that the review and
> voting
> > > process should make sure that no strings slip through which do change
> > > parameters or parameter ordering.
> >
> > I think the case illustrated by the above example is perfectly ok to
> merge.
>
> Ofcourse, isnce it is correct. But that's the case with all correct code
> if it qualifies for other reasons.
>
> > Any committer doing .po merges to branches has responsibility to check
> > carefully that all the strings to merge really do have no format
> specifier
> > changes.
> >
> > To help them, we might consider declaring that any revisions with format
> > specifier changes *MUST* say so in the log message.
> >
> Two steps that are easy to miss sometimes and that will introduce a crash.
>
> In HACKING, we require voting for any changes to strings in the C source
> and we don't allow % changes at all. The .po rule is relaxed so string
> changes (I'm always talking about msgstr strings,msgid is a change to the
> C code) that don't touch % codes can be merged without voting. But %
> changes require voting, since the format strings aren't validated by the
> normal build (because that's non-portable) and they easily introduce
> crashes. GNU msgfmt can validate format strings, so it is easy to make
> sure they are correct. Still people make mistakes and miss this. (I might
> be abnormally sloppy, but you can see a recent commit by me that was just
> comment fixes, shortly followed by a follow-up that removed an extra */,
> so that the whole tree built again...)
>
> That was the idea when I proposed the change to HACKING some month ago.
> Ironically, then, jerenkrantz (I believe) objected saying this rule was
> too relaxed. And now, some people want to relax it even more:-)
Let me start by saying that I think the rule should *not* be relaxed. I
think that I caught attention too late to get the translations up to date. I
know what to do next time we hit a release branch point.
However: Since (and this is an exceptional situation I hope) we will be
restarting soaking with the release of RC2, I figured that puts us back to
the point where the branch is created. Next to that, I run the status mailer
script daily on the branch until we hit 1.1.
Given the above two facts and the fact that what I recognise that what I did
can *never* happen after the start of the soaking has started, I hope that
I'm forgiven this once.
It would be truely a shame to have to do with the quality of the
translations pre-10429 for the next half year or more...
bye,
Erik.
--
NEU: WLAN-Router für 0,- EUR* - auch für DSL-Wechsler!
GMX DSL = supergünstig & kabellos http://www.gmx.net/de/go/dsl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r10429 - branches/1.1.x/subversion/po
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Mon, 2 Aug 2004, Ben Reser wrote:
> On Sun, Aug 01, 2004 at 07:53:27PM +0200, Peter N. Lundblad wrote:
> > msgfmt -c
> >
> > I proposed to add -c to the msgfmt arguments in Makefile.in. The problem
> > was that -c is a GNUism. We could do some configure script work to use
> > this flag if available and ensure that the release manager use GNU
> > gettext. Then I would be +1 on your interpretation, no problem.
>
> Well I can say for sure that I'm using GNU gettext now. But I don't
> know how we can really gurantee that will always be the case. Adding
> support for -c sounds like a good idea. But maybe it'd be better to
> develop our own tool that was in Python that we could be sure the RM
> always can run it.
>
OK. Then someone better at python than me (which means very little...)
has to do this. Else, there is my -c patch which I posted which might be
good to commit for now?
Thanks,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r10429 - branches/1.1.x/subversion/po
Posted by Ben Reser <be...@reser.org>.
On Sun, Aug 01, 2004 at 07:53:27PM +0200, Peter N. Lundblad wrote:
> msgfmt -c
>
> I proposed to add -c to the msgfmt arguments in Makefile.in. The problem
> was that -c is a GNUism. We could do some configure script work to use
> this flag if available and ensure that the release manager use GNU
> gettext. Then I would be +1 on your interpretation, no problem.
Well I can say for sure that I'm using GNU gettext now. But I don't
know how we can really gurantee that will always be the case. Adding
support for -c sounds like a good idea. But maybe it'd be better to
develop our own tool that was in Python that we could be sure the RM
always can run it.
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r10429 - branches/1.1.x/subversion/po
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Sun, 1 Aug 2004, Ben Reser wrote:
> There's certainly no reason we couldn't develop a tool, probably would
> take me 5 minutes, that would make sure the formats match. If there
> isn't already such a tool.
>
msgfmt -c
> Also just because there's no voting doesn't mean there isn't review. We
> could even add the running of such a tool to our test suite run. Which
> means a release will never have this problem because it'll fail the test
> suite run.
>
I proposed to add -c to the msgfmt arguments in Makefile.in. The problem
was that -c is a GNUism. We could do some configure script work to use
this flag if available and ensure that the release manager use GNU
gettext. Then I would be +1 on your interpretation, no problem.
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r10429 - branches/1.1.x/subversion/po
Posted by Ben Reser <be...@reser.org>.
On Sun, Aug 01, 2004 at 04:48:24PM +0200, Peter N. Lundblad wrote:
> What do you mean by "very wrong"? Ofcourse, a simple mistake such as
> swapping an %s with an %d is very wrong, still it is easy to do if your
> language put the words in a different order. I'm not sure every translator
> use tools with format string validation. Also, what would make the change
> not allowed if the translator thinks it is correct and merges it?
Well there shouldn't ever be a circumstance where the format strings in
a translation don't match that in the English version since we don't
have positional formatting codes available. So any difference is a bug.
There's certainly no reason we couldn't develop a tool, probably would
take me 5 minutes, that would make sure the formats match. If there
isn't already such a tool.
Also just because there's no voting doesn't mean there isn't review. We
could even add the running of such a tool to our test suite run. Which
means a release will never have this problem because it'll fail the test
suite run.
> >
> > The only circumstance I really see coming up in practice is adding
> > strings that weren't previously translatable because they weren't
> > wrapped with _(). Those things require voting. So I'd modify the rules
>
> Why is this a problem? If the string is correct in the source, then the
> msgid will be correct in the .po file and, per your logic, the msgstr will
> be correct since a single translator don't make mistakes. Here must be
> something I don't understand...
Because to add a new string requires modification to the C code. We
want to be very cautious about that. I guess I don't get what the
confusion is here.
> I think this is confusing. Changes to .po files that affect msgids are
> made by tools, not people. These rules should concentrate on msgstr
> changes. So, your rule could be rewritten something like:
> Without voting:
> ...
> * Changes to .po files if all format specifiers exactly match the
> correspinding msgid strings regarding (including their order).
Changes are made by tools, but checked in by human beings. An addition
of a msgid to a po file implies a change to a C source file. My
intention is to allow translators to work on .po files freely as long as
they don't modify a C source file.
When I say add a new msgid I mean create one by adding a _() to the C
source code. I'm assuming here that a translator is going to probably
add the _() and then provide the translation additions in the same
voting item.
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r10429 - branches/1.1.x/subversion/po
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Thu, 29 Jul 2004, Ben Reser wrote:
> On Thu, Jul 29, 2004 at 08:56:05AM +0200, Peter N. Lundblad wrote:
> >
> >
> > I see that we interpret these differently. What would the second rule
> > allow that the first doesn't under your interpretation?
>
> Right now as far as I'm concerned this rule means as long as you don't
> touch a .c or .h file you're fine. Because you can't go changing the %
> codes without chaing the .c or .h files. Now I suppose someone could
> use a %d interchangeable with a %ld on some platforms. But this all
> should be easy to review. If the % codes on the msgid don't match the
> msgstr then there is probably something very wrong with the change and
> it won't be allowed anyway. If the msgid doesn't match what we have in
What do you mean by "very wrong"? Ofcourse, a simple mistake such as
swapping an %s with an %d is very wrong, still it is easy to do if your
language put the words in a different order. I'm not sure every translator
use tools with format string validation. Also, what would make the change
not allowed if the translator thinks it is correct and merges it?
>
> The only circumstance I really see coming up in practice is adding
> strings that weren't previously translatable because they weren't
> wrapped with _(). Those things require voting. So I'd modify the rules
Why is this a problem? If the string is correct in the source, then the
msgid will be correct in the .po file and, per your logic, the msgstr will
be correct since a single translator don't make mistakes. Here must be
something I don't understand...
> to read as follows to be more clear:
>
> Without voting:
> - Changes to message translations in .po files where the % codes in the
> msgstr are exactly the same (including order) as the % codes in the
> msgid and that do not add new msgids that did not previously exist.
>
> With voting:
> - Changes to message translations in .po files that add a msgid (not
> used in another existing translation) or alter the % codes in an
> existing msgid.
>
I think this is confusing. Changes to .po files that affect msgids are
made by tools, not people. These rules should concentrate on msgstr
changes. So, your rule could be rewritten something like:
Without voting:
...
* Changes to .po files if all format specifiers exactly match the
correspinding msgid strings regarding (including their order).
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r10429 - branches/1.1.x/subversion/po
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Thursday, July 29, 2004 1:26 PM -0700 Ben Reser <be...@reser.org> wrote:
> wrapped with _(). Those things require voting. So I'd modify the rules
> to read as follows to be more clear:
>
> Without voting:
> - Changes to message translations in .po files where the % codes in the
> msgstr are exactly the same (including order) as the % codes in the
> msgid and that do not add new msgids that did not previously exist.
>
> With voting:
> - Changes to message translations in .po files that add a msgid (not
> used in another existing translation) or alter the % codes in an
> existing msgid.
+1 - this was the intent of what I had suggested before. I'd also say that a
specific language that adds a translation for an *already existing* message id
can be added without voting (or restart). However, changing the msgid (or
adding a new msgid) should require a vote. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: svn commit: r10429 - branches/1.1.x/subversion/po
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Sat, 31 Jul 2004, Clifford Caoile wrote:
> I have a question about the % codes and order.
>
> Given this discussion, would it be fair to say that the rearrangement of the
> % codes, even after using the msgfmt rearragement syntax (for example,
> "Error %s return val %ld" ==> "Return val %2$ld error %1$s" ) is not
> supported in Subversion build process?
>
This isn't an msgfmt syntax, but an option for printf in newer POSIX
specifications. We use APR's own printf functions, which don't support
this feature. There have been talk about adding this to APR, but AFAIK no
one has done so yet.
regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: svn commit: r10429 - branches/1.1.x/subversion/po
Posted by Clifford Caoile <pi...@email.com>.
I have a question about the % codes and order.
| Ben Reser said:
|
| Right now as far as I'm concerned this rule means as long as you don't
| touch a .c or .h file you're fine. Because you can't go changing the %
| codes without chaing the .c or .h files. Now I suppose someone could
| use a %d interchangeable with a %ld on some platforms. But this all
| should be easy to review. If the % codes on the msgid don't match the
| msgstr then there is probably something very wrong with the change and
| it won't be allowed anyway. If the msgid doesn't match what we have in
| the code then well, the msgstr won't ever be used so there's no harm
| as far as stability, though the translation will suffer.
|
| The only circumstance I really see coming up in practice is adding
| strings that weren't previously translatable because they weren't
| wrapped with _(). Those things require voting. So I'd modify the rules
| to read as follows to be more clear:
|
| Without voting:
| - Changes to message translations in .po files where the % codes in the
| msgstr are exactly the same (including order) as the % codes in the
| msgid and that do not add new msgids that did not previously exist.
|
| With voting:
| - Changes to message translations in .po files that add a msgid (not
| used in another existing translation) or alter the % codes in an
| existing msgid.
Given this discussion, would it be fair to say that the rearrangement of the
% codes, even after using the msgfmt rearragement syntax (for example,
"Error %s return val %ld" ==> "Return val %2$ld error %1$s" ) is not
supported in Subversion build process?
Reference: info "(gettext)c-format Flag" (I can't get a more comprehensive
explaination than this)
Regards,
Clifford Caoile
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r10429 - branches/1.1.x/subversion/po
Posted by Ben Reser <be...@reser.org>.
On Thu, Jul 29, 2004 at 08:56:05AM +0200, Peter N. Lundblad wrote:
>
>
> On Wed, 28 Jul 2004, Ben Reser wrote:
>
> > On Wed, Jul 28, 2004 at 11:34:38PM +0200, Peter N. Lundblad wrote:
> > > That was the idea when I proposed the change to HACKING some month ago.
> > > Ironically, then, jerenkrantz (I believe) objected saying this rule was
> > > too relaxed. And now, some people want to relax it even more:-)
> >
> > I don't think I'm suggesting that we relax the rule. I thought the rule
> > allowed those changes to be merged. Did I miss something in them? I'm
> > certainly okay with them the way I understand them.
> >
> We have in hacking:
>
> Without voting:
> ...
> - Changes to message translations in .po files as long as format string
> "%" codes are not touched.
> With voting:
> ...
> - Changes to message translations in .po files with changes to format
> "%" codes.
>
> I see that we interpret these differently. What would the second rule
> allow that the first doesn't under your interpretation?
Right now as far as I'm concerned this rule means as long as you don't
touch a .c or .h file you're fine. Because you can't go changing the %
codes without chaing the .c or .h files. Now I suppose someone could
use a %d interchangeable with a %ld on some platforms. But this all
should be easy to review. If the % codes on the msgid don't match the
msgstr then there is probably something very wrong with the change and
it won't be allowed anyway. If the msgid doesn't match what we have in
the code then well, the msgstr won't ever be used so there's no harm
as far as stability, though the translation will suffer.
The only circumstance I really see coming up in practice is adding
strings that weren't previously translatable because they weren't
wrapped with _(). Those things require voting. So I'd modify the rules
to read as follows to be more clear:
Without voting:
- Changes to message translations in .po files where the % codes in the
msgstr are exactly the same (including order) as the % codes in the
msgid and that do not add new msgids that did not previously exist.
With voting:
- Changes to message translations in .po files that add a msgid (not
used in another existing translation) or alter the % codes in an
existing msgid.
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r10429 - branches/1.1.x/subversion/po
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Wed, 28 Jul 2004, Ben Reser wrote:
> On Wed, Jul 28, 2004 at 11:34:38PM +0200, Peter N. Lundblad wrote:
> > That was the idea when I proposed the change to HACKING some month ago.
> > Ironically, then, jerenkrantz (I believe) objected saying this rule was
> > too relaxed. And now, some people want to relax it even more:-)
>
> I don't think I'm suggesting that we relax the rule. I thought the rule
> allowed those changes to be merged. Did I miss something in them? I'm
> certainly okay with them the way I understand them.
>
We have in hacking:
Without voting:
...
- Changes to message translations in .po files as long as format string
"%" codes are not touched.
With voting:
...
- Changes to message translations in .po files with changes to format
"%" codes.
I see that we interpret these differently. What would the second rule
allow that the first doesn't under your interpretation?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r10429 - branches/1.1.x/subversion/po
Posted by Ben Reser <be...@reser.org>.
On Wed, Jul 28, 2004 at 11:34:38PM +0200, Peter N. Lundblad wrote:
> That was the idea when I proposed the change to HACKING some month ago.
> Ironically, then, jerenkrantz (I believe) objected saying this rule was
> too relaxed. And now, some people want to relax it even more:-)
I don't think I'm suggesting that we relax the rule. I thought the rule
allowed those changes to be merged. Did I miss something in them? I'm
certainly okay with them the way I understand them.
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r10429 - branches/1.1.x/subversion/po
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Wed, 28 Jul 2004, Max Bowsher wrote:
> Erik Huelsmann wrote:
> >>>> Log:
> >>>> Merge translation updates.
> >>>>
> >>>> Merge trunk revisions
> >>>> r10254,
> >>>> r10282,
> >>>> r10409,
> >>>> r10412,
> >>>> r10415,
> >>>> r10418,
> >>>> r10423,
> >>>> r10426.
> >>>>
> >>>>
> >>> Some of these (the changes to es and sv) include formatting strings and
> >>> require voting per hacking. Maybe this was discussed when you were
> away...
> >>
> >> I thought by that we meant you couldn't change the argument ordering,
> >> add any arguments to a message, or change the types of the arguments.
> >> Not that you couldn't touch something that was used as a format call.
> >> Now if you change a %d to %ld then you'd be violating that. But I don't
> >> think adding:
> >>
> >> +msgid "Unsupported FS loader version (%d) for fsfs"
> >> +msgstr "Aplique RA binariamente incompatible (versión %d) para ra_dav"
> >>
> >> violates thats. Am I missing some case where adding that would be bad?
> >
> > I'd love it to mean that. I think the idea is that the review and voting
> > process should make sure that no strings slip through which do change
> > parameters or parameter ordering.
>
> I think the case illustrated by the above example is perfectly ok to merge.
Ofcourse, isnce it is correct. But that's the case with all correct code
if it qualifies for other reasons.
> Any committer doing .po merges to branches has responsibility to check
> carefully that all the strings to merge really do have no format specifier
> changes.
>
> To help them, we might consider declaring that any revisions with format
> specifier changes *MUST* say so in the log message.
>
Two steps that are easy to miss sometimes and that will introduce a crash.
In HACKING, we require voting for any changes to strings in the C source
and we don't allow % changes at all. The .po rule is relaxed so string
changes (I'm always talking about msgstr strings,msgid is a change to the
C code) that don't touch % codes can be merged without voting. But %
changes require voting, since the format strings aren't validated by the
normal build (because that's non-portable) and they easily introduce
crashes. GNU msgfmt can validate format strings, so it is easy to make
sure they are correct. Still people make mistakes and miss this. (I might
be abnormally sloppy, but you can see a recent commit by me that was just
comment fixes, shortly followed by a follow-up that removed an extra */,
so that the whole tree built again...)
That was the idea when I proposed the change to HACKING some month ago.
Ironically, then, jerenkrantz (I believe) objected saying this rule was
too relaxed. And now, some people want to relax it even more:-)
Hope this clarifies the thinkings behind the current rule.
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r10429 - branches/1.1.x/subversion/po
Posted by Max Bowsher <ma...@ukf.net>.
Erik Huelsmann wrote:
>>>> Log:
>>>> Merge translation updates.
>>>>
>>>> Merge trunk revisions
>>>> r10254,
>>>> r10282,
>>>> r10409,
>>>> r10412,
>>>> r10415,
>>>> r10418,
>>>> r10423,
>>>> r10426.
>>>>
>>>>
>>> Some of these (the changes to es and sv) include formatting strings and
>>> require voting per hacking. Maybe this was discussed when you were
away...
>>
>> I thought by that we meant you couldn't change the argument ordering,
>> add any arguments to a message, or change the types of the arguments.
>> Not that you couldn't touch something that was used as a format call.
>> Now if you change a %d to %ld then you'd be violating that. But I don't
>> think adding:
>>
>> +msgid "Unsupported FS loader version (%d) for fsfs"
>> +msgstr "Aplique RA binariamente incompatible (versión %d) para ra_dav"
>>
>> violates thats. Am I missing some case where adding that would be bad?
>
> I'd love it to mean that. I think the idea is that the review and voting
> process should make sure that no strings slip through which do change
> parameters or parameter ordering.
I think the case illustrated by the above example is perfectly ok to merge.
Any committer doing .po merges to branches has responsibility to check
carefully that all the strings to merge really do have no format specifier
changes.
To help them, we might consider declaring that any revisions with format
specifier changes *MUST* say so in the log message.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r10429 - branches/1.1.x/subversion/po
Posted by Erik Huelsmann <e....@gmx.net>.
> > > Log:
> > > Merge translation updates.
> > >
> > > Merge trunk revisions
> > > r10254,
> > > r10282,
> > > r10409,
> > > r10412,
> > > r10415,
> > > r10418,
> > > r10423,
> > > r10426.
> > >
> > >
> > Some of these (the changes to es and sv) include formatting strings and
> > require voting per hacking. Maybe this was discussed when you were
> away...
>
> I thought by that we meant you couldn't change the argument ordering,
> add any arguments to a message, or change the types of the arguments.
> Not that you couldn't touch something that was used as a format call.
> Now if you change a %d to %ld then you'd be violating that. But I don't
> think adding:
>
> +msgid "Unsupported FS loader version (%d) for fsfs"
> +msgstr "Aplique RA binariamente incompatible (versión %d) para ra_dav"
>
> violates thats. Am I missing some case where adding that would be bad?
I'd love it to mean that. I think the idea is that the review and voting
process should make sure that no strings slip through which do change
parameters or parameter ordering.
bye,
Erik.
--
NEU: WLAN-Router für 0,- EUR* - auch für DSL-Wechsler!
GMX DSL = supergünstig & kabellos http://www.gmx.net/de/go/dsl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r10429 - branches/1.1.x/subversion/po
Posted by Ben Reser <be...@reser.org>.
On Wed, Jul 28, 2004 at 12:02:15AM +0200, Peter N. Lundblad wrote:
> On Tue, 27 Jul 2004 dionisos@tigris.org wrote:
>
> > Author: dionisos
> > Date: Tue Jul 27 13:17:16 2004
> > New Revision: 10429
> >
> > Modified:
> > branches/1.1.x/subversion/po/de.po
> > branches/1.1.x/subversion/po/es.po
> > branches/1.1.x/subversion/po/nb.po
> > branches/1.1.x/subversion/po/sv.po
> > Log:
> > Merge translation updates.
> >
> > Merge trunk revisions
> > r10254,
> > r10282,
> > r10409,
> > r10412,
> > r10415,
> > r10418,
> > r10423,
> > r10426.
> >
> >
> Some of these (the changes to es and sv) include formatting strings and
> require voting per hacking. Maybe this was discussed when you were away...
I thought by that we meant you couldn't change the argument ordering,
add any arguments to a message, or change the types of the arguments.
Not that you couldn't touch something that was used as a format call.
Now if you change a %d to %ld then you'd be violating that. But I don't
think adding:
+msgid "Unsupported FS loader version (%d) for fsfs"
+msgstr "Aplique RA binariamente incompatible (versión %d) para ra_dav"
violates thats. Am I missing some case where adding that would be bad?
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org