That's ugly. I don't generated files in the repository. Can't damned-lies be a bit more clever?

Looking a bit further, what exactly does damned-lies need to know? It seems that it can skope somehow with intltool-extract stuff so this should be difficult to add. Quoting from the Makefile.am:

translatable-strings.h: $(wizard_files_DATA)
	perl $(srcdir)/extract-translatable-strings.pl $(wizard_files_DATA) > translatable-strings.h

I don't like storing generated files in vcs either, but I'm not sure that one month before release is a good time to start inventing creative ways to generate it...

The file was always generated. For a dubios reason it was in git while it shouldn't have been.

Everything is fine for make distcheck so this is only a damned-lies problem, nothing that is wrong in the package.

Well damned-lies could of course try to cope with this issue. However, I think every GNOME module should try to comply as much as possible to the intltool tool chain, without requiring to any supplemental script magic. There are always translators which update their po files with an intltool-update command in the po directory.

Did you try any XML mode from intltool (e.g. [type:gettext/xml]) ?

Currently, intltool-update blocks on the unexisting translatable-strings.h file. Johannes, could you fix this?

Well, I am aware of that because this file is generated using extract-translable-strings.pl (see comment #2). I will try to figure out if we could use intltool instead to get the translation but I am not sure.

But what can we do if intltool is not able to extract the translations and a generated file in unacceptable in git because it will become outdated or it will be catched in completely unrelated commits?

Checking further, as the .wiz files are actually xml files with the _ convention that shouldn't be a big deal for intltool. I just wonder if it can scope with the wiz.in => wiz instead of xml.in => xml.

I won't be able to have a look at it till wednesday...

The .wiz files are not well-formed xml files, so intltool-extract can not parse them:

gabor@gabor-desktop:~/tmp/anjuta/po$ intltool-extract --type=gettext/xml ../plugins/project-wizard/templates/gtk.wiz
Generating C format header file for translation.

junk after document element at line 12, column 0, byte 352 at /usr/lib/perl5/XML/Parser.pm line 187

This was the problem in bug #398035, then this perl script was invented to work it around.

Maybe the bug is to used XML-like format and not make it XML compliant. However, there is not much to do to make them XML compliant: add a root element and replace quotes in attribute values. Would this be possible?

The .wiz files are not XML file.

They are templates those are going through a kind a preprocessor (autogen) to generate XML file (almost as I have forgotten to put a root node).

By example in minimal.wiz you have something like

[+IF (=(get "HavePackage") "1")+]
<page name="packages" _label="Configure external packages" _description="Configure external packages">
...
[+ENDIF+]

I'm afraid it's not obvious to transform this to a valid XML file. I don't know if I can change this to really match XML syntax.

Then, another issue is that adding the translation for these files inside Anjuta is not right, because it means that we cannot translate .wiz file distributed outside Anjuta. The translation should be inside the .wiz file, like it's done for .plugin file.


I'm ready to work on this but if I'm changing the .wiz file format, I would like to fix both problems at the same time. I have some idea for the first issue, but I don't know how to solve the second one. I'm afraid that using a kind of ini format for .wiz file will be difficult. Is it possible to include translation in a XML file ?

But, I'm afraid that it's too late to do such changes for Anjuta 2.30. I'm not sure I will be able to find a solution in one week and it's probably too much hassle for translators.

OK, I added the file back for now though it's really ugly.

Translation in xml files are now problem, intltool can extract them from xml.in files and creates an xml file for each language.

I don't know about all this "if"-stuff though.

Changed bug-title!

Thanks Johannes, but didn't just forgot to push it? I can't see it in the log: http://git.gnome.org/browse/anjuta/log/

Sorry...

Created attachment 155158 [details] [review]
diff of the regenerated file

oops, I forgot to mention, while we are at it, it would be nice to update this file :)

Review of attachment 155158 [details] [review]:

I regenerated the file here so didn't use the patch. It should be up-to-date now anyway.

I have done some investigation and I think the situation is better than expected.

The XML parser in intltool accept invalid XML file too. I have been able to use it on a .wiz file after just adding a root node and changing some quote. I think we can keep almost the same format, just supporting an optional root node. 


Then using intltool-merge, it is possible to include the translation directly in the .wiz file. It creates element in the xml file, so I need to improve the parser to read these new elements and use them for translation instead of using gettext.


When this is done, it makes sense to distribute project templates outside Anjuta. But it needs several files, I think we can rename a .tgz archive of all needed files as anjuta.wiz.tgz. Then, if we use such file in anjuta command line, we automatically expand the archive, install it in the user directory and start the project wizard inside.

I have added a root node (optional to keep compatibility) in all .wiz file and change the quote character when needed.

The extract-translable-strings.pl script and the translatable-strings.h file are not needed anymore, I have removed them.

I have checked that intltool-merge is able to read the .wiz file and merge the translation but please check that everything is fine.

The .wiz files are still not completely valid XML files and finding the right character for quote is a not always obvious as the files are used by different languages (xml, autogen, guile).