Re: Some problematic strings in Subversion

Stefan Sperling wrote:
> Since I speak German, let me make a suggestion which does not have
> the same negative connotations as the literal translation "Opfer":
> "(vom Baumkonflikt) betroffenes Objekt"

"Baumopfer"
rofl! :)

But I'm not sure "Objekt" is a good translation, unless it's already widely
used.

Ich sehe keinen Grund, warum das praktische englische Wort "victim"
unbedingt beibehalten werden muss. Im Grunde ist es ja eine widersprüchliche
Änderung an einem bestimmten Pfad, insofern könnte man auch sagen:

 ("%s is a tree conflict victim")
  "%s ist durch einen Baumkonflikt gefährdet"
                                   betroffen
                                   kompromittiert"
         "an einem Baumkonflikt beteiligt" (lol)

  "%s verursacht einen Baumkonflikt"
     "hat einen Baumkonflikt verursacht"

  "Baumkonflikt bei %s"

With tree-conflicts, there is no clear notion of who *is* the culprit,
there's just two happy hackers doing different things to the same node by
accident.

Stsp, is there a philosophy behind the phrase "%s is a tree-conflict
victim", or would you also accept "%s caused a tree-conflict" or "There is a
tree-conflict at %s" in English?

Maybe we should change this if it also makes many other translations so much
easier? Who knows about this stuff?

[[[
#: ../libsvn_wc/tree_conflicts.c:357
msgid "Empty victim path in tree conflict description"
#: ../svn/tree-conflicts.c:242
#, c-format
msgid "Invalid tree conflict data for victim %s"
]]]

These are really difficult and other translators are likely to go off at
tangents. As you guys discussed, they are only fatal failures that occur
when the working copy is corrupt. Making them non-translatable in r33792.

>
> Would that do?
>
>> #: ../libsvn_wc/tree_conflicts.c:357
>> msgid "Empty victim path in tree conflict description"
>> #: ../svn/tree-conflicts.c:242
>> #, c-format
>> msgid "Invalid tree conflict data for victim %s"
>>
>> PS: The German translation in trunk is now up-to-date (except two
>> strings). Will merge it into 1.5.x soon ...
>
> Great!

Good work, Jens!

>
>> Index: subversion/svn/notify.c
>> ===================================================================
>> --- subversion/svn/notify.c (Revision 33718)
>> +++ subversion/svn/notify.c (Arbeitskopie)
>> @@ -83,7 +83,7 @@
>>
>> if (nb->skipped_paths > 0)
>> SVN_ERR(svn_cmdline_printf
>> - (pool,_(" Skipped paths: %u\n"), nb->skipped_paths));
>> + (pool,_(" Skipped paths: %u\n"), nb->skipped_paths));
>
> Nice catch! But it should be:
>
> - (pool,_(" Skipped paths: %u\n"), skipped_paths));
> + (pool, _(" Skipped paths: %u\n"), skipped_paths));

Uh what? s/nb->// ? And the indentation?

>
> Committed in r33784.

$ svn diff -c 33784
Index: subversion/svn/notify.c
===================================================================
--- subversion/svn/notify.c (revision 33783)
+++ subversion/svn/notify.c (revision 33784)
@@ -107,7 +107,7 @@

   if (skipped_paths > 0)
     SVN_ERR(svn_cmdline_printf
- (pool,_(" Skipped paths: %u\n"), skipped_paths));
+ (pool, _(" Skipped paths: %u\n"), skipped_paths));

   return SVN_NO_ERROR;
 }

Well, everything seems to be in order after all.

>> - "Dump the contents of filesystem to stdout in a 'dumpfile'\n"
>> + "Dump the contents of the repository to stdout in a 'dumpfile'\n"
>
> 'svnadmin dump' really *only* dumps the filesystem! No config files,
> no locks, no hook scripts, etc.
>
> I'd strongly suggest we really make it dump the whole repository before
> changing this message.

Filed issue #3299.
http://subversion.tigris.org/issues/show_bug.cgi?id=3299

~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