I think that it is more a "configure" bug than an "i18n" one, even if I do not really understand the bug yet.

Have a nice day!

On Oct 31, 2005, at 9:50 PM, Nicolas Goutte wrote:
> ------- Additional Comments From nicolasg snafu de  2005-10-31  
> 21:50 -------
> I think that it is more a "configure" bug than an "i18n" one, even  
> if I do not really understand the bug yet.

Yes, the bug is not really "i18n". I don't know how the Makefile.in  
for po/ subdirectories are generated, but the bug is probsbly related  
to how those are generated. Could it be in the *todist tools ? I  
don't know much about kde processes to create distribution

--
antoine

On Tuesday 01 November 2005 03:57, Antoine Reilles wrote:
[bugs.kde.org quoted mail]

No, the Makefiles are either created:
- by pofiles.um of unsermake (which has not any touching of GMO files)
- by admin/am_edit (which seems to be the code that is critized here)  if you 
use automake 

Another question: what do you exactly mean by "fuzzy PO files"? Do you mean 
files where the empty msgid is marked as fuzzy? If this is really the case, 
then the real problem is not the generation of Makefiles but more than there 
are buggy PO files.

Have a nice day!


>
> --
> antoine

On Nov 1, 2005, at 4:40 PM, Nicolas Goutte wrote:
> Another question: what do you exactly mean by "fuzzy PO files"? Do  
> you mean
> files where the empty msgid is marked as fuzzy? If this is really  
> the case,
> then the real problem is not the generation of Makefiles but more  
> than there
> are buggy PO files.


Yes, those files are probably there to give a starting point for  
translators.
I don't think it is the point here.
The Makefiles generated contains entry like:

  libkexif.gmo: libkexif.po
         rm -f libkexif.gmo; $(GMSGFMT) -o libkexif.gmo $(srcdir)/ 
libkexif.po
         test ! -f libkexif.gmo || touch libkexif.gmo

the last lines purpose it to create an empty .gmo file if the msgfmt  
call did not create the file, which is the case for files with empty  
msgid. But what the test does it to touch the file if it exists, and  
not if it doesn't.
There is no necessity to touch the .gmo file if it has just been  
created by msgfmt. However, creating it even if msgfmt failed makes  
sure the rule is not trigerred each time, and also make sure the  
installed files are the same regardless if msg files have been  
updated, of the used version of msgfmt.

> No, the Makefiles are created:
> - by admin/am_edit (which seems to be the code that is critized  
> here)  if you
> use automake


so i suggest the following patch for am_edit:
--- admin/am_edit.orig  2005-09-17 18:09:28.000000000 +0200
+++ admin/am_edit
@@ -1614,7 +1614,7 @@ sub handle_POFILES($$)
          $pofile =~ /(.*)\.[^\.]*$/;          # Find name minus  
extension
          $tmp .= "$1.gmo: $pofile\n";
          $tmp .= "\trm -f $1.gmo; \$(GMSGFMT) -o $1.gmo \$(srcdir)/ 
$pofile\n";
-        $tmp .= "\ttest ! -f $1.gmo || touch $1.gmo\n";
+        $tmp .= "\ttest -f $1.gmo || touch $1.gmo\n";
          $allgmofiles .= " $1.gmo";
          $pofileLine  .= " $1.po";
      }

On Tuesday 01 November 2005 16:56, Antoine Reilles wrote:
[bugs.kde.org quoted mail]

Well, a PO file is supposed to be a PO file. So the empty msgid should not be 
fuzzy.

To have a PO file that makes msgfmt refuse to produce a file is a bug in 
itself.

> I don't think it is the point here.


> The Makefiles generated contains entry like:
>
>   libkexif.gmo: libkexif.po
>          rm -f libkexif.gmo; $(GMSGFMT) -o libkexif.gmo $(srcdir)/
> libkexif.po
>          test ! -f libkexif.gmo || touch libkexif.gmo
>
> the last lines purpose it to create an empty .gmo file if the msgfmt
> call did not create the file, which is the case for files with empty
> msgid.


I am not sure that it was the purpose. If it was, it would have been 
introduced in unsermake too. As it is not, I suppose that its reason was 
another.

I do not think that creating empty GMO files is a good goal. It would be at 
most a hack.

(But I am not an expert of KDE's build system, neither the old automake-based 
ones, nor of the one around unsermake.)

> But what the test does it to touch the file if it exists, and
> not if it doesn't.


> There is no necessity to touch the .gmo file if it has just been
> created by msgfmt.


I would be careful. It is not the only place where there are curious touch 
calls. So perhaps there is/was really a need for it. (That would explain why 
the unsermake version of the code does not have such a call, as unsermake is 
not as touchy as the automake-based build system.)

(...)

Have a nice day!

Closing this report as the build system has changed in KDE4.