libexif-devel — This is the place where your questions about libexif will be answered.

[Libexif-devel] New Dutch PO file for 'exif' (version 0.6.18-pre2)

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'exif' has been submitted
by the Dutch team of translators.  The file is available at:

    http://translationproject.org/latest/exif/nl.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

    http://translationproject.org/latest/exif/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/exif.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>

[Libexif-devel] New Dutch PO file for 'libexif' (version 0.6.18-pre2)

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'libexif' has been submitted
by the Dutch team of translators.  The file is available at:

    http://translationproject.org/latest/libexif/nl.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

    http://translationproject.org/latest/libexif/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/libexif.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>

[Libexif-devel] New Indonesian PO file for 'exif' (version 0.6.18-pre2)

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'exif' has been submitted
by the Indonesian team of translators.  The file is available at:

    http://translationproject.org/latest/exif/id.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

    http://translationproject.org/latest/exif/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/exif.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>

[Libexif-devel] New Danish PO file for 'exif' (version 0.6.18-pre2)

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'exif' has been submitted
by the Danish team of translators.  The file is available at:

    http://translationproject.org/latest/exif/da.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

    http://translationproject.org/latest/exif/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/exif.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>

[Libexif-devel] New Polish PO file for 'libexif' (version 0.6.18-pre2)

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'libexif' has been submitted
by the Polish team of translators.  The file is available at:

    http://translationproject.org/latest/libexif/pl.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

    http://translationproject.org/latest/libexif/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/libexif.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>

[Libexif-devel] New Polish PO file for 'exif' (version 0.6.18-pre2)

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'exif' has been submitted
by the Polish team of translators.  The file is available at:

    http://translationproject.org/latest/exif/pl.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

    http://translationproject.org/latest/exif/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/exif.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>

[Libexif-devel] New Danish PO file for 'libexif' (version 0.6.18-pre2)

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'libexif' has been submitted
by the Danish team of translators.  The file is available at:

    http://translationproject.org/latest/libexif/da.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

    http://translationproject.org/latest/libexif/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/libexif.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>

Re: [Libexif-devel] exif_loader_get_buf()

[Dan F. <da...@co...>]

On Fri, Oct 02, 2009 at 10:15:56AM +0200, Jan Patera wrote:
> You are fast ;-) You implemented it before (<24 hours) giving a chance for
> response ;-)

Well, I've been thinking about it for a while. The more I thought, the more
I realized this was the way to go, at least in the short term. I figured it's
easy enough to revert if someone doesn't like it.

> Yes, I agree with the variant you implemented.

Phew!

>>> Dan
-- 
http://www.MoveAnnouncer.com              The web change of address service
          Let webmasters know that your web site has moved

Re: [Libexif-devel] exif_loader_get_buf()

[Jan P. <pa...@pi...>]

>> void exif_loader_get_buf (ExifLoader *loader, const unsigned char
>> **buf, size_t *buf_size);
>
> I've implemented this and modified the exif front-end and all seems
> well. I just hope the now more eager default tag fixup routines don't
> bite anyone.

You are fast ;-) You implemented it before (<24 hours) giving a chance for
response ;-)

Yes, I agree with the variant you implemented.

 -- Jan

[Libexif-devel] libexif prerelease testing

[Dan F. <da...@co...>]

I've created prerelease libexif and exif source packages temporarily
hosted at http://www.npsnet.com/danf/software/pub/libexif-0.6.18-pre2.tar.bz2
and http://www.npsnet.com/danf/software/pub/exif-0.6.18-pre2.tar.bz2
Please test them and report back any problems you find. Barring any
issues, I hope to make an official release next week. Here are the md5sums:

0f3e907208139f11f3e72701df3b623f  exif-0.6.18-pre2.tar.bz2
2558f6f491af59c984f0721460c91c92  libexif-0.6.18-pre2.tar.bz2

>>> Dan
-- 
http://www.MoveAnnouncer.com              The web change of address service
          Let webmasters know that your web site has moved

Re: [Libexif-devel] exif_loader_get_buf()

[Dan F. <da...@co...>]

On Tue, Sep 29, 2009 at 11:50:11PM -0700, Dan Fandrich wrote:
> void exif_loader_get_buf (ExifLoader *loader, const unsigned char **buf,
>                                                   size_t *buf_size);

I've implemented this and modified the exif front-end and all seems well.
I just hope the now more eager default tag fixup routines don't bite anyone.

>>> Dan
-- 
http://www.MoveAnnouncer.com              The web change of address service
          Let webmasters know that your web site has moved

[Libexif-devel] exif_loader_get_buf()

[Dan F. <da...@co...>]

There's one more change I think needs to go into libexif in this next
release. Since the last release, libexif has gotten a lot smarter about
adding mandatory tags and removing illegal tags in files when the data type
is not explicitly set. Few applications likely set the data type, including
the exif front-end, so users upgrading to 0.6.18 may be surprised that
some tags are now appearing and disappearing when they didn't used to.
It's also a bit misleading to users of the exif front-end since it now
shows tags that appear to have come from a JPEG file when they were
actually synthesized by libexif itself.

I'm planning on adding a --no-fixup option to the exif front end that stops
libexif from messing with the tags when loading them and restores something
closer to the previous behaviour.  The implementation seems simple:
call exif_data_unset_option() on the 
EXIF_DATA_OPTION_IGNORE_UNKNOWN_TAGS and
EXIF_DATA_OPTION_FOLLOW_SPECIFICATION options.  Unfortunately, due to an
API deficiency, this is impossible to do when using an ExifLoader. These
options have to be unset on an ExifData, but by the time the app gets one
back from exif_loader_get_data() the damage has already been done.

There are two ways of fixing this. One is to add this function:

/*! Return the data read by the loader. The loader must
 * already contain data from a previous call to #exif_loader_write_file
 * or #exif_loader_write. The returned pointer is only guaranteed to be
 * valid until the next call to a function modifying this #ExifLoader.
 *
 * \param[in] loader the loader
 * \param[out] buf read-only pointer to the data read by the loader, or NULL
 *                 in case of error
 * \param[out] buf_size size of the data at buf
 * \return allocated ExifData
 */
void exif_loader_get_buf (ExifLoader *loader, const unsigned char **buf,
                                                  size_t *buf_size);

This provides another way to get data out of an ExifLoader (right now, the
only way is by creating an ExifData). This is really an API deficiency in
its own right and this function should probably be added regardless,
but it can also be used to solve the above problem since the user can then
create his own ExifData with the right options unset and pass in the
data from the ExifLoader through exif_data_load_data().

Another solution is to create exif_loader_get_data_opt() that works like
exif_loader_get_data() but takes in the ExifDataOption and ExifDataType
values to use instead of the defaults.  This should work, but I'm not sure
the app will always know the ExifDataType before the EXIF data is read.
It also creates a new way of setting options, which somehow seems impure.

The last way is to create a exif_loader_get_data_pure() function that looks
exactly like exif_loader_get_data() but uses no or UNKNOWN values for
ExifDataOption and ExifDataType.  The user can later call exif_data_fix()
after setting the options the way he wants to do the fixup. I dislike
this solution because it's possible some option in the future may need
to be set before the data is loaded from the file for it to work.

So, I think I'll implement exif_loader_get_buf() and see how that goes.
Hopefully, that will be sufficient and the other two functions won't be
needed, but I'd like to hear other people's opinions.

>>> Dan
-- 
http://www.MoveAnnouncer.com              The web change of address service
          Let webmasters know that your web site has moved

Re: [Libexif-devel] Another libexif release

[Dan F. <da...@co...>]

On Tue, Sep 22, 2009 at 09:52:22AM +0200, Jean-Philippe François wrote:
> I discovered this issue a couple days ago :
> This is a performance issue. The following piece of code takes 1.5 seconds on a 270 MHz ARM processor

I've checked in a fix for this. The test suite that used to take 3 min to
run to completion now takes 5 sec. Thanks for pointing out the seriousness
of this bottleneck in exif_data_fix().

>>> Dan
-- 
http://www.MoveAnnouncer.com              The web change of address service
          Let webmasters know that your web site has moved

Re: [Libexif-devel] Another libexif release

[Dan F. <da...@co...>]

On Tue, Sep 22, 2009 at 09:52:22AM +0200, Jean-Philippe François wrote:
> I discovered this issue a couple days ago :
> This is a performance issue. The following piece of code takes 1.5 seconds on a 270 MHz ARM processor

I've noticed this O(n^2) operation myself. The problem with this patch
is that any unknown tags will never get a chance to return
EXIF_SUPPORT_LEVEL_NOT_RECORDED and will therefore never be removed.
Perhaps that loop should be split into two; one looping through the
actual tags found in the ExifContent to find those that should be removed,
and another loop going through the actual tags in the ExifTagTable[]
to find those that need to be added.

>>> Dan
-- 
http://www.MoveAnnouncer.com              The web change of address service
          Let webmasters know that your web site has moved

Re: [Libexif-devel] Another libexif release

[Jean-Philippe F. <jp....@cy...>]

Dan Fandrich a écrit :
> It's been almost a year since the last libexif/exif release and people are
> starting to ask about a new one. Members of the Translation Project have
> been busy lately updating the translations to the latest code, so there's
> no reason not to make a release soon.
> 
> I've started to look at some of the open bugs and issues that people have
> reported that noone has investigated yet, and there are a couple that
> really ought to be looked into more thoroughly before a release. There
> is also the issue of what to do with libexif-gtk and gexif, neither of
> which have been touched in a long time despite having some serious issues,
> likely because the developers with commit access don't use them.
> 
> If you know of an issue or have a request that should get into the next
> release, now's the time to speak up. 
I discovered this issue a couple days ago :
This is a performance issue. The following piece of code takes 1.5 seconds on a 270 MHz ARM processor

    ExifContent * ec;
    ExifEntry * ee;
    int tag_count = sizeof(MyTags)/sizeof(ExifTag);
    int i;

    /* Allocate and initialise Exif dat */
    e_data = exif_data_new();
    exif_data_set_data_type (e_data, EXIF_DATA_TYPE_COMPRESSED);
    exif_data_set_byte_order(e_data, EXIF_BYTE_ORDER_INTEL);
    exif_data_fix (e_data);

The culprit is the exif_content_fix function called by exif_data_fix, 
where the exif_tag_table is searched for matching tag for every 65536 possible tag value.
That is much more tag than there is in the table.

Unfortunately, the ExifTagTable is not exported, which is fine, and the function for 
accessing it are marked as :
/* For now, do not use these functions. */

So here is a hack to greatly reduce the runtime of the exif_content_fix function :

Index: libexif-0.6.17/libexif/exif-content.c
===================================================================
--- libexif-0.6.17.orig/libexif/exif-content.c	2008-07-26 18:06:49.000000000 +0200
+++ libexif-0.6.17/libexif/exif-content.c	2009-09-22 09:24:33.000000000 +0200
@@ -253,6 +253,7 @@
 	ExifDataType dt;
 	ExifTag t;
 	ExifEntry *e;
+        int n;
 
 	if (!c) return;
 
@@ -265,7 +266,7 @@
 	 * Then check for existing tags that are not allowed and for
 	 * non-existing mandatory tags.
 	 */
-	for (t = 0; t <= 0xffff; t++) {
+	for(n=0; t=exif_tag_table_get_tag(n); n++) {
 		switch (exif_tag_get_support_level_in_ifd (t, ifd, dt)) {
 		case EXIF_SUPPORT_LEVEL_MANDATORY:
 			if (exif_content_get_entry (c, t)) break;


Jean-Philippe François


 Otherwise, I hope to do it within a
> couple of weeks (and keep your jokes about Release Early, Release Often
> to yourselves!)  But seriously, we could probably do with releasing a
> bit more often in the future.
> 
>>>> Dan
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
>>>> is the only developer event you need to attend this year. Jumpstart your
>>>> developing skills, take BlackBerry mobile applications to market and stay 
>>>> ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
>>>> http://p.sf.net/sfu/devconf
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> libexif-devel mailing list
>>>> lib...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/libexif-devel

[Libexif-devel] Another libexif release

[Dan F. <da...@co...>]

It's been almost a year since the last libexif/exif release and people are
starting to ask about a new one. Members of the Translation Project have
been busy lately updating the translations to the latest code, so there's
no reason not to make a release soon.

I've started to look at some of the open bugs and issues that people have
reported that noone has investigated yet, and there are a couple that
really ought to be looked into more thoroughly before a release. There
is also the issue of what to do with libexif-gtk and gexif, neither of
which have been touched in a long time despite having some serious issues,
likely because the developers with commit access don't use them.

If you know of an issue or have a request that should get into the next
release, now's the time to speak up.  Otherwise, I hope to do it within a
couple of weeks (and keep your jokes about Release Early, Release Often
to yourselves!)  But seriously, we could probably do with releasing a
bit more often in the future.

>>> Dan

Re: [Libexif-devel] strange string

[Dan F. <da...@co...>]

On Sun, Sep 20, 2009 at 04:35:16PM +0200, Marcus Meissner wrote:
> While translating ...
> 
>         {EXIF_TAG_GPS_STATUS, "GPSStatus", N_("GPS receiver status"),
>          N_("Indicates the status of the GPS receiver when the image is "
>             "recorded. 'A' means measurement is in progress, and 'V' means "
>             "the measurement is Interoperability."), ESL_GPS},
> 
> This does not make sense to me.
> 
> "V means the measurement is .. " what?

This has always confused me, too.  It's as though someone went through
the EXIF spec with a search and replace function, replacing some common
word with "Interoperability".  The nearest I can figure is that the authors
mean one of three things by that word; the ability to interoperate
(presumably, with different implemenations of EXIF readers/writers), the
Interopability IFD (tag 0x8769), and some third, nebulous meaning, which
might refer to the 12-byte TIFF-style tag structure itself.  Naturally,
"Interoperability" isn't listed in the definition of terms section of the
standard. I'm just glad I don't have responsibility for trying to translate
it.

>>> Dan
-- 
http://www.MoveAnnouncer.com              The web change of address service
          Let webmasters know that your web site has moved

[Libexif-devel] New German PO file for 'libexif' (version 0.6.18-pre1)

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'libexif' has been submitted
by the German team of translators.  The file is available at:

    http://translationproject.org/latest/libexif/de.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

    http://translationproject.org/latest/libexif/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/libexif.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>

[Libexif-devel] strange string

[Marcus M. <ma...@je...>]

Hi,

While translating ...

        {EXIF_TAG_GPS_STATUS, "GPSStatus", N_("GPS receiver status"),
         N_("Indicates the status of the GPS receiver when the image is "
            "recorded. 'A' means measurement is in progress, and 'V' means "
            "the measurement is Interoperability."), ESL_GPS},

This does not make sense to me.

"V means the measurement is .. " what?

Ciao, Marcus

[Libexif-devel] New German PO file for 'exif' (version 0.6.18-pre1)

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'exif' has been submitted
by the German team of translators.  The file is available at:

    http://translationproject.org/latest/exif/de.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

    http://translationproject.org/latest/exif/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/exif.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>

[Libexif-devel] New Vietnamese PO file for 'exif' (version 0.6.18-pre1)

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'exif' has been submitted
by the Vietnamese team of translators.  The file is available at:

    http://translationproject.org/latest/exif/vi.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

    http://translationproject.org/latest/exif/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/exif.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>

[Libexif-devel] New Vietnamese PO file for 'libexif' (version 0.6.18-pre1)

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'libexif' has been submitted
by the Vietnamese team of translators.  The file is available at:

    http://translationproject.org/latest/libexif/vi.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

    http://translationproject.org/latest/libexif/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/libexif.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>

[Libexif-devel] New Swedish PO file for 'libexif' (version 0.6.18-pre1)

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'libexif' has been submitted
by the Swedish team of translators.  The file is available at:

    http://translationproject.org/latest/libexif/sv.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

    http://translationproject.org/latest/libexif/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/libexif.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>

[Libexif-devel] New Swedish PO file for 'exif' (version 0.6.18-pre1)

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'exif' has been submitted
by the Swedish team of translators.  The file is available at:

    http://translationproject.org/latest/exif/sv.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

    http://translationproject.org/latest/exif/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/exif.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>

[Libexif-devel] New German PO file for 'libexif' (version 0.6.18-pre1)

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'libexif' has been submitted
by the German team of translators.  The file is available at:

    http://translationproject.org/latest/libexif/de.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

    http://translationproject.org/latest/libexif/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/libexif.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>