Comment 30 for bug 608631

Revision history for this message
Nicolas Delvaux (malizor) wrote : Re: [Bug 608631] Re: Visual tag to represent narrow non-breaking spaces

> You are just having trouble inputting it, and I haven't seen conclusive
> evidence suggesting browsers don't support it.

Oh, sorry, I did some testing with web browsers too (indeed, I forgot to
add this critical part in my previous comment, shame on me)
Here are some non working browsers (screenshots are in French, so please
read "nnbsp" instead of "espace fine insécable" ;-)):

- Up to Internet Explorer 8 on Windows Xp (and predecessors) → it
display a square instead of a nnbsp
( http://malaria.perso.sfr.fr/fines/images/fines_IE8_xp.png )
(note that it works with Vista and Seven, here the bug is in the OS
build-in renderer not in the browser itself)

- Because of a bug in Qt
( http://bugreports.qt.nokia.com/browse/QTBUG-13280 ) no Qt browser
currently support nnbsp: nothing is displayed.
I tested with konqueror
( http://malaria.perso.sfr.fr/fines/images/fines_konqueror.png ) and
Rekonq ( http://malaria.perso.sfr.fr/fines/images/fines_rekonq.png )

Same bug with Safari on Mac OS for example.

Basically, nnbsp is currently well supported in Firefox (all OS) and in
all GTK browsers (I did not test, but I was told that Chrome support it
too).
You can try your browser with this web-page for example:
http://malaria.perso.sfr.fr/fines/test_nnbsp.html

So, we may reasonably think that a tag may be needed for both input and
display of the nnbsp char. ;-)

> I am simply not convinced: as someone who has worked on Serbian
> localization from the ground-up for free software, I am familiar with
> what it takes to get special characters supported in translations. For
> instance, Serbian uses „these“ kind of quotes. No keyboard layout other
> than the Serbian keyboard layouts in XFree and X.org support it (which I
> helped develop). The way to fix a problem of the missing characters is
> to enable their input: if the character is the right one to use, why
> should you not use it as part of your daily input in French? (if you
> don't like my example, think of many other Unicode characters that are
> typographically more appropriate for text, but rarely used: em- and
> en-dashes, minus, ellipsis, etc)

But nnbsp is a special case.
Here reviewers need to figure out if the space in "Test !" is a nnbsp or
a regular space.
It's indeed doable without a tag, but you need a compatible browser, no
fixed-width font and you also need trained eyes.

It's really not comparable with „these“ ;-)

> Is it not something that could be automatically produced instead? For
> example, perhaps a simple post-processing step on French .po files
> export would do the trick? Would such post-processing be possible (iow,
> is it well defined)?

Well, perhaps it's doable.
But it can't be automatic for now, at least because not all frameworks
(mainly Qt) support nnbsp.

And, personally, I prefer translating things the good way directly.
Such an automation should just warn the user that he might has forgotten
something at line X, otherwise the translator should be trusted.
(anyway, it's a bit off-topic)

> The patch you submitted is not really complete. And it touches stuff it
> shouldn't touch. But, I am sure we can get it in order for landing.
> And then, if it ends up in Launchpad, what's to guarantee that:
> - it will receive widespread use

→ At least now we know what work and what don't.
GTK (but also XUL, wxWidget and Tcl/Tk) apps seems to be a kind of good
start. Then it's use can only spread (and it may also accelerate the fix
of remaining support issues).

> - we'll know what to do with it in the future

→ Well, use it even more!
French official typographic rules won't change in the near future, the
nnbsp usage can only grow as the technical barrier diminish.

And if, for some really unexpected reasons, no one use nnbsp in the
future, just drop the patch!

> - we won't keep getting requests for characters for specific languages
> simply because people don't want to solve the problem at the right level
> (i.e. keyboard input)

So this is not only an input problem.
And if it was, do you know an easy way to patch Windows to add a
shortcut for nnbsp in all layouts that need it?

Not all projects hosted on Launchpad are GNU/Linux only, Windows support
can't be forgotten here (and it's currently easier to input a nnbsp with
a Canadian layout on GNU/Linux than with any French layout on Windows).

> Also, let me repeat another thing: if [nnbsp] is the right thing to
> use
> *instead* of [nbsp], then we should get rid of the support for [nbsp]:
> there's no reason to make it easier to input a character that should
> not
> be used! (I know it'd be nice to keep it for compatibility reasons,
> but
> I am just pointing at what I believe is logical)

Because nnbsp is mainly usefull in French or (for example) for the short
form of the Czech dates.

nbsp can be (and are) used in any language. You may often want to use it
to just prevent a line break between special words.
It can be for multiple-word, proper names (you should write Mac[nbsp]OS
for example) or just for style.

So dropping [nbsp] is really a bad idea IMHO.
And even if you think that it's usage is too negligible, you should keep
compatibility too because all translators won't just drop [nbsp] one day
to use [nbthin].
I understand your concern about "making easier to input something that
should not be used", so drop the *input* part if you want when there
will be no more problem with nnbsp support, but at least keep a visible
tag to distinguish [nbsp] from a white space.

However, I'm really sorry to have forgotten browsers tests in my
previous comment (so you might want to re-re-consider your opinion ;-))