[Digikam-devel] exiv2 and l10n

Hi!

As KDE has a very powerful l10n infrastructure would'nt it be better to use
exiv2s internal names as hash-value for translation tables maintained by
digiKam? Later these tables can be integrated into a native exiv2 l10n
infrastructure.

Bye

  Thorsten

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-2]

Le Vendredi 3 Mars 2006 11:16, Thorsten Schnebeck a écrit :

> Hi!
>
> As KDE has a very powerful l10n infrastructure would'nt it be better to use
> exiv2s internal names as hash-value for translation tables maintained by
> digiKam? Later these tables can be integrated into a native exiv2 l10n
> infrastructure.
>
> Bye
>
>   Thorsten

Well, because Exiv2 library is outside of KDE project, i think that Exiv2 i18n
must be done on Exiv2 repository, like libexif done. But, i let's Andreas
(The Exiv2 author) commented himself this point.

About Tags titles, tags values, and tags descriptions, I think there are any
strings to backport from libexif and any strings improvement to do before
i18n. Libexif have a better tags descriptions for example.

Regards

Gilles

PS : Andreas, have you subscribe to digiKam-devel ML ?

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

Gilles Caulier wrote:

> Le Vendredi 3 Mars 2006 11:16, Thorsten Schnebeck a écrit :
>
>>Hi!
>>
>>As KDE has a very powerful l10n infrastructure would'nt it be better to use
>>exiv2s internal names as hash-value for translation tables maintained by
>>digiKam? Later these tables can be integrated into a native exiv2 l10n
>>infrastructure.
>>
>>Bye
>>
>>  Thorsten
>
>
> Well, because Exiv2 library is outside of KDE project, i think that Exiv2 i18n
> must be done on Exiv2 repository, like libexif done. But, i let's Andreas
> (The Exiv2 author) commented himself this point.

Exiv2 should (eventually) have its own i18n/l10n infrastructure. Is this
  an urgent requirement from your point of view?

> About Tags titles, tags values, and tags descriptions, I think there are any
> strings to backport from libexif and any strings improvement to do before
> i18n. Libexif have a better tags descriptions for example.
>
> Regards
>
> Gilles
>
> PS : Andreas, have you subscribe to digiKam-devel ML ?

Yes, just did that. I suggest you also subscribe to the Exiv2 list, if
you haven't done so yet, see http://www.exiv2.org/support.html (very low
traffic)

Regards,
Andreas
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-2]

On Friday 10 March 2006 06:06 am, Andreas Huggel wrote:

> Gilles Caulier wrote:
> > Le Vendredi 3 Mars 2006 11:16, Thorsten Schnebeck a écrit :
> >>Hi!
> >>
> >>As KDE has a very powerful l10n infrastructure would'nt it be better to
> >> use exiv2s internal names as hash-value for translation tables
> >> maintained by digiKam? Later these tables can be integrated into a
> >> native exiv2 l10n infrastructure.
> >>
> >>Bye
> >>
> >>  Thorsten
> >
> > Well, because Exiv2 library is outside of KDE project, i think that Exiv2
> > i18n must be done on Exiv2 repository, like libexif done. But, i let's
> > Andreas (The Exiv2 author) commented himself this point.
>
> Exiv2 should (eventually) have its own i18n/l10n infrastructure. Is this
>   an urgent requirement from your point of view?
>
> > About Tags titles, tags values, and tags descriptions, I think there are
> > any strings to backport from libexif and any strings improvement to do
> > before i18n. Libexif have a better tags descriptions for example.

I think i18n is important for end-users, especially with GUI. Try to use last
digiKam source code from svn trunk for example.

It's not very difficult to do, but before to works on i18n, i recommend you to
polish/improve all tags descriptions/titles strings using libexif strings
(this one is already i18n)

I have also a little remark :

Why libexif can parse without problem ORF raw file format (Fuji) and Exiv2
no ? I suppose that RAF is a RAW file format based to JPEG. I think that we
can support easily RAF files without any substantial changes...

------------------------------------------------------------------------------------------
From Exif-Probe project documentation :

RAF is a proprietary "raw" format of Fujifilm. It is an untagged format and
the implementation in exifprobe is preliminary, based upon nothing more than
examination of a few images I've downloaded from the internet. The primary
image data is "interpolated" CFA (is that really raw?) uncompressed. The CFA
data for the secondary pixels used in some models is apparently interlaced by
rows with the data for primary pixels. I assume that the tables found in the
images are white balance or color balance tables.
 
The files contain a JPEG image complete with EXIF data, which will be
displayed by exifprobe.
------------------------------------------------------------------------------------------

If you want to test it, this is my image files database used with digiKam:

http://digikam3rdparty.free.fr/Images_2_Test_DImg/

> >
> > Regards
> >
> > Gilles
> >
> > PS : Andreas, have you subscribe to digiKam-devel ML ?
>
> Yes, just did that. I suggest you also subscribe to the Exiv2 list, if
> you haven't done so yet, see http://www.exiv2.org/support.html (very low
> traffic)
>

No problem, i will do it...

Andreas, in the future (after to have released digiKam 0.9.0-beta1), i would
to contribe to exiv2 library to create new file format parsers like MRW for
example. How we can work together ?

Gilles
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[F.J.Cruz]

---- Gilles Caulier <[hidden email]> escribió:

> Andreas, in the future (after to have released digiKam 0.9.0-beta1), i would
> to contribe to exiv2 library to create new file format parsers like MRW for
> example. How we can work together ?
>
> Gilles

Well, then I think it's better if I wai" for you to implement NEF support at the same time you implement MRW, ok?

Paco.

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[F.J.Cruz]

---- Gilles Caulier <[hidden email]> escribió:

> On Friday 10 March 2006 11:38 am, you wrote:
> > ---- Gilles Caulier <[hidden email]> escribió:
> > > Andreas, in the future (after to have released digiKam 0.9.0-beta1), i
> > > would to contribe to exiv2 library to create new file format parsers like
> > > MRW for example. How we can work together ?
> > >
> > > Gilles
> >
> > Well, then I think it's better if I wai" for you to implement NEF support
> > at the same time you implement MRW, ok?
> >
>
> Sure. After to have study how to start a new RAW file parser, this is my
> plan :
>
> - In first we need to do/study TIFF/EP file format. To do a new read only
> parser, we can use Digikam::DMetaLoader class as well. I have alredy started
> this one about TIFF to load any IPTC metadata. Exif still to do. Look in my
> code for more information. Nota : i think that we need to use the last stable
> libtiff 3.8.0. Right ?
>
> - Doing a read only parser in DMetadata is a first stage and not the last.
> When you have done that you can use this code to make a new advanced Exiv2
> parser in read/write mode. The advantage to use DMetaloader in first is that
> you can experiment easily the loader code accordinly with the file format to
> decode. The result is directly visible into metadata sidebar in digikam.
>
> - After to have done a TIFF/EP parser, others parser for RAW files format
> based on TIFF/EP (NEF, MRW, etc.) can be done using a part of existing
> implementation.
>
> Fix me if i'm wrong... (:=)))
>
> Gilles

All is right for me :-).

Paco





_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel