You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Stein <gs...@gmail.com> on 2008/10/21 08:28:05 UTC
Re: svn commit: r33792 - in trunk/subversion: libsvn_wc svn
Is there a way to mark the strings as "We made a conscious decision to
not translate these" ? ... I fear that in a year or so, somebody will
come along, notice they done have _() around them, and *add* it back.
On Mon, Oct 20, 2008 at 5:54 PM, <ne...@tigris.org> wrote:
> Author: neels
> Date: Mon Oct 20 17:54:35 2008
> New Revision: 33792
>
> Log:
> Making two fatal errors non-translatable. They only occur in the presence
> of a corrupt working copy.
>
> Suggested by: jensseidel
>
> * subversion/svn/tree-conflicts.c
> (svn_cl__append_human_readable_tree_conflict_description): Remove a _().
>
> * subversion/libsvn_wc/tree_conflicts.c
> (svn_wc__write_tree_conflicts_to_entry): Remove a _().
>
> Modified:
> trunk/subversion/libsvn_wc/tree_conflicts.c
> trunk/subversion/svn/tree-conflicts.c
>
> Modified: trunk/subversion/libsvn_wc/tree_conflicts.c
> URL: http://svn.collab.net/viewvc/svn/trunk/subversion/libsvn_wc/tree_conflicts.c?pathrev=33792&r1=33791&r2=33792
> ==============================================================================
> --- trunk/subversion/libsvn_wc/tree_conflicts.c Mon Oct 20 16:17:50 2008 (r33791)
> +++ trunk/subversion/libsvn_wc/tree_conflicts.c Mon Oct 20 17:54:35 2008 (r33792)
> @@ -354,7 +354,7 @@ svn_wc__write_tree_conflicts_to_entry(ap
> len = strlen(path);
> if (len == 0)
> return svn_error_create(SVN_ERR_WC_CORRUPT, NULL,
> - _("Empty victim path in tree conflict description"));
> + "Empty victim path in tree conflict description");
>
> /* Escape separator chars while writing victim path. */
> for (j = 0; j < len; j++)
>
> Modified: trunk/subversion/svn/tree-conflicts.c
> URL: http://svn.collab.net/viewvc/svn/trunk/subversion/svn/tree-conflicts.c?pathrev=33792&r1=33791&r2=33792
> ==============================================================================
> --- trunk/subversion/svn/tree-conflicts.c Mon Oct 20 16:17:50 2008 (r33791)
> +++ trunk/subversion/svn/tree-conflicts.c Mon Oct 20 17:54:35 2008 (r33792)
> @@ -239,7 +239,7 @@ svn_cl__append_human_readable_tree_confl
> our_phrase = select_our_phrase(conflict, phrases);
> if (! our_phrase || ! their_phrase)
> return svn_error_createf(SVN_ERR_WC_CORRUPT, NULL,
> - _("Invalid tree conflict data for victim %s"),
> + "Invalid tree conflict data for victim %s",
> victim_name);
>
> /* Substitute the '%s' format in the phrases with the victim path. */
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: svn-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: svn-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Reporting internal errors [was: svn commit: r33792 - in
trunk/subversion: libsvn_wc svn]
Posted by Jens Seidel <je...@users.sf.net>.
On Wed, Oct 22, 2008 at 01:15:02PM +0100, Julian Foad wrote:
> On Tue, 2008-10-21 at 17:48 +0200, Jens Seidel wrote:
> > Nevertheless the intention should be to also display a proper localized
> > but more general error message if a very rare event happened (such as
[snip]
> > something like
> >
> > "An internal error occurred:
> > Either your repository or filesystem is corrupted or you found a bug.
> > If you suspect a bug, please send us the following error message:
> > "Value kjadfk72 ..."
> > "
> >
> > would be great.
>
> Yes. That is a very good suggestion for how to report internal errors
> and suspected data corruptions. This can be useful if the detailed
> message contains enough information to be more useful than simply a
> source flie name and line number would be.
Thanks.
> I chose to fix the particular messages that started this discussion in a
> different way in r33835, by replacing them with simple
> SVN_ERR_ASSERT/SVN_ERR_MALFUNCTION macros.
Yep, I have seen this already. I thought about an assert-like statement
when I wrote above.
> I committed your "U_" macro patch in r33836, and we can see if it
> becomes useful in practice.
If it isn't useful currently than there is no need to commit it :-)
Nevertheless I like your cleanup. It would be great if I (and others)
could save some time avoiding translating too many error messages.
Jens
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Reporting internal errors [was: svn commit: r33792 - in
trunk/subversion: libsvn_wc svn]
Posted by Julian Foad <ju...@btopenworld.com>.
On Tue, 2008-10-21 at 17:48 +0200, Jens Seidel wrote:
> let me add a note that I generally support translatable messages and
> this is also true for error messages. But if there is really no
> (real) possibility to see such an message it is just wasted time to
> translate it.
>
> Nevertheless the intention should be to also display a proper localized
> but more general error message if a very rare event happened (such as
> a database corruption). I'm not sure whether this happens currently
> or whether the user is confused with a very technical message.
>
> So instead of just printing
>
> "Value kjadfk72 in structure lahflh2 has value 27468 but not 27826 or 262"
Ha! Yes, that is what some of our error messages look like to a user.
> something like
>
> "An internal error occurred:
> Either your repository or filesystem is corrupted or you found a bug.
> If you suspect a bug, please send us the following error message:
> "Value kjadfk72 ..."
> "
>
> would be great.
Yes. That is a very good suggestion for how to report internal errors
and suspected data corruptions. This can be useful if the detailed
message contains enough information to be more useful than simply a
source flie name and line number would be.
I chose to fix the particular messages that started this discussion in a
different way in r33835, by replacing them with simple
SVN_ERR_ASSERT/SVN_ERR_MALFUNCTION macros.
I committed your "U_" macro patch in r33836, and we can see if it
becomes useful in practice.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r33792 - in trunk/subversion: libsvn_wc svn
Posted by Jens Seidel <je...@users.sf.net>.
On Tue, Oct 21, 2008 at 05:58:49PM +0200, Neels J Hofmeyr wrote:
> Jens Seidel wrote:
> > If you don't like it, please, please don't bother me and either improve
> > it later yourself or provide a proper text.
>
> Hey Jens, on this list, we bother each other all the time. I'm afraid you'll
> have to be bothered... :(
Maybe I wasn't clear enough: I just tried to ask you not to start a
large thread complaining about the log message as it happened already
often on this list.
If it isn't OK for you either provide a proper solution or change the
log yourself after it was committed.
Jens
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r33792 - in trunk/subversion: libsvn_wc svn
Posted by "Neels J. Hofmeyr" <ne...@elego.de>.
Yes, what he said.
Julian Foad wrote:
> On Tue, 2008-10-21 at 17:58 +0200, Neels J Hofmeyr wrote:
>> Jens Seidel wrote:
>>> If you don't like it, please, please don't bother me and either improve
>>> it later yourself or provide a proper text.
>
> Jens, thanks for taking the time to write the patch and the log message.
> I had a quick look and it looks good. And it really does help us, even
> if it seems like it would be such a small thing for somebody else to do
> it.
>
>> Hey Jens, on this list, we bother each other all the time. I'm afraid you'll
>> have to be bothered... :(
>
> Meaning: you'll have to be prepared to receive comments, and sometimes
> the comments will be more fussy than they need to be. Of course you
> don't have to bother to learn all of the project's habits and customs in
> detail if you don't want to.
>
>> Then again, you can just choose to not reply to messages, or say something
>> like "sorry, you might be right, but got no time right now".
>
> That's true. The way that you said "please, please don't bother me"
> sounded a bit strong, but at least we know how you feel now, and that's
> OK. I might not always remember this in future, so apologies in advance
> if I one day reply to you and say "That's not quite how we like it...".
>
> - Julian
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
--
Neels Hofmeyr -- elego Software Solutions GmbH
Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
phone: +49 30 23458696 mobile: +49 177 2345869 fax: +49 30 23458695
http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin
Handelsreg: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
Re: svn commit: r33792 - in trunk/subversion: libsvn_wc svn
Posted by Julian Foad <ju...@btopenworld.com>.
On Tue, 2008-10-21 at 17:58 +0200, Neels J Hofmeyr wrote:
>
> Jens Seidel wrote:
> > If you don't like it, please, please don't bother me and either improve
> > it later yourself or provide a proper text.
Jens, thanks for taking the time to write the patch and the log message.
I had a quick look and it looks good. And it really does help us, even
if it seems like it would be such a small thing for somebody else to do
it.
> Hey Jens, on this list, we bother each other all the time. I'm afraid you'll
> have to be bothered... :(
Meaning: you'll have to be prepared to receive comments, and sometimes
the comments will be more fussy than they need to be. Of course you
don't have to bother to learn all of the project's habits and customs in
detail if you don't want to.
> Then again, you can just choose to not reply to messages, or say something
> like "sorry, you might be right, but got no time right now".
That's true. The way that you said "please, please don't bother me"
sounded a bit strong, but at least we know how you feel now, and that's
OK. I might not always remember this in future, so apologies in advance
if I one day reply to you and say "That's not quite how we like it...".
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r33792 - in trunk/subversion: libsvn_wc svn
Posted by Neels J Hofmeyr <ne...@elego.de>.
Jens Seidel wrote:
> If you don't like it, please, please don't bother me and either improve
> it later yourself or provide a proper text.
Hey Jens, on this list, we bother each other all the time. I'm afraid you'll
have to be bothered... :(
Then again, you can just choose to not reply to messages, or say something
like "sorry, you might be right, but got no time right now".
And, if you're close enough, people usually just go on without bothering the
poster.
I asked you to post a complete patch suggestion because it takes a lot of
time off my pressing schedule to re-iterate the things you already know.
Hope we can hit a compromise, here.
~Neels
--
Neels Hofmeyr -- elego Software Solutions GmbH
Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
phone: +49 30 23458696 mobile: +49 177 2345869 fax: +49 30 23458695
http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin
Handelsreg: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
Re: Build system flaws (Was: Re: svn commit: r33792 - in trunk/subversion:
libsvn_wc svn)
Posted by Neels J Hofmeyr <ne...@elego.de>.
Jens Seidel wrote:
> a build error. This one was sufficient simple so that I thougth it would
> be optimal for starting contributing but I lost the interest without
> replies.
Yeah, it happened with me, too. I posted a patch and two weeks later no-one
had replied. Someone then said to me that the patch was probably not replied
to because no-one knew anything sensible to say about it at the time,
subversion being so large and complex. That helped me over the sort of
"naive disappointment" I felt... And now, basically a couple of weeks later,
I'm committing other people's patches already.
If I don't get replies, it helps me to just carry on in a relaxed frame of
mind, in subtle anticipation that someone out there, some release cycles
later, will discover the post and find exactly what she was looking for.
To me it looks like patches for mod_dav_svn, the build system and so on
usually aren't readily attended to, I guess because they require deep
insight into stuff most developers don't deal with most of the time.
Anyhow, I'm positive that all of your contributions are very much
appreciated by most of the developers (including me), even if one sometimes
gets a different impression. Thanks! And by any means, do continue!
~Neels
--
Neels Hofmeyr -- elego Software Solutions GmbH
Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
phone: +49 30 23458696 mobile: +49 177 2345869 fax: +49 30 23458695
http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin
Handelsreg: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
Build system flaws (Was: Re: svn commit: r33792 - in
trunk/subversion: libsvn_wc svn)
Posted by Jens Seidel <je...@users.sf.net>.
Hi Greg,
On Wed, Oct 22, 2008 at 01:48:41AM -0700, Greg Stein wrote:
> On Wed, Oct 22, 2008 at 12:49 AM, Jens Seidel <je...@users.sf.net> wrote:
> >> Few things in software development are as obnnoxious as 'make
> >> distclean' running configure.
> >
> > Can this happen in a automake based project? I thought it just called
> > clean and removes also config.h, config.log, ... but as long as
> > configure.ac or a dependent M4 file isn't touched configure shouldn't be
> > called!??
>
> Yes, this happens. You type "make clean", and automake will re-run
> configure,
yes, if an autotools related file was touched. Cannot remember that it
happened otherwise. It can be avoided using the macro AM_MAINTAINER_MODE
which disables the so called "rebuild rules" by default but I don't
like it.
But this becomes off-topic and autotools stuff is indeed very
complicated.
> which rebuilds the makefiles, and then it restarts the make
> clean. After about the third time it did this to me, I threw out
> Automake.
OK.
> > But the current build solution is OK until nobody objects (no, I'm mean,
> > if everyone agrees ("+1") to patches) if one tries to fix remaining errors
> > (such as no parallel make support during install, or depending on an
>
> Hadn't heard about a lack of parallel support. Interesting. Do you
> know what causes that, or is there a bug filed where I can see more?
No, sorry I didn't investigated it yet as I wanted to start with a more
simple bug. (The problem is at least reported in the link mentioned
below.)
To be honest the build system never worked for me as user flawlessly
since years. For most of my problems I found solutions or workarounds
via Internet search so I assumed you know about these.
Here I think again that the rule not to create bug reports if not
aggreed on this list is not optimal. But now I'm at a state where I'm
familiar enough with the development of Subversion to provide patches
for hacking.html ...
> > properly installed Subversion during "make install" (see e.g.
> > http://www.nabble.com/make-install-doesn't-install-td19177330.html which
> > contains even a minor patch which can be applied if
> > include/subversion-1/svn-revision.txt isn't used (which I think is
>
> Missed that thread last month.
And all others too? It's strange that nobody had any opinion about
a build error. This one was sufficient simple so that I thougth it would
be optimal for starting contributing but I lost the interest without
replies.
Maybe my email writing style wasn't good enough (no PATCH: tag, not
starting new threads but replying to existing ones, ...) ...
> > true))). And there is of course also the problem that installation isn't
> > just a simple
> >
> > ./configure
> > make
> > make install
> >
> > but has to deal with subcomponents (such as javahl) differently and in a
> > fixed order.
>
> It's a complex build system at this point.
The solution could be a simple extension of the default targets by
sub-targets. Haven't tested it though.
> Originally, not everybody
> wanted to build the bindings and things. But I think your suggestion
> is better: rather than separate targets, make then configure-time
> switches.
Yep.
Thanks for your comments,
Jens
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r33792 - in trunk/subversion: libsvn_wc svn
Posted by Greg Stein <gs...@gmail.com>.
On Wed, Oct 22, 2008 at 12:49 AM, Jens Seidel <je...@users.sf.net> wrote:
>...
>> > PS: Don't forget to call ./autogen.sh again. Don't know why autotools
>> > are not started by default after touching configure.ac. Argh, now I see,
>> > it's a autoconf project but not a automake one ... OK, this explains it.
>>
>> Few things in software development are as obnnoxious as 'make
>> distclean' running configure.
>
> Can this happen in a automake based project? I thought it just called
> clean and removes also config.h, config.log, ... but as long as
> configure.ac or a dependent M4 file isn't touched configure shouldn't be
> called!??
Yes, this happens. You type "make clean", and automake will re-run
configure, which rebuilds the makefiles, and then it restarts the make
clean. After about the third time it did this to me, I threw out
Automake.
> Based on my own experience I find autoconf (generates configure) much
> more difficult (at least the configuration: configure.ac, M4 handling)
> than automake (generated Makefile templates) with it's tiny
> Makefile.am's.
Agreed.
> But the current build solution is OK until nobody objects (no, I'm mean,
> if everyone agrees ("+1") to patches) if one tries to fix remaining errors
> (such as no parallel make support during install, or depending on an
Hadn't heard about a lack of parallel support. Interesting. Do you
know what causes that, or is there a bug filed where I can see more?
> properly installed Subversion during "make install" (see e.g.
> http://www.nabble.com/make-install-doesn't-install-td19177330.html which
> contains even a minor patch which can be applied if
> include/subversion-1/svn-revision.txt isn't used (which I think is
Missed that thread last month.
> true))). And there is of course also the problem that installation isn't
> just a simple
>
> ./configure
> make
> make install
>
> but has to deal with subcomponents (such as javahl) differently and in a
> fixed order.
It's a complex build system at this point. Originally, not everybody
wanted to build the bindings and things. But I think your suggestion
is better: rather than separate targets, make then configure-time
switches.
Cheers,
-g
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r33792 - in trunk/subversion: libsvn_wc svn
Posted by Jens Seidel <je...@users.sf.net>.
On Tue, Oct 21, 2008 at 07:13:30PM -0700, Eric Gillespie wrote:
> Jens Seidel <je...@users.sf.net> writes:
>
> > If you don't like it, please, please don't bother me and either improve
> > it later yourself or provide a proper text.
>
> Uh, wow.
Remember that this was related to log entry discussions not to the
patch.
> > PS: Don't forget to call ./autogen.sh again. Don't know why autotools
> > are not started by default after touching configure.ac. Argh, now I see,
> > it's a autoconf project but not a automake one ... OK, this explains it.
>
> Few things in software development are as obnnoxious as 'make
> distclean' running configure.
Can this happen in a automake based project? I thought it just called
clean and removes also config.h, config.log, ... but as long as
configure.ac or a dependent M4 file isn't touched configure shouldn't be
called!??
Based on my own experience I find autoconf (generates configure) much
more difficult (at least the configuration: configure.ac, M4 handling)
than automake (generated Makefile templates) with it's tiny
Makefile.am's.
But the current build solution is OK until nobody objects (no, I'm mean,
if everyone agrees ("+1") to patches) if one tries to fix remaining errors
(such as no parallel make support during install, or depending on an
properly installed Subversion during "make install" (see e.g.
http://www.nabble.com/make-install-doesn't-install-td19177330.html which
contains even a minor patch which can be applied if
include/subversion-1/svn-revision.txt isn't used (which I think is
true))). And there is of course also the problem that installation isn't
just a simple
./configure
make
make install
but has to deal with subcomponents (such as javahl) differently and in a
fixed order.
Jens
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r33792 - in trunk/subversion: libsvn_wc svn
Posted by Eric Gillespie <ep...@pretzelnet.org>.
Jens Seidel <je...@users.sf.net> writes:
> If you don't like it, please, please don't bother me and either improve
> it later yourself or provide a proper text.
Uh, wow.
> PS: Don't forget to call ./autogen.sh again. Don't know why autotools
> are not started by default after touching configure.ac. Argh, now I see,
> it's a autoconf project but not a automake one ... OK, this explains it.
Few things in software development are as obnnoxious as 'make
distclean' running configure.
--
Eric Gillespie <*> epg@pretzelnet.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r33792 - in trunk/subversion: libsvn_wc svn
Posted by Greg Stein <gs...@gmail.com>.
2008/10/21 Jens Seidel <je...@users.sf.net>:
>...
> PS: Don't forget to call ./autogen.sh again. Don't know why autotools
> are not started by default after touching configure.ac. Argh, now I see,
> it's a autoconf project but not a automake one ... OK, this explains it.
Yeah... we used automake a LOOOOONG time ago. I'll save you the rant.
It's harsh enough that I tossed our use of automake and created
gen-make, and haven't looked back yet (that was around May 2001, I
think?).
Cheers,
-g
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r33792 - in trunk/subversion: libsvn_wc svn
Posted by Jens Seidel <je...@users.sf.net>.
Hi,
let me add a note that I generally support translatable messages and
this is also true for error messages. But if there is really no
(real) possibility to see such an message it is just wasted time to
translate it.
Nevertheless the intention should be to also display a proper localized
but more general error message if a very rare event happened (such as
a database corruption). I'm not sure whether this happens currently
or whether the user is confused with a very technical message.
So instead of just printing
"Value kjadfk72 in structure lahflh2 has value 27468 but not 27826 or 262"
something like
"An internal error occurred:
Either your repository or filesystem is corrupted or you found a bug.
If you suspect a bug, please send us the following error message:
"Value kjadfk72 ..."
"
would be great. I nevertheless didn't address this with this patch.
On Tue, Oct 21, 2008 at 04:16:10PM +0200, Neels J. Hofmeyr wrote:
> Jens Seidel wrote:
> > On Tue, Oct 21, 2008 at 01:28:05AM -0700, Greg Stein wrote:
> >> Is there a way to mark the strings as "We made a conscious decision to
> >> not translate these" ? ... I fear that in a year or so, somebody will
> >> come along, notice they done have _() around them, and *add* it back.
> >
> > Of course! Just invent a new unused macro similar to _() and mark the
> > text with it. Maybe I_() for internal or U_() for unused?
>
> Nice idea!
> U_() for "untranslatable"? ;)
OK, let's use U_().
> Jens, how about posting a patch for these things? It does take kind of
> longish at first, but all the work you do then doesn't need to be taken over
> by others, and they don't need to go search for stuff as you already did.
OK, I attached one. I don't like dealing with log messages but here is a
attempt:
[[[
Mark messages not useful for translation with U_(). This avoids that a
gettext call is later added accidentally again.
* subversion/svn_private_config.hw
configure.ac:
Define a new macro U_() to mark untranslatable strings similar to _().
* subversion/svn/tree-conflicts.c
(svn_cl__append_human_readable_tree_conflict_description)
subversion/libsvn_wc/tree_conflicts.c
(svn_wc__write_tree_conflicts_to_entry):
Use U_() for two strings with removed _() wrapper in r33792.
* www/hacking.html
notes/l10n-problems: Document U_().
]]]
If you don't like it, please, please don't bother me and either improve
it later yourself or provide a proper text.
> You probably know this already...
Yep.
> of your working copy. -- but wait, you're on windows, right? :/
Of course NOT (it doesn't have a proper license and even in ReactOS
I miss the Unix flair :-)).
PS: Don't forget to call ./autogen.sh again. Don't know why autotools
are not started by default after touching configure.ac. Argh, now I see,
it's a autoconf project but not a automake one ... OK, this explains it.
Jens
Re: svn commit: r33792 - in trunk/subversion: libsvn_wc svn
Posted by "Neels J. Hofmeyr" <ne...@elego.de>.
Jens Seidel wrote:
> On Tue, Oct 21, 2008 at 01:28:05AM -0700, Greg Stein wrote:
>> Is there a way to mark the strings as "We made a conscious decision to
>> not translate these" ? ... I fear that in a year or so, somebody will
>> come along, notice they done have _() around them, and *add* it back.
>
> Of course! Just invent a new unused macro similar to _() and mark the
> text with it. Maybe I_() for internal or U_() for unused?
Nice idea!
U_() for "untranslatable"? ;)
"unused" wouldn't quite be right.
> (N_() is already in use.)
>
> This way it would also be possible to later tell xgettext to extract
> these messages (e.g. into a separate PO file) if this is wanted
> in some rare cases (e.g. for some language teams).
>
> Affected file would be (search for gettext)
> configure.ac
> subversion/svn_private_config.hw
Jens, how about posting a patch for these things? It does take kind of
longish at first, but all the work you do then doesn't need to be taken over
by others, and they don't need to go search for stuff as you already did.
You probably know this already... Multiple working copies are a good thing.
Just file-system-copying your working copy and `svn revert -R .' on the copy
is a quick way to get a new, clean working copy. Make some changes, how
feeble they may be, and just post the output of `svn diff' run in the root
of your working copy. -- but wait, you're on windows, right? :/
~Neels
>
> Jens
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
--
Neels Hofmeyr -- elego Software Solutions GmbH
Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
phone: +49 30 23458696 mobile: +49 177 2345869 fax: +49 30 23458695
http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin
Handelsreg: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
Re: svn commit: r33792 - in trunk/subversion: libsvn_wc svn
Posted by Jens Seidel <je...@users.sf.net>.
On Tue, Oct 21, 2008 at 01:28:05AM -0700, Greg Stein wrote:
> Is there a way to mark the strings as "We made a conscious decision to
> not translate these" ? ... I fear that in a year or so, somebody will
> come along, notice they done have _() around them, and *add* it back.
Of course! Just invent a new unused macro similar to _() and mark the
text with it. Maybe I_() for internal or U_() for unused?
(N_() is already in use.)
This way it would also be possible to later tell xgettext to extract
these messages (e.g. into a separate PO file) if this is wanted
in some rare cases (e.g. for some language teams).
Affected file would be (search for gettext)
configure.ac
subversion/svn_private_config.hw
Jens
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org