Re: Source code encoding detection modifications for intltool

--+pHx0qQiF2pBVqBT
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2003-07-15(Tue) 13:26:12 +0200, Carlos Perell=C3=B3 Mar=C3=ADn wrote:
> > An unexpected failure -- currently escaped hex values (\x??) are not
> > handled. Source code with such strings should most likely use
> > --from-code=3DUTF-8 too, but "file" detects them as either ASCII or ISO=
-*
> > files. (mlview/src/mlview-app.c for example)
>=20
> Well, if it's detected as an ASCII file, we can use without problems the
> UTF-8 encoding, the problem is if it detects it as an ISO-* because
> there are characters that are not valid UTF-8 characters...
>=20
> Ideas to "fix" it?
> Assume that all files are using UTF-8 is not the correct behavior...

I've been thinking about something like this:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
[deaddog@localhost CVS.GNOME.ORG]$ cat mlview/po/POTFILES.in
{...... comment here .......}
[encoding: UTF-8]
{......}
src/mlview-attribute-picker.c
src/mlview-app.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

That is, explicitly specify the encoding of source files in POTFILES.in,
so that intltool can use this value to avoid autodetecting file
encoding. Is there any better possible solution?

Abel

--=20
Abel Cheung
Linux counter #256983   | http://counter.li.org
GPG Key: (0xC67186FF)   | http://deaddog.org/gpg.asc
Key fingerprint: 671C C7AE EFB5 110C D6D1  41EE 4152 E1F1 C671 86FF

--+pHx0qQiF2pBVqBT
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/FQgiQVLh8cZxhv8RAv0LAKDa+bh0p1dq46QR/8HGcQy406x+RACguCaF
zwM4oggNIJYkWN9up13vPLk=
=IjpI
-----END PGP SIGNATURE-----

--+pHx0qQiF2pBVqBT--