[PATCH] Add long comments to shared-mime-info XML file

[Andrew J. Montalenti]

Dear Christian,

On Thu, 2005-10-13 at 12:17 +0200, Christian Neumair wrote:
> > I don't know about this patch.  Some of your long forms are a bit too
> > long.  "Cascading Style Sheets stylesheet" and "Microsoft Windows Media
> > Video video", for example, are particularly long and redundant, and
> > would look stupid should a programmer ever actually employ the long
> > comment form.
> 
> Maybe you could come up with alternate proposals?

I guess it wasn't clear that I was pointing to two separate problems.
I'll make it clear here:

(1) If we are to have long comments, they shouldn't be redundant.
"Cascading Style Sheet Styles stylesheet" is just silly, as is "Windows
Media Video video".  This doesn't help the user, and looks like a
mistake.  If I were seeing a dialog showing asking me with what
application I'd like to open this "Cascading Style Sheet stylesheet",
I'd immediately think the programmer blindly expanded a "CSS" acronym to
its full name in a string that, prior, had "CSS stylesheet" in it, and
didn't realize there'd be redundancies.

(2) Are long comments even necessary or useful in the form you have
enumerated them?

> > Since a lot of what you are doing seems to be acronym expansion, I think
> > a better approach might be to use what many web pages employ nowadays,
> > namely an <abbr> tag.
> 
> Isn't that exactly what I was proposing, just that the <abbr> tag you
> propose maps to the <comment> tag of my proposal, i.e.
> 
>              | short desc., long desc. (expanded)
> current       <comment>,    <comment>
> your proposal <abbr>,       <comment>
> my proposal   <comment>,    <long-comment>

You didn't understand me.  I wrote:

"but it seems to me rather than writing 'Microsoft
Windows Media Video video', it would make more sense to write 'WMV
Video' and have WMV be an abbreviation whose tooltip would provide the
expansion to "Microsoft Windows Media Video".  But this doesn't seem
like it can be done in a quick-and-dirty patch just to this XML file,
but rather needs some understanding from those who are reading it."

As you can see, the important thing about what I said is that through an
abbr tag, the reader/parser understands what part of the string is
actually an acronym, and thus depending on a proper use of that
information (only expanding the acronym on some event from the user,
like a mouseover event with a cursor change to a question mark, as is
done in newer web browsers), we can throw around the acronym freely
while still allowing the expansion to those who are curious.

So, to summarize:

o Your proposal is to have two categories of comments--long and
short--whose strings are used in different contexts.

o My proposal is to have one category of comments, which has a
contextual clue (<abbr> tag) whenever parts of those strings may need to
offer an acronym expansion.

> > Just to further push my point, many desktop publishers use TIFF files
> > and JPEG files and PDF files all the time, without caring at all that
> > TIFF stands for Tagged Image File Format
> 
> Exactly. Over at Nautilus, we're also suffering from the problem that
> the current <comment>s are simply too long.

Right, and I agree with your general sentiment: you want the shorter
ones to be there, while the longer ones are available.  But what I'm
saying is, I don't think the "long comments" are useful, and I think
it's hard to get "acronym expansion" right while still providing an
"object name" AND not sounding hokey (i.e., as above, expanding WMV
Video without repeating the word "video").  But it's not so bad if you
move your mouse over WMV in the string "WMV video" and find a tooltip
that expands to "Windows Media Video".

The acronyms only satisfy a kind of curiosity for technophiles, or
sometimes--but rarely--provide a description of the kind of file.  (I do
mean it when I say rarely: think mp3, whose expansion says nothing about
music, or ogg, etc.)

You also don't seem to realize that using an <abbr> tag also implements
your <long-comment> anyway, just with an additional step (namely, parse
abbr tag, replace acronym with expanded one).  So, if you wanted to
temporarily implement long comments "your way", you could.  But this
way, later on, if GtkLabel's get some feature equivalent to <abbr> tags,
we'll be able to use them.  And for now, we can also do other things
like "sort by acronym" in a display of recognizable file types, or
"search acronyms," without having to do dirty hacks like a strcmp
between the <long- and non-<long- comments.  As is, even your regular
<comment>'s don't have any notion of pointing out where the acronym is.

> > Anyway, I think this patch needs at least a _bit_ of discussion before a
> > commit, and at least needs to have some of these sillier long entries
> > corrected.
> 
> Doesn't it do that already? The file is quiet huge, and I've spent some
> time. It is just meant as a starting point for further development.

You think "correcting" long entries means having short ones that will
make sense to users.  I think correcting long entries means correcting
long entries that will make sense to users.

I understand you spent time on it--it's obviously a step in the right
direction, but before one commits code to it, don't you think we should
think through the best solution?

-- 
Andrew J. Montalenti
http://www.pixelmonkey.org