Menu
▾
▴
libexif-devel — This is the place where your questions about libexif will be answered.
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
(6) |
May
|
Jun
(5) |
Jul
(17) |
Aug
(4) |
Sep
(5) |
Oct
(5) |
Nov
(26) |
Dec
(6) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(8) |
Feb
|
Mar
(3) |
Apr
(3) |
May
|
Jun
|
Jul
(4) |
Aug
(18) |
Sep
(9) |
Oct
(8) |
Nov
(5) |
Dec
(4) |
| 2004 |
Jan
(10) |
Feb
(1) |
Mar
(7) |
Apr
(11) |
May
(13) |
Jun
(5) |
Jul
(3) |
Aug
|
Sep
|
Oct
(15) |
Nov
(6) |
Dec
(10) |
| 2005 |
Jan
(1) |
Feb
(1) |
Mar
(25) |
Apr
(24) |
May
(9) |
Jun
(20) |
Jul
(13) |
Aug
(4) |
Sep
(17) |
Oct
(7) |
Nov
(2) |
Dec
(11) |
| 2006 |
Jan
(30) |
Feb
(12) |
Mar
(12) |
Apr
(12) |
May
(7) |
Jun
(12) |
Jul
(14) |
Aug
(16) |
Sep
(20) |
Oct
(16) |
Nov
(35) |
Dec
(42) |
| 2007 |
Jan
(34) |
Feb
(34) |
Mar
(29) |
Apr
(116) |
May
(42) |
Jun
(25) |
Jul
(4) |
Aug
(9) |
Sep
|
Oct
(2) |
Nov
(4) |
Dec
(10) |
| 2008 |
Jan
(9) |
Feb
(7) |
Mar
(2) |
Apr
(5) |
May
(2) |
Jun
(3) |
Jul
(3) |
Aug
|
Sep
(7) |
Oct
(4) |
Nov
(42) |
Dec
(20) |
| 2009 |
Jan
(12) |
Feb
(12) |
Mar
(1) |
Apr
(4) |
May
(2) |
Jun
(4) |
Jul
|
Aug
(3) |
Sep
(23) |
Oct
(34) |
Nov
(16) |
Dec
(8) |
| 2010 |
Jan
(5) |
Feb
(9) |
Mar
(3) |
Apr
(5) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
(14) |
| 2011 |
Jan
(4) |
Feb
|
Mar
(3) |
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
(2) |
Sep
(1) |
Oct
(1) |
Nov
(6) |
Dec
(4) |
| 2012 |
Jan
(2) |
Feb
|
Mar
(2) |
Apr
(10) |
May
(11) |
Jun
|
Jul
(21) |
Aug
(7) |
Sep
|
Oct
(1) |
Nov
(4) |
Dec
|
| 2013 |
Jan
(1) |
Feb
(6) |
Mar
(11) |
Apr
(2) |
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
(4) |
Oct
|
Nov
(3) |
Dec
(7) |
| 2014 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
(8) |
May
(1) |
Jun
(6) |
Jul
(2) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
(1) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(1) |
Jul
(1) |
Aug
(2) |
Sep
(1) |
Oct
(1) |
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
(1) |
Apr
(2) |
May
(2) |
Jun
(3) |
Jul
|
Aug
|
Sep
(8) |
Oct
|
Nov
|
Dec
(1) |
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(5) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
(1) |
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(1) |
Nov
|
Dec
|
| 2020 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
(1) |
May
(14) |
Jun
(8) |
Jul
(3) |
Aug
(1) |
Sep
(1) |
Oct
(2) |
Nov
(1) |
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
(1) |
Nov
(5) |
Dec
(5) |
| 2022 |
Jan
(3) |
Feb
(2) |
Mar
|
Apr
(2) |
May
(1) |
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2023 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
(1) |
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
(1) |
| 2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
|
From: Valere M. <val...@ym...> - 2012-05-10 19:48:08
|
> I suppose after 8 years, it's time for a new release ;-) It would be > nice if we had a few more translations to go with it, but that's not > critical. I also noticed a bug in the tracker that's been waiting 4 > years for someone who knows libexif-gtk to take a look. Would you mind > taking a peek? > http://sourceforge.net/tracker/?func=detail&aid=2014281&group_id=12272&atid=112272 > Yep, will have a look. |
|
From: Valere M. <val...@ym...> - 2012-05-09 20:20:21
|
> >I've checked in your final two patch sets (with some tiny tweaks). Please >check what's in CVS to make sure it still works. > >As you noted, all the translations except French are now out of date. >There aren't that many strings to translate, so if anyone listening >wants to update an existing language or translate into a new one, feel >free! If you're not able to generate the .pot file yourself, just ask >and I'll e-mail it. > Hi, I've checked the CVS (i.e. compared to what I have locally) and it's all good. I've also built gtk2/gtk3 versions and get exif information from gtkam without problem. So, perfect for me. Thanks a lot! Will you post a new tarball in sourceforge files list ? Cheers, Valère. |
|
From: Valere M. <val...@ym...> - 2012-04-26 07:27:03
|
Hi, Just to make a remark about the code itself, I indeed agree that maintaining code for both gtk2 and gtk3 doesn't improve readability. The way the code has been done is however inspired on how others did it. I don't know if there is a better way to do it. No problem at all with the delay. I have a full time job, family, ... so I perfectly understand that you also have your priorities. I was just sending mails to get a status update, not more. Thanks a lot to you all for the reviews and, should you receive bug reports, don't hesitate to send them to me. Cheers Valère ----- Mail original ----- > De : Dan Fandrich <da...@co...> > À : lib...@li... > Cc : > Envoyé le : Mercredi 25 avril 2012 23h34 > Objet : Re: [Libexif-devel] Changes to libexif-gtk for migration to gtk3 > > On Mon, Apr 23, 2012 at 09:46:07PM +0200, Marcus Meissner wrote: >> I would however say its good in the end. > > Thanks for taking a look at this, Marcus. I managed to contact > Lutz Müller, the original author of libexif-gtk, and he was fine with > it, too. Sorry about that unexpectedly-long delay, Valère, and thanks > for your patience. I'll check it in soon. > >>>> Dan > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > libexif-devel mailing list > lib...@li... > https://lists.sourceforge.net/lists/listinfo/libexif-devel > |
|
From: Dan F. <da...@co...> - 2012-04-25 21:46:57
|
On Mon, Apr 23, 2012 at 09:46:07PM +0200, Marcus Meissner wrote: > I would however say its good in the end. Thanks for taking a look at this, Marcus. I managed to contact Lutz Müller, the original author of libexif-gtk, and he was fine with it, too. Sorry about that unexpectedly-long delay, Valère, and thanks for your patience. I'll check it in soon. >>> Dan |
|
From: Marcus M. <ma...@je...> - 2012-04-23 19:46:16
|
On Mon, Apr 23, 2012 at 10:15:51AM +0100, Valere Monseur wrote: > Hi, > Did you managed to find someone to review the code changes ? > Thanks > Valère > >________________________________ > >De : Dan Fandrich <da...@co...> > >À : lib...@li... > >Envoyé le : Vendredi 20 janvier 2012 10h56 > >Objet : Re: [Libexif-devel] Changes to libexif-gtk for migration to gtk3 > > > >On Thu, Jan 19, 2012 at 09:38:41AM +0000, Valere Monseur wrote: > >> First of all, I wish you a happy new year 2012 (ok, it's almost end of Jan, but better late than never). > >> Regarding the below request for code review of gtk changes, did you had the opportunity to ask the gphoto2 devs ? > > > >I did, but the best person to review it was ill at the time. I'll try someone > >else if I don't get a response by next week. Thanks for your patience. Hi, While my arm is better these days and my workload allows a bit of review ... Your changes look sensible in general. The ifdef/else/endif mess looks ugly but is bearable I think. As I have no knowledge of GTK I cannot really tell if the 80KB updates2.diff is good or not though. I would however say its good in the end. Ciao, Marcus |
|
From: Valere M. <val...@ym...> - 2012-04-23 09:15:59
|
Hi, Did you managed to find someone to review the code changes ? Thanks Valère >________________________________ >De : Dan Fandrich <da...@co...> >À : lib...@li... >Envoyé le : Vendredi 20 janvier 2012 10h56 >Objet : Re: [Libexif-devel] Changes to libexif-gtk for migration to gtk3 > >On Thu, Jan 19, 2012 at 09:38:41AM +0000, Valere Monseur wrote: >> First of all, I wish you a happy new year 2012 (ok, it's almost end of Jan, but better late than never). >> Regarding the below request for code review of gtk changes, did you had the opportunity to ask the gphoto2 devs ? > >I did, but the best person to review it was ill at the time. I'll try someone >else if I don't get a response by next week. Thanks for your patience. > >>>> Dan > >------------------------------------------------------------------------------ >Keep Your Developer Skills Current with LearnDevNow! >The most comprehensive online learning library for Microsoft developers >is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, >Metro Style Apps, more. Free future releases when you subscribe now! >http://p.sf.net/sfu/learndevnow-d2d >_______________________________________________ >libexif-devel mailing list >lib...@li... >https://lists.sourceforge.net/lists/listinfo/libexif-devel > > > |
|
From: Translation P. R. <ro...@tr...> - 2012-04-16 01:52:23
|
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 Croatian team of translators. The file is available at:
http://translationproject.org/latest/exif/hr.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...>
|
|
From: Casper <fa...@fe...> - 2012-04-11 09:49:45
|
Marcus Meissner a écrit : > On Sat, Apr 07, 2012 at 03:37:42AM +0200, Casper wrote: > > Hello developers, > > I'm packaging exif for Fedora GNU/Linux, you can follow the integration > > in fedora repository here: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=796465 > > > > As you can see, I encountered a problem: > > What is exactly the libjpeg subfolder needed during the compilation ? > > Hi, > > The subfolder does not contain a libjpeg copy, but very small jpeg > manipulations functions. > > wc -l *.c *.h > 478 jpeg-data.c > 122 jpeg-marker.c > 92 jpeg-data.h > 103 jpeg-marker.h > 795 insgesamt > > So it is not a copy. Thanks a lot Matthieu -- Pour encrypter vos emails Clef GPG ID : 83288189 Empreinte : CC26 692F 5205 AC8F 7912 7783 D7A7 F4C5 8328 8189 |
|
From: Translation P. R. <ro...@tr...> - 2012-04-10 16:12:11
|
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 Croatian team of translators. The file is available at:
http://translationproject.org/latest/exif/hr.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...>
|
|
From: Marcus M. <ma...@je...> - 2012-04-10 07:18:09
|
On Sat, Apr 07, 2012 at 03:37:42AM +0200, Casper wrote: > Hello developers, > I'm packaging exif for Fedora GNU/Linux, you can follow the integration > in fedora repository here: > > https://bugzilla.redhat.com/show_bug.cgi?id=796465 > > As you can see, I encountered a problem: > What is exactly the libjpeg subfolder needed during the compilation ? Hi, The subfolder does not contain a libjpeg copy, but very small jpeg manipulations functions. wc -l *.c *.h 478 jpeg-data.c 122 jpeg-marker.c 92 jpeg-data.h 103 jpeg-marker.h 795 insgesamt So it is not a copy. Ciao, Marcus |
|
From: Translation P. R. <ro...@tr...> - 2012-04-09 22:27:24
|
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 Croatian team of translators. The file is available at:
http://translationproject.org/latest/exif/hr.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...>
|
|
From: Casper <fa...@fe...> - 2012-04-07 01:38:07
|
Hello developers, I'm packaging exif for Fedora GNU/Linux, you can follow the integration in fedora repository here: https://bugzilla.redhat.com/show_bug.cgi?id=796465 As you can see, I encountered a problem: What is exactly the libjpeg subfolder needed during the compilation ? Best Regards, Matthieu Saulnier -- Pour encrypter vos emails Clef GPG ID : 83288189 Empreinte : CC26 692F 5205 AC8F 7912 7783 D7A7 F4C5 8328 8189 |
|
From: Translation P. R. <ro...@tr...> - 2012-03-21 01:02:11
|
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...>
|
|
From: Translation P. R. <ro...@tr...> - 2012-03-21 00:47:14
|
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...>
|
|
From: Dan F. <da...@co...> - 2012-01-20 14:25:18
|
On Thu, Jan 19, 2012 at 09:38:41AM +0000, Valere Monseur wrote: > First of all, I wish you a happy new year 2012 (ok, it's almost end of Jan, but better late than never). > Regarding the below request for code review of gtk changes, did you had the opportunity to ask the gphoto2 devs ? I did, but the best person to review it was ill at the time. I'll try someone else if I don't get a response by next week. Thanks for your patience. >>> Dan |
|
From: Valere M. <val...@ym...> - 2012-01-19 09:38:53
|
Hi, First of all, I wish you a happy new year 2012 (ok, it's almost end of Jan, but better late than never). Regarding the below request for code review of gtk changes, did you had the opportunity to ask the gphoto2 devs ? Thanks Cheers Valère >> I'll go ahead and make a request there unless you say otherwise. > >That would be great! >Thanks a lot > >Valère > |
|
From: Translation P. R. <ro...@tr...> - 2011-12-24 21:47:12
|
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 Serbian team of translators. The file is available at:
http://translationproject.org/latest/exif/sr.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...>
|
|
From: Valere M. <val...@ym...> - 2011-12-09 08:53:04
|
> I'll go ahead and make a request there unless you say otherwise. That would be great! Thanks a lot Valère |
|
From: Dan F. <da...@co...> - 2011-12-09 08:42:08
|
On Wed, Dec 07, 2011 at 06:44:00PM +0000, Valere Monseur wrote: > The new updated patch (updates1.diff) has been uploaded at the same place > than others i.e. http://sourceforge.net/projects/vmonseur.u/files/libexif-gtk/ That looks great! I've gone ahead and commited the update1.diff patchset, as well as the update to fr.po. Since the rest of the patches are considerably more intrusive, and given the lack of reviewers on this list, I'm a bit hesistant to check it in without at least someone else taking a look first. Since gtkam is one of the few users of libexif-gtk, it might be worthwhile asking someone on the gphoto2 mailing list to review them. I'll go ahead and make a request there unless you say otherwise. >>> Dan |
|
From: Valere M. <val...@ym...> - 2011-12-07 18:44:07
|
Thanks for the review, Dan. The new updated patch (updates1.diff) has been uploaded at the same place than others i.e. http://sourceforge.net/projects/vmonseur.u/files/libexif-gtk/ Please, find below my comments on the review. Cheers, Valere > -DLOCALEDIR is already set in configure.ac by GP_GETTEXT_HACK, isn't it? Indeed, I'm not yet used to the GP_xxx macros ;) I've removed -DLOCALEDIR from Makefiles. > - -DG_LOG_DOMAIN=\"libexif\" > + -DG_LOG_DOMAIN=\"libexif-gtk\" \ > > Won't this break backward compatibility? Or is this just for debugging? > Could one expect changing it to break any software? It could be used for other things than debugging. I've reset G_LOG_DOMAIN to 'libexif'. > diff -aurpN libexif-gtk-0.3.5-cvs/cvs/libexif-gtk/tests/test-libexif-gtk.c libexif-gtk-0.3.5-diff1/cvs/libexif-gtk/tests/test-libexif-gtk.c > + bind_textdomain_codeset (GETTEXT_PACKAGE, "UTF-8"); > > Does GTK not operate in the current locale's character set? Is it fixed to > use UTF-8 no matter what the environment? If so, then this should really > be called everywhere that bindtextdomain(GETTEXT_PACKAGE, LOCALEDIR) > is called from within libexif-gtk. Apps won't know this textual domain name, > anyway, since it's really an internal detail to libexif-gtk. As per the gtk documentation (http://developer.gnome.org/gtk/2.24/gtk-question-index.html): bindtextdomain has to be called with UTF8. So, indeed bind_textdomain_codeset has to be called everywhere that bindtextdomain is called from within libexif-gtk. Change is done. > - gtk_set_locale (); > - textdomain (PACKAGE); > + bind_textdomain_codeset (GETTEXT_PACKAGE, "UTF-8"); > + textdomain (GETTEXT_PACKAGE); > > Since test-libexif-gtk.c itself doesn't use gettext, I wouldn't expect it to > be calling textdomain(). In fact, it seems like a better test to NOT > call it, so you can better ensure that the libexif-gtk library is doing > the right thing with gettext on its own. In addition, the whole #ifdef > ENABLE_NLS block at the head of that file should go. Yep, I agree. Change is done. > However, I believe you'll need a call to setlocale(LC_ALL,"") to set > the locale. I'm guessing that's what gtk_set_locale() did, so that > part should probably stay. I think this diff chunk should probably look > like this: > > gtk_set_locale (); > - textdomain (PACKAGE); As per the gtk documentation (http://developer.gnome.org/gtk/2.24/gtk-General.html): locale is set by gtk_init, which is a mandatory call for every gtk program. So there is no point in calling gtk_set_locale or set_locale. |
|
From: Translation P. R. <ro...@tr...> - 2011-11-25 11:17:12
|
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 Czech team of translators. The file is available at:
http://translationproject.org/latest/exif/cs.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...>
|
|
From: Dan F. <da...@co...> - 2011-11-18 06:28:04
|
On Mon, Nov 14, 2011 at 10:16:03PM +0000, Valere Monseur wrote: > As discussed with Dan, here are the different diff files to apply to the cvs > tree and a description of the content of each file. > The diff files are located here: http://sourceforge.net/projects/vmonseur.u/ > files/libexif-gtk/ Thanks, Valere, for taking this on. > Description updates1.diff > > summary: technical changes + internationalisation changes This patch is the only one I can meaningfully review. I'm hoping others on this list who are familiar with GTK will give the other patches. After taking a look at this first patch, I have some questions about a few of the hunks. diff -aurpN libexif-gtk-0.3.5-cvs/cvs/libexif-gtk/gtk-extensions/Makefile.am libexif-gtk-0.3.5-diff1/cvs/libexif-gtk/gtk-extensions/Makefile.am libgtk_extensions_la_CFLAGS = \ $(AM_CFLAGS) $(CFLAGS) \ - -I$(top_srcdir) \ - $(GTK_CFLAGS) + -I$(top_srcdir) \ + $(GTK_CFLAGS) \ + -DLOCALEDIR=\""$(localedir)"\" + -DLOCALEDIR is already set in configure.ac by GP_GETTEXT_HACK, isn't it? - -DG_LOG_DOMAIN=\"libexif\" + -DG_LOG_DOMAIN=\"libexif-gtk\" \ Won't this break backward compatibility? Or is this just for debugging? Could one expect changing it to break any software? diff -aurpN libexif-gtk-0.3.5-cvs/cvs/libexif-gtk/tests/test-libexif-gtk.c libexif-gtk-0.3.5-diff1/cvs/libexif-gtk/tests/test-libexif-gtk.c + bind_textdomain_codeset (GETTEXT_PACKAGE, "UTF-8"); Does GTK not operate in the current locale's character set? Is it fixed to use UTF-8 no matter what the environment? If so, then this should really be called everywhere that bindtextdomain(GETTEXT_PACKAGE, LOCALEDIR) is called from within libexif-gtk. Apps won't know this textual domain name, anyway, since it's really an internal detail to libexif-gtk. - gtk_set_locale (); - textdomain (PACKAGE); + bind_textdomain_codeset (GETTEXT_PACKAGE, "UTF-8"); + textdomain (GETTEXT_PACKAGE); Since test-libexif-gtk.c itself doesn't use gettext, I wouldn't expect it to be calling textdomain(). In fact, it seems like a better test to NOT call it, so you can better ensure that the libexif-gtk library is doing the right thing with gettext on its own. In addition, the whole #ifdef ENABLE_NLS block at the head of that file should go. However, I believe you'll need a call to setlocale(LC_ALL,"") to set the locale. I'm guessing that's what gtk_set_locale() did, so that part should probably stay. I think this diff chunk should probably look like this: gtk_set_locale (); - textdomain (PACKAGE); >>> Dan |
|
From: Valere M. <val...@ym...> - 2011-11-14 22:16:11
|
Hi, As discussed with Dan, here are the different diff files to apply to the cvs tree and a description of the content of each file. The diff files are located here: http://sourceforge.net/projects/vmonseur.u/files/libexif-gtk/ Description updates1.diff summary: technical changes + internationalisation changes - whitespace changes - cleaning of useless comments - PACKAGE replaced by GETTEXT_PACKAGE - call of bindtextdomain in required places (to avoid changing API to have a global call) - added missing gettext definition in gtk-options.c - added missing internationalisation of options[i].name in gtk-options.c - added LOCALEDIR in Makefile.am - changed G_LOG_DOMAIN from libexif to libexif-gtk - call to gtk_set_locale removed from test-libexif-gtk.c (already done in gtk-init) - call to bind_textdomain_codeset added in test-libexif-gtk.c Description updates2.diff summary: changes to remove gtk2 deprecated calls and adapt the code for both gtk2 and gtk3 following the documentation: http://developer.gnome.org/gtk3/3.1/gtk-migrating-2-to-3.html - deprecated GtkFileSelection has been replaced by GtkFileChooser API - accesses to some internal gtk variables via pointer have been replaced by accesses via accessor functions - GtkTooltips has been deprecated in gtk 2.12 in favor of the new GtkTooltip API so make the code conditional for both APIs - when possible transform deprecated symbols into new ones valid for both gtk2 and gtk3 - remove individual includes... - ...otherwise condition the code for gtk2/gtk3 Note: after those changes, the code is compatible for both gtk2 and gtk3 but the autotools have not yet been adapted to allow for the gtk3 build. Description updates3.diff summary: autotools adapted to gtk2 or gtk3 fixed bug in deletion of notebook pages fr translation updated - autogen.sh: added - Changelog: updated - NEWS: updated - README: updated - TODO: created - configure.ac: version/revision changed - configure.ac: added option --with--gtk3 - Makefile.am: changed to build with gtk2 or gtk3 - libexif-gtk.pc: specific file generated when building with gtk2 or gtk3 - libexif-gtk-uninstalled.pc: specific file generated when building with gtk2 or gtk3 - fixed segfault bug when removing pages of notebook - Language tag added in .po files - French translation fully updated - gtk-options.c added in POTFILES.in patched with these commands starting from the cvs: cvs -z3 -d:pserver:ano...@li...:/cvsroot/libexif co -P libexif-gtk patch -p2 -i updates1.diff patch -p2 -i updates2.diff patch -p2 -i updates3.diff |
|
From: Translation P. R. <ro...@tr...> - 2011-11-07 00:27:41
|
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...>
|
|
From: Translation P. R. <ro...@tr...> - 2011-11-06 22:42:24
|
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...>
|
258 messages has been excluded from this view by a project administrator.
