Re: git: problematic git status output with some translations (such as fr_FR)

From: Raphael Hertzog <hertzog@debian.org>
Date: Jan 16, 2014, 22:00 UTC
Message-ID: <20140116220045.GA18773@x230-buxy.home.ouaza.com>
In-Reply-To: <CACsJy8Cw+YpG3C8PFuBOddDWLTBZB=bHDFBtTwYzLO=1a15LuA@mail.gmail.com>

Hi,

On Fri, 20 Dec 2013, Duy Nguyen wrote:

Show 15 quoted lines

> On Fri, Dec 20, 2013 at 3:50 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> > Junio C Hamano wrote:
> >> Jonathan Nieder <jrnieder@gmail.com> writes:
> >
> >>> This includes the colon in the translated string, to make it easier to
> >>> remember to keep the non-breaking space before it.
> >>
> >> Hmph, recent 3651e45c (wt-status: take the alignment burden off
> >> translators, 2013-11-05) seems to have gone in the different
> >> direction when it updated similar code for the non-unmerged paths.
> >
> > Yes, if this seems to go in the right direction, I'd add a follow-up
> > for that when rerolling.
> 
> i'm fine either way.

In both cases, the alignment burden is taken off the translators. But I agree that it's best to keep the colon in the translatable string so that translators can add the space required by proper typography.

So I'd favor Jonathan's approach. I just tested his patch and it solves the immediate problem for me. Without the patch I have this (French translation):

| Chemins non fusionnés :
|   (utilisez "git add <fichier>..." pour marquer comme résolu)
| 
| 	modifié des deux côtés :fichier

And with it:

| Chemins non fusionnés :
|   (utilisez "git add <fichier>..." pour marquer comme résolu)
| 
| 	modifié des deux côtés :     fichier

However it looks like the padding is calculated on bytes and not on (wide) characters, so we have 3 extra spaces before the filename (one for ô, é, and the non-breaking space). This can be problematic for translations where all characters require multiple bytes. :-)

The patch is also incomplete since it currently breaks the test suite in multiple places (the unnecessary padding before the filename goes away), for example:

--- expected 2014-01-16 21:37:11.270535950 +0000 +++ actual 2014-01-16 21:37:11.270535950 +0000

@@ -5,7 +5,7 @@
 Unmerged paths:
   (use "git add/rm <file>..." as appropriate to mark resolution)
 
-	both added:         conflict.txt
-	deleted by them:    main.txt
+	both added:      conflict.txt
+	deleted by them: main.txt
 
 no changes added to commit (use "git add" and/or "git commit -a")
not ok 11 - status when conflicts with add and rm advice (deleted by them)


That was my two euros to help get this fixed because it annoys me
quite often.

Cheers,

-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/