GNOME Bugzilla – Bug 73586
Entity encodings should not be used in po files
Last modified: 2004-12-22 21:47:04 UTC
[This is a split from bug 73339, which was about another bug/request, but where the comments turned out to be more about this problem] Currently, intltool puts < > from XML files as < and > in po files. It should not, for many reasons: * Worsens readability * Makes po files not transparent, messages will need retranslation if they are moved from one type of file to another, even if they are exactly the same
Hmm. The problem I was pointing out was different to this. It looked to me like it was copying '<', '>' etc. from the XML into the po files, whereas it should be converting back to '<', '>' in the po files. e.g. a string in the interface could be: '<b>Fast</b>'. This is saved in the Glade XML file as: <property name="label"><b>Fast</b></property> and it looked like intltool was writing this in the po file: msgid "<b>Fast</b>" But that is incorrect as when libglade loads the XML it will call gettext with the string "<b>Fast</b>" (the XML parser will have converted the entities back to '<' and '>').
Unfortunately, this conflicts with the new feature Sven added for the Gimp. But I guess we can do it your way (which seems quite logical to me) for Glade files, and his way (which also makes sense) for generic XML files. Or maybe you guys can figure out something even better. To help make this clear, I'd like some test cases in the intltool test directory that show how the current behavior is right or wrong for these various cases. Then it's easy for us to fix the scripts.
Damon, I guess Sven was asking you why you store <b>Fast</b> as <property name="label"><b>Fast</b></property> in the glade xml file, and not as <property name="label"><b>Fast</b></property> Darin, what about .server.in files. Don't they also have some of these problems?
No, .server files don't use any markup inside the things we translate.
I don't want to include markup tags in Glade's DTD. Maybe if the markup has its own DTD we could use namespaces and such. But I'm not sure its worth the hassle. The bug is a problem with plain strings which use '<' as well, so it would still need fixing anyway.
I'd also welcome that change but I don't think it's a trivial one.
If we are extracting from a glade file I now convert &lf to < and > to >. I hope that solves some of the problems. Can I close this bug report?
Glade saves entities for '<', '>', '&'and '"', so if you add the other 2 I think this is fixed.
They were already there. So it should be fixed.