Re: [Libexif-devel] pl.po update for libexif and exif 0.6.15, some NLS notices

[Hans U. N. <gp...@n-...>]

Jakub Bogusz wrote:

> I updated pl.po files for libexif and exif 0.6.15; as new .pot files

Thank you!

> weren't uploaded to GNU TP, I cannot send updated translations through
> GNU TP - but they are available at:
> 
> http://mail.qboosh.pl/pl.po/libexif-0.6.15.pl.po
> http://mail.qboosh.pl/pl.po/exif-0.6.15.pl.po

GNU TP will have to wait for the next release, I guess. I have no idea
how it works so far, anyway :)

> And some notices:
> 
> 1. Message in exif/main.c:55 contains extra ')' character.

I'll look at that.

> 2. Since libexif no longer binds its codeset to UTF-8, it returns
> strings in native encoding; trying to convert them from UTF-8 in
> exif/exif-i18n.c breaks them; simply omitting iconv() call removes the
> problem.
> But I suppose that gtk+2 applications using libexif (like gexif) won't
> be happy getting non-UTF strings either... maybe libexif should have
> some function to set its output encoding?

There are two kinds of libexif users: a) console apps and b)
GTK/Qt/whatever apps.

Console apps require the default encoding, GTK/Qt/whatever apps (may)
want a locale independent encoding, probably UTF-8.

Given that we are currently having quite a mess of encodings within
libexif anyway, we need to do a clean solution here. It will entail a
function to set the encoding an application expects libexif to use, but
also some changes internal to libexif to make sure that not only libexif
messages but the textual parts of EXIF data are recoded correctly.

That stuff is non-trivial, but definitely needs to be done.

Uli

P.S: So far, literally hundreds of moderated spam mails to libexif-devel
deleted, one ham mail approved.