Oh, and "element" should rather be "plugin".

Created attachment 54786 [details] [review]
Proposed patch.

2005-12-21  Christian Neumair  <chris@gnome-de.org>

        Reviewed by:  Ronald S. Bultje  <rbultje@ronald.bitfreak.net>

        * grecord/src/gsr-window.c: (make_play_pipeline),
        (make_record_pipeline):
        * gst-mixer/src/main.c: (main):
        * gstreamer-properties/gstreamer-properties.glade:
          Prevent use of GStreamer slang words ("element", "sink", "source")
          and fix window position for gstreamer-properties (#321536).

reverting the patch from the gnome-2-12 branch because it breaks the string freeze.

changing back plugin to element because they're not plugins - plugins provide features, one of those features are elements.  Completely open to other suggestions if that's still considered slang, as long as it's not "plugin" :)

I noticed Ronald reverted to using plugins.  That means that programs will ask the user to find the gconfaudiosrc, flacenc, ... plug-in, even though no such plugins exist.

I'll ask the i18n team for an opinion.

... or one could fix the strings to ask the user to find the 'gconf', 'flac' etc. plugin (shouldn't even affect translated strings in many cases IIRC).

Tim, the problem is that you don't necessarily know which one you're looking for - any element can be put in the audio profile pipeline.

Here is part of a mail from Shaun McCance about this issue:

<PASTE>
I think I'd prefer to see that sort of thing avoided
altogether by using the long name of the element:

"The GConf audio source could not be found."

Of course, if the desired element isn't installed,
then there's no way to extract the long name.  But
if you're checking for a specific known element,
you can hardcode its long name in your application.

More generally, I don't think element or plug-in
are terms that a lot of non-technical users are
going to recognize, although some users will have
some sense of what a plug-in is.  Solely from the
standpoint of users understanding what's giong on,
I think the choice of terms is irrelevant.  It's
like talking about kernel modules: no amount of
sugar language is going to make it immediately
understandable.

The best solution is probably to use the correct
term, which is element.  And then make sure any
dialogs that really need to talk about elements
have just enough language to convey the gist of
the problem to most people.  Compare:

"Could not find gconfaudiosrc element."

"The gconfaudiosrc audio input element could
not be found on your system.  Without this..."

Simply by saying "audio input element", you give
some sense of what's going on.  It's not going to
turn Aunt Tilly into a GStreamer hacker overnight,
but it doesn't sound as horribly cryptic as the
first example.

Then we add troubleshooting sections to the help
files (the single most useful thing to have in
help files, and the single least common thing we
ever have in Gnome help files), and we make that
dialog link to that.
</PASTE>

I'd like to get this settled before the next release and am inclined to follow Shaun's lead on it.

I've changed them because of consensus of the i18n team on this thing. The word "element" should be avoided at all cost, I've been told, hence the reversal. Users, mostly, won't be able to tell a plugin from an element anyway, I agree with Shaun on that.

Since we have two people from the same team contradicting each other on this, I'm not gonna decide, I'd like them to fight it out in public with mud and cheerleaders and will take whatever stands up at the end. In other words, let's throw it on d-d-l.

I've seen no one from the i18n team speak out on this at all.  This is lame.  The change needs reverting - it was made late without any record, so the weight should be towards keeping how it was in the first place, esp. if Shaun says he would lean towards using the correct term.

This was marked a blocker very specifically for the release - I don't understand how you can clear it and release and ignore this.

Put this on /.

No, to be serious:

From L10N standpoint it doesn't matter that much if you call it element or plug-in. Translators might take the same term for both. That's my personal opinion, not gnome-i18n's.

From a users standpoint I perfectly follow Shaun's idea. Plug-in or Element don't mean anything to me. I would need some advice how to fix my issue, without extensive use of forums or much google'ing. Simply say what had failed and give some hints about it through integrated help. If you don't come around cryptic things like "GConf Audio Source Element", point explicitly to the integrated help in those messages.
Try to avoid a flame war about naming. This leads to nothing valuable for the end users... last seen on fedora-devel-list, target background images ;)

Maybe the perfect solution can't be done in time for GNOME 2.14, but it's worth to follow up on this.

-- Frank, who's reading gnome-i18n and watching Christian's bugs for historical I18N reasons.

Thomas,

I decided in favour of Christian's comment because I believe he is right. Plug-in is computer slang; element is GStreamer slang. Therefore, I believe we should expose users to the word "plug-in", not "element". They won't know the difference anyway. The fact that it's technically inaccurate is anecdotical at best.

Please revert your post-release changes until, as I requested, Shaun and Christian come to an agreement on how we should handle this. I see Shaun's point, but I still agree with Christian. In the end, if those two agree, I will go with whatever they say. But do *not* commit this stuff that I disagree with explicitely. I reverted it for a reason.

(Don't get me wrong, I like the better error messages; they just re-introduce a gst-specific slang word that I purposefully removed, and I disagree with that part of the patch as explained above.)

Ronald,

I think this is being made into too much.

It's pretty simple.
- Christian made a change without much rationale, to messages that were written on purpose to contain element when we wrote gnome-sound-recorder.  That was the status quo situation.
- The change isn't that much better, because plug-in is only slightly less jargony, as two docs people are saying when asked about it.
- A contended change on which there is obvious disagreement should not have been made in the first place; you claim there was consensus from i18n but I see no record of consensus on this issue.  So it is the original patch that needs reverting.  (I mailed i18n and docs on this very topic, and Shaun was the one who replied.)
- Now, instead of getting negative about it (I felt it was silly you reverted it twice when the situation isn't obviously better with the patch), I decided to properly fix it by providing decent error messages.

You've got two docs people saying that it doesn't matter if you pick element or plug-in - neither is useful to the user.  And you've got a GStreamer maintainer saying that if the choice doesn't matter, the correct choice is preferred.

I do not want this dragged out endlessly and miss all related freezes and release a gnome-sound-recorder with crappy error messages.  The original change was not a good change, and this one is definately better.  If you feel element should not be used, make your case to -i18n and -docs.  I did my homework for this bug, and I want it to be resolved positively, not weighed down in endless debate and with a crappy result.

For the record, the gnome-media 2.13.90 release contains the following two code snippets:

                show_error_dialog (NULL, NULL, _("Could not find GStreamer element "
                                   "\"%s\" - please install it"), "gconfaudiosink");

and
                show_error_dialog (NULL, NULL, _("Could not find GStreamer plugin "
                                   "\"%s\" - please install it"), "gconfaudiosrc");

I quote myself:

"I believe he is right"
"[wait] until [..] Shaun and Christian come to an agreement on how we should handle this"
"I will go with whatever they say"

If you want it resolved quickly, then make Shaun and Christian discuss it. You disagree with my change, I disagree with yours. I don't see why you would have the right to undo my changes and break freezes, it's not like your opinion is more important than mine.

I'm not going to argue over this for a long time.  If a change is made and there is disagreement, it should be rolled back and discussed, not forward and discussed.  If agreement can't be reached, users should not be affected by the change.

While I feel that if you still think that the change Christian made is correct, it is you or Christian who should argue for it, I'm going to do the work myself of making Shaun and Christian discuss it, because it's getting pretty clear that the handling of this bug is unrelated to the actual bug.  I don't feel like releasing a gnome-media with even crappier dialogs than it already has.

I didn't break any freeze with this, btw.

As to what happens when two maintainers disagree - case by case I guess.  I disagreed completely switching gnome-cd to be ripping-based instead of just using the ioctl interface and have the cable connected.  In that case, you decided, and since you did all the work on that, fine by me, I can suck it up.

In this particular case, the dialogs now are infinitely better than what they were.  Seems pretty clear to me that if the dispute does not get resolved, the person who did the positive step forward gets to choose.

"(Don't get me wrong, I like the better error messages; they just re-introduce a gst-specific slang word that I purposefully removed, and I disagree with that part of the patch as explained above.)"

I'm not asking to revert the patch. I ask to revert the plugin->element change. This is the last time I ask nicely.

This is getting ugly.  I don't have a definitive reference for this.  It's not as if the Chicago Manual of Style talks about GStreamer.  I don't even have a strong argument, just my gut instinct, and even that is giving me mixed signals.

1. We want to avoid technical jargon when we can.  On the other hand, the only way you can provide a reasonably useful error message is to use technical jargon.  If this were a discussion about whether to say element or plugin in the preferences dialog, I'd smack everybody involved.  But it's an error dialog.  Something went wrong, and we can't tell you about it without exposing a little bit of how things work.

2. Neither element nor plugin is going to be immediately understandable to most non-technical users.  Plugin, however, does occur elsewhere in our interfaces.  (gedit has a Plugins tab in its preferences dialog.)  Then again, element is a generic word that any English speaker ought to know.  Sufficient adjectives can make a generic noun irrelevant.  Hence my recommendation for language like "audio input element".  The word element fades away, and you see that the problem has something to do with getting audio input.

3. Good trouble-shooting guides in the help can do far more for the user than the choice of which incomprehensable term to use.  But the fact is, we don't have good trouble-shooting guides in our help, and it's unrealistic to expect it to appear overnight.

4. So when all else fails, make sure your error messages are Googleable.  Make sure they convey useful information to the computer-savvy nephew, or the fellow on the phone from tech support.  But also try to make the language convey some sense of the problem to normal folks.  If it looks less too scary, they might not even bother asking the computer-savvy nephew.

5. It occurs to me that the packages providing the base set of elements for GStreamer are named gst-plugins-*.  And there's the GStreamer Plugin Writer's Guide.  Googling for gstreamer element gives 70,600 hits; for gstreamer plugin gives 472,000 hits.

6. We are late in the release cycle, and flip-flopping this won't help anybody.  When there's disagreement, status quo is generally preferred.  It's like Risk: a tie goes to the defender.  You guys play Risk?  I love Risk.

See how I can't give you a clear answer on this?  I will make one very clear point, though: We have numerous GStreamer-using applications in our desktop.  Each of them is probably going to need to talk about GStreamer elements/plugins in some error dialog somewhere.  Either all of them should talk about elements, or all of them should talk about plugins.

The current text changed again, and is probably clearer than either above. Let's close this and think happy thoughts.