GNOME Bugzilla – Bug 121330
All list type default values in schemas are stripped in intltool-merge
Last modified: 2004-12-22 21:47:04 UTC
For example, in gtali.schemas.in from gnome games: <type>list</type> <list_type>string</list_type> <locale name="C"> <default>[Human,Wilber,Bill,Monica,Kenneth,Janet]</default> <short></short> <long></long> </locale> Becomes this in gtali.schemas: <type>list</type> <list_type>string</list_type> <locale name="C"> <default></default> <short></short> <long></long> And caused failure during schemas registration. Here is the relevant part of code in intltool-merge (schemas_merge_translations): $c_default_block =~ s/default>\[.*?\]/default>/s; print OUTPUT "$locale_start_spaces$c_default_block"; It seems that all list type values are treated as comment instead and be removed.
Any ideas on this one? I can't see the point of just removing all list defaults... is the fix to simple remove that line? Seems to work at a very quick glance, but my perl/intltool knowledge is very limited.
It seems to me that <tag>[.....]</tag> notation was supposedly to add into intltool for specifying comments in the old days, so that translators would know what's going on (e.g. telling translators not to translate numbers into localized versions). Yet this usage is not widely known. Actually I haven't seen any schemas using it as comment... However, later it was decided widely to use [....] as a notation for list values, but the change is not adopted accordingly in intltool. The above was just my guess anyway. Kenneth may know the ins and outs of this problem. Kenneth?
hmm, [comments] was used to add comments to strings like "[show as ]Image" in Nautilus. I guess we can disallow that for gconf files. I would happily accept a patch doing that if no better sollution is found. Kenneth
I was looking at this today. It is sufficient to just remove the line that Abel initially identified. A search through the CVS HEAD of the all modules in the GNOME release show that none of them are using the [comment] format, but a number are using the [item1, item2] format. So this should get fixed soon. Longer term (when #123914 is fixed), it is pretty easy to add in support for XML-style comments in schema files that make it into the PO file (I pretty much have that working, but I need #123914 resolved first to avoid clashes). Then we can add translation-aiding comments when necessary. But apparently we can survive without that feature at the moment.
Created attachment 22172 [details] [review] Trivial fix (including fixing the tests)
hmm, but there is support for [] in strings in glib now, so this might be more populair. I guess they are not used in nautilus any longer as they were used for the medusa parts. But the patch should be good anyway, since it is not intltool which should strip the []'s, but the program showing the strings.
Kenneth, IIRC months ago I wanted to add support for comments for the rfc822deb format, and you showed me what had been done with Nautilus. Thus I decided to remove (Perl syntax) "\[\s[^\[\]]*\]$", see e.g. rfc822deb_merge_translations in intltool-merge. From the messages on this bugreport, I guess that "^\[[^\[\]]*\s\]" could also be a valid comment (I should have taken this one, will try to support both). The key point is that a space must be present for this sequence to be considered as a comment, so bracketed expression in [Save as ]Image is a comment whereas <foo>[bar,baz]</foo> is not. This space improves readability, and prevents all bracketed expressions from being removed. Denis
I have seen comments like this in Nautilus: "[View as ]Files that are[ older than 5 days]" So it is more complicated like that.
Your example tend to show that by design, comments in Nautilus embed a significant space, which was my point. So if you want to follow a similar rule (what I did without any problem for rfc822deb), you only have to replace $c_default_block =~ s/default>\[.*?\]/default>/s; by $c_default_block =~ s/default>\[.*?\s\]/default>/s; in intltool-merge, and bracketed lists will no more be removed. But allowing brackets within comments is error prone, I prefer $c_default_block =~ s/default>\[[^\[\]]*\s\]/default>/s; PS: could intltool bugreports be forwarded to xml-i18n-tools?
They probably could. I just don't know where to set that up. If you tell me how, I will look into it.
Malcolm, FYI #123914 has just been fixed.
Someone told me (sometime ago, can't remember who) that he comment support in glib was using | like "verb|this is a string". I don't know if this is the case or not, but it would be nice to know :-)
Feel free to check in this patch Malcolm
Was this ever checked in?
I did not check it in. I kept meaning to confirm that the commit Callum McKenzie did as part of bug #133369 was a duplicate of this work. It certainly is intended to have the same effect, so if this bug still exists, we should reopen #133369 and work from there. *** This bug has been marked as a duplicate of 133369 ***