Re: Fichier po de debconf et UTF-8
Le jeudi 8 mai 2003, Jérôme Marant écrit :
> Rebonjour,
Bonsoir, (re-),
> Encore une interrogation sur UTF-8.
>
> Ne serait-ce pas faire un progrès que de fournir dès à
> présent à la fois une version iso-8859-1 ou -15 et une
> version UTF-8 des templates debconf (respectivement
> fr.po et fr.UTF-8.po) si nous souhaitons encourager
> le passage à UTF-8?
>
> Pour ce faire, il suffit d'utiliser msgconv fourni avec
> la glibc : msgconv -t UTF-8 input_file > output_file
> Il n'y a pas d'effort supplémentaire à fournir.
>
> Je pense qu'il faudrait le faire pour les .po en général
> mais je dépasse le cadre du projet.
bon j'ai trouvé msgconv dans ma sid chrootée, j'ai fait un petit test et
ça ne marche pas, en tout cas pour ce que je cherche à faire pour le
ddts. Voici ce que j'ai envoyé à Grisu, sans réaction pour le moment :
Subject: iconv from iso-8859-15 0xBD (unicode 0x153) to non-existing iso-8859-1 fail
Le mardi 8 avril 2003, Nicolas Bertolissio écrit :
> Hi,
>
> I found the bug, this is because iconv cannot convert a character from
> iso-8859-15 to iso-8859-1
>
> applicatif entièrement mis en œuvre au sein de vat : vous n'avez besoin d'aucune
> ^
>
> this character is œ but does not exist in iso-8859-1.
>
> I don't know how we can fix this bug for the moment. We could store all
> descriptions in utf8 but we would have the same trouble when sending a
> description in iso-8859-1 as convertion from utf8 would not be possible.
Hypothesis:
===========
For the necessity of an example let's say we want to use iso-8859-15 but
translations are stores in iso-8859-1 and we look particularly at
character 0x153 (unicode) which doesn't exist in iso-8859-1 but can be
recoded as 'oe' and which exists in iso-8859-15 as 'œ' (0xBD).
Facts:
======
If someone send back an iso-8859-15 encoded translation, 'iconv' fails
converting 0xBD to iso-8859-1 as this character doesn't exists in
iso-8859-1.
Possible solutions:
===================
- use 'recode' instead of 'iconv'
it will successfully convert from iso-8859-15 0xBD to iso-8859-1 'oe'
problem: this doesn't work the other way, iso-8859-1 'oe' is recoded
as iso-8859-15 'oe'
- use utf8 for translated descriptions
all conversions from iso-8859-1 or iso-8859-15 to utf8 will succeed
problem: 'iconv' will fail to convert unicode 0x153 to iso-8859-1 as
this character doesn't exist
So both theses solutions are not acceptable.
Last one I thought about:
Use utf8 AND 'recode'
=====================
sending translation:
--------------------
conversions from unicode 0x153 to iso-8859-15 0xBD and to iso-8859-1
'oe' will both succeed so we can send data in any requested encoding.
receiving trnaslation:
----------------------
conversion from iso-8859-15 0xBD to utf8 will be unicode 0x153 so
comparision between database translation and received one will match in
utf8.
conversion from iso-8859-1 'oe' to utf8 will be unicode 'oe', so
comparision between database translation and received one will NOT
match in utf8.
So we cannont use utf8 for comparison.
But as conversion FROM unicode 0x153 will be either iso-8859-15 0xBD or
iso-8859-1 'oe', we can use the received encoding for comparison as it
will match.
Troubles:
---------
yes, there are some :(
- If a translator uses iso-8859-1 'oe', it will be stored as unicode
'oe' in the database but if a reviewer uses iso-8859-15, unicode 'oe'
will be sent to him as iso-8859-15 'oe', he will certainly change it
into iso-8859-15 0xBD so a bug will be issued with unicode 0x153. The
bug will be send in iso-8859-1 'oe' so with no difference for the
translator.
If he accepts the changes (he cannot see), the database will be
updated with unicode 0x153 and all is fine.
BUT: If he just closes the bug, certainly the reviewer will send back
the same review and this is an endless circle.
Review comment may help for this, but reviewers will have to write
them, we cannot automake them.
- When a bug report is issue, it will always be issued in iso-8859-1 so
even if the translator uses iso-8859-15 he will receive an iso-8859-1
'oe' and HAVE TO change it back into iso-8859-15 0xBD.
One possible solution for this last one is to store the
translator/reviewer encoding in a new database so we can issue the bug
report with the right encoding.
Any comment?
Donc, c'est juste une idée pour le moment, mais c'est peut-être,
sûrement pas la bonne liste pour en discuter.
Mais les commentaires sont les bien venus.
Nicolas
--
Reply to: