Re: [Po4a-devel]Non breaking spaces in man pages
Hi,
On Wed, 16 Feb 2005, Nicolas François wrote:
I think it is important: when used in a macro argument, "\
" permits to
continue the same argument. For example:
.BI foo bar
has two arguments, the first one in bold face, the second one in italic
(and they are displayed joined).
Whereas:
.BI foo\ bar
only consist in one argument and is displayed as "foo bar" in bold face.
Thanks for the explanation.
[...]
Thanks for the example. I can reproduce it (I didn't tried the
ascii
charset)
The conversion of '\ ' to 0xA0 was done because some french translators
used the latin-1 non-breakable space in PO, and it was useful for them to
convert the 0xA0 char in the PO to a '\ ' in the man page (otherwise there
is others warnings).
Is there a way to enter non-breaking spaces from the keyboard? Or did they
use some special software that diferentiates both kinds of spaces?
What I propose is to keep the conversion of 0xAO to '\ ' in
post_trans,
but remove the opposite conversion in pre_trans. Thus PO will be valid and
translators will be able (at their will) to use 0xA0 in the msgid (and
will have to set a correct charset in the header).
If I understood it well, it would be compatible with existent po files,
but the newly created files would have "\ " instead of 0xA0? (I would like
this approach)
Do you think we may keep the 0xA0 if the user specified an
$self->{TT}{'file_in_charset'} = UTF-8 or latin-1
(should we then check in_charset or out_charset ?)
It's the first time I see 0xA0, so I don't know many things about it. I
see it like a strange character, hard to diferentiate from the standard
space in classic editors (correct me if I'm wrong). Personally I prefer
having "\ " everywhere instead of 0xA0, independent from the character
set.
I'm also asking this for the TeX module (there I'm doing
translation of
accentuated characters, i.e. \'e in the TeX file becomes é in the PO which
is then translated again to \'e in the TeX file).
This is a different case because it's easy to diferentiate a 'e' from a
'é' (both visually when reading and when writing each one).
Apart of this, I'll try to have a look at this conversion, because this
introduces undetected non-ascii characters (which should force the po file
to be in utf-8).
These translations are, IMHO, user friendly (when it does not break
the
PO ;). They also help spell checkers or syntax checkers (acheck): for
example, in French a ';' has to be preceded by a non-breaking space...
Oops, I didn't know that rule.
Regards,
Jordi Vilalta