[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] proper indentation in merge conflict menu

From: Jens Seidel <jensseidel_at_users.sourceforge.net>
Date: Fri, 6 Jun 2008 17:07:51 +0200

On Fri, Jun 06, 2008 at 04:37:39PM +0200, Stefan Sperling wrote:
> On Fri, Jun 06, 2008 at 03:56:57PM +0200, Jens Seidel wrote:
> > On Fri, Jun 06, 2008 at 03:06:42PM +0200, Stefan Sperling wrote:
> > > Note that probably not all systems we support have wide chars, so on
> >
> > I think one such system is cygwin.
> >
> > > What about maintaining multiple full text menus? The code could use
> >
> > I do not like text duplication. I have to translate it consistently.
>
> We're currently talking of about 5 or 6 full text prompts that will share
> most of their text. Each being about 3 lines long. I think this is a
> negligible amount of additional translation overhead, considering that
> it buys us consistent indentation for all languages on any platform
> we support. And it keeps the code's complexity at the same level as it
> currently is.

Mmh, OK. Nevertheless it is generally always preferred to have many
small texts instead of fewer but larger ones. This reduces the risk
for fuzzy strings (you change a minor part in a message and the
whole text is affected, needs to be retranslated) and could easily
allow reusing texts in different contexts.

> > Also formating strings should be factored out, e.g. via a format string
> > such as "%s (%c) %s" where the first %s is some kind of space, %c could
> > be a shortcut and %s the menu text. So one would need to translate this
> > format specification only once and with a minor single change all lines
> > (and maybe even different menus) can be adjusted at once.
>
> I'm OK with this. But it works only as long as we don't need
> the exact same format string for something else which is
> internationalised as well, right?

This would be no problem. If someone noticed that two identical strings
(e.g. "count" and "count") require different translations depending on
content one used a special function which ignored some parts of text.
For example:
P_("as used in phrase1|count")
P_("as used in phrase2|count")

const char *P_(const char *Text)
{
  const char * const translation = gettext(Text);
  const char * const stripto = strchr(translation, '|');

  if(stripto == NULL)
    return translation;
  else
    return stripto+1;
}

Translations: "as used in phrase1|count" ==> "Anzahl"
              "as used in phrase2|count" ==> "Zahl"

Newer gettext version provide a dpgettext function that takes a context
argument.

> > Using some kind of format string could help. Some
> > libraries such as Qt use layout classes such as QVBox and QHBox
> > and align all childrens of these vertically or horizontally,
> > respectively. Complex layout can now be created by nesting these:
> > QVBox(QHBox(%s), QHBox(QVBox(%s))).
>
> I know you're not suggesting to, but I guess pulling in QT as
> a dependency to solve this issue is out of question :)

But an *own* format handling which fulfills svn needs would do it. I'm not
proposing this but the help message could be described by the following syntax:

(%B starts a block mode, %b ends it. Text in block mode will be breaked after
a fixed column at whitespaces and the indentation is kept.)

%command_name: %s.
usage: %s

 %B%s%b

Valid options:
  %s %move_to_column(15):%B%s%b

Jens

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-06-06 17:11:19 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.