After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 121330 - All list type default values in schemas are stripped in intltool-merge
All list type default values in schemas are stripped in intltool-merge
Status: RESOLVED DUPLICATE of bug 133369
Product: intltool
Classification: Deprecated
Component: general
Other All
: Normal normal
: ---
Assigned To: intltool maintainers
intltool maintainers
Depends on:
Reported: 2003-09-03 05:40 UTC by Abel Cheung
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---

Trivial fix (including fixing the tests) (3.89 KB, patch)
2003-12-07 11:27 UTC, Malcolm Tredinnick
none Details | Review

Description Abel Cheung 2003-09-03 05:40:08 UTC
For example, in from gnome games:

      <locale name="C">

Becomes this in gtali.schemas:

      <locale name="C">

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
Comment 1 Richard Hult 2003-11-02 00:39:48 UTC
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.
Comment 2 Abel Cheung 2003-11-04 20:18:15 UTC
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.

Comment 3 Kenneth Rohde Christiansen 2003-11-04 20:43:00 UTC
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.

Comment 4 Malcolm Tredinnick 2003-12-07 11:22:52 UTC
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.
Comment 5 Malcolm Tredinnick 2003-12-07 11:27:51 UTC
Created attachment 22172 [details] [review]
Trivial fix (including fixing the tests)
Comment 6 Kenneth Rohde Christiansen 2003-12-07 16:35:12 UTC
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.
Comment 7 Denis Barbier 2003-12-11 12:58:48 UTC

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
is not.  This space improves readability, and prevents all bracketed
expressions from being removed.

Comment 8 Kenneth Rohde Christiansen 2003-12-11 13:58:58 UTC
I have seen comments like this in Nautilus:

"[View as ]Files that are[ older than 5 days]"

So it is more complicated like that. 
Comment 9 Denis Barbier 2003-12-11 17:47:13 UTC
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;
  $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?
Comment 10 Kenneth Rohde Christiansen 2003-12-16 14:31:17 UTC
They probably could. I just don't know where to set that up. If you
tell me how, I will look into it.
Comment 11 Denis Barbier 2004-01-07 00:20:59 UTC
Malcolm, FYI #123914 has just been fixed.
Comment 12 Kenneth Rohde Christiansen 2004-01-07 17:04:31 UTC
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 :-) 
Comment 13 Kenneth Rohde Christiansen 2004-01-29 12:25:02 UTC
Feel free to check in this patch Malcolm
Comment 14 Kenneth Rohde Christiansen 2004-04-26 08:47:29 UTC
Was this ever checked in?
Comment 15 Malcolm Tredinnick 2004-04-26 21:44:27 UTC
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 ***