Comment 27 for bug 608631

An update about this...

I ran many tests last month and I made a report about the narrow no-break space support in the free software ecosystem.
It's in French so I'm not sure it's useful in this bug report, but you can find the PDF here: http://malaria.perso.sfr.fr/fines/
(of course we discuss it on some l10n-teams mailing-list)

So, the important thing I noticed is that some toolkits/environments have rendering bugs but some just work.
All important bugs were reported (mainly Qt: http://bugreports.qt.nokia.com/browse/QTBUG-13280 ) and I fixed another (KBD/TTY: http://git.altlinux.org/people/legion/packages/kbd.git?p=kbd.git;a=commit;h=50f674d1775bc75f799c583b887c3329088ff620 ).
So, the situation is getting better.

But the interesting part (at least for this bug report) is mainly that all GTK apps support the narrow no-break space (on GNU/Linux, on Windows XP/Vista/Seven...).
So all GTK apps that host their translations on Launchpad could start using it now... if this bug get a fix.

Do you really need that a project as huge as Gnome starts to use nnbsp widely to just implement a fix?
(anyway, I will argue in favour of it's adoption in Gnome at the beginning of the next cycle)

Otherwise, I also noticed that there is in fact no easy way to input a nnbsp with Windows (it requires to mess around with REGEDIT...) and also that there is no short-cut for it on GNU/Linux with a Canadian layout (I have to verify this last one).
So we really need a tag such as [nbthin] to workaround those input problems.

The patch I submitted just add 6 lines to the code (I don't take documentation into account).
The code is the same that with other tags, so I can't imagine how it can break something that may have not break without it.
Could you please re-consider your opinion on this?