Re: [PATCH] proper indentation in merge conflict menu

On Fri, Jun 06, 2008 at 09:49:28AM +0200, Jens Seidel wrote:
> On Thu, Jun 05, 2008 at 06:17:17PM -0400, Karl Fogel wrote:
> > Instead, perhaps we have to write multiline prompts in a way that allows
> > translations to work regardless of word length. I don't think counting
> > characters is the way to go, unless there's no other solution.
>
> Don't understand what's wrong with counting ... But it may indeed result
> in clumsy code.

The reason that it makes sense to do it in the cases you found is that
the code prints different parts of the menu depending on certain flags.
So the code assembles the whole menu from different pieces. The pieces
get translated individually and therefore each have different and unknown
length.

And you are right about clumsy code! "Counting characters" is very fragile.
BTW, if you look closely at my patch, you can see that "counting characters"
is actually not the proper term -- in some languages single characters
can take up more than one terminal column when printed. So instead of
"counting characters" we should probably say "determining string width
at run time."

Note that probably not all systems we support have wide chars, so on
these the indentation will still be wrong with the "run time" method.
I think it would be better to find some way to specify the amount of
indentation required in the data set (i.e. the strings) instead, and
to have the code be as stupid as possible ("just print it").

What about maintaining multiple full text menus? The code could use
a full text menu for each case it encounters, instead of building
up a suitable menu from several pieces. This would create some redundancy,
but would make the indentation work in all cases. After all, if
translators translate a full menu for each case, they can get the
indentation correct in all cases, right?

> > Do you know of any other places in Subversion that have this problem?
>
> There are really many strings which need to be tested live (not just by
> proofreading the PO file).

This is very unfortunate. Doesn't gettext provide some way to deal
with these kinds of problems? How do other projects handle this?

Stefan