GNOME Bugzilla – Bug 98861
Version 0.23 doesn't ignore silent line breaks
Last modified: 2005-06-10 21:31:15 UTC
After an update to intltool-0.23, we found out that it does not ignore silent line breaks. This breaks/makes fuzzy some translations on gnome-2-0 branch. For examle, current gedit CVS code (gnome-2-0). - have 100% translated with intltool-0.22 - update to intltool 0.23 - rerun intltool-update cs on the same code, now there are 4 fuzzies. The fuzzies are the same strings, except it has to \n\n at the end. With previous version, the \n\n were stripped.
I'll attach the messages that caused the sudden fuzzyness when upgrading intltool. Note the additional newlines before </atkpropery>; they are what caused the fuzziness, since they were no longer ignored but treated as \n\n.
Created attachment 12371 [details] The affected messages in the source
Ignore the strange characters in this, I was pasting this from a mail and I'm pretty sure this is where those strange characters come from.
So should these be stripped for letting it show up translated? Or what is the problem? If so I have to fix this :)
To me, the bug seems to be this: Given the XML fragment: <tag>text </tag> For this fragment intltool-0.22 generated the string "text" and intltool-0.23 generated the string "text\n". Now, forget the fuzziness, string freeze and all. The question is: For what string is libglade2 (or whatever) asking gettext a translation? To properly *display* the translated string for the user, this string should match the one generated by intltool. Is it "text" or "text\n"?
Can anyone check this? If glade wants them stripped, then so do we.
Can some of you translators check the correct think to do, so we can fix this. Patch is always appreciated.
I am still waiting :-(
Is this problem still here?
Does anyone know how can this most easily be checked?
I am pretty sure that intltool will return "text" for the <tag>text\n</tag> case above.
Rodney: indeed, but I'm wondering what's actually *Glade* doing, and what's the easiest way to check if it does it the same way?
FWIW, I checked this, and it seems libglade actually cares about spaces, and intltool-extract does as well in gettext/glade mode. So, this seems to work ok, so this was probably fixed in the meantime.