Comment 12 for bug 608631

Le lundi 02 août 2010 à 19:42 +0000, verdy_p a écrit :
>
>
> > Message du 02/08/10 10:21
> > De : "Nicolas Delvaux" <email address hidden>
> > A : <email address hidden>
> > Copie à :
> > Objet : [Bug 608631] Re: Visual tag to represent narrow non-breaking spaces
> >
> >
> > Yes, fundamentally we may replace all [nbsp] by nnbsp.
> >
> > But currently nnbsp is not widely used or even known, it's not even on
> > our translation guidelines (eg gnome-l10n-fr, lp-l10n-fr, ubuntu-l10n-
> > fr...; even if these last 2 will surely change when this bug will be
> > fixed).
> >
> > As said in the first post and by verdy_p, even if nnbsp support seems to be ok now, there might be some bugs with
> some fonts or rendering engines.
> > And as nnbsp support is quite new in modern browsers, we may need to fallback on [nbsp] for webapps (to support IE
> 6/7 or such horrible things).
> >
> > So I think that [nbsp] is still needed for compatibility purpose.
>
> Why? applications that don't support NNBSP can replace them automatically when exporting from Launchpad. Translators
> won't have any issue, as the datbase will internally store NNBSP in its history. And there will be no difficulty to
> enter it (there's already a way to input NBSP in the editor so that it is preserved in the input form, to avoid the
> browser bugs that replace them by standard spaces. So they will be clearly visible.
>
> And applications that are using resources can also preprocess the returned texts before using them, if their
> renderer cannot support this character. note also that browser shave made very significant progresses during the
> last months, and because of security issues, almost all users are forced to update their browser as soon as
> possible. Who uses now a deprecated browser version ? Browsers are integrating the support of NNBSP even if the
> selected font does not support it (in fact this support is now part of its text renderer or text layout engine).
This may require much more work than to simply keep [nbsp] for a
while...

We can start using [nbthin] everywhere and, if we find that it causes
trouble in some apps, we can use instead [nbsp] while the underlying bug
is being fixed.

This may be longer but IMHO this is easier.

> > About a "graphical" display, this is a good idea.
> > But, unlike spaces or newlines, all keyboard layout do not have a mapping for nnbsp.
> > So it may still be necessary to input nnbsp via [nbthin] in some cases.
>
> Not needed. In the online editor of Lauchpad you'll see [nbthin], exactly like you currently see [nbsp]. You don't
> need any special keyboard assignment for entering [nbsp], as this is part of the Javascript support integrated in
> the Launchpad edit form.
>
> If some users can type NNBSP directly with their custom keyboard layout, no problem: the editor will still dispaly
> the colored [nbthin] indicator. same thing if they are copy-pasting texts in the editor.
>
> And anyway in the exports, such characters would be represented in the
> .po file as \u2009.
Yes, this is exactly what my patch implements. ;-)

But, as an addition, a "visual tag" to represent [nbsp] or [nbthin]
would be great too.
The current implementation is not clear for beginners, I see quite often
translated strings (eg "Bonjour[nbsp]!") with newly proposal with a
standard space instead of "[nbsp]".

With a small picture to represent it, it may be clearer and, by
questioning the user, it may encourage him to read translations
guidelines.

(perhaps this need a specific bug report?)