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