Merge lp://qastaging/~cldunlap1/ubuntu/oneiric/xchat/fix-for-816506 into lp://qastaging/ubuntu/oneiric/xchat

Hi Chad, thanks for your contribution to Ubuntu.

I'm not aware of any Ubuntu specific user interface guidelines that this change would fall under, and to be honest, I see a fairly wide variety of styles in the few applications I've checked. So I don't know under what criteria ellipsis should or should not appear. Thus I think it would generally not be a good idea to diverge from Debian on this.

But I'm also not aware of any Debian guidelines that would cover this either, so then I'd default to upstream, or possibly for Gnome tools, the Gnome user interface guidelines.

http://developer.gnome.org/hig-book/stable/

This page covers ellipsis:

http://developer.gnome.org/hig-book/stable/menus-design.html.en

"Label the menu item with a trailing ellipsis ("...") only if the command requires further input from the user before it can be performed. Do not add an ellipsis to items that only present a confirmation dialog (such as Delete), or that do not require further input (such as Properties, Preferences or About)."

which seems to say that the Preferences item should not have ellipsis.

One thing to be concerned about when making changes like this, especially for SRU'd packages, is that changing human readable text in an application will break the translations, as you may have noticed when you touched the .po files. In this case, I think you could probably fix those too since ... isn't translated, but that may cause some disruption with translations in Launchpad. I honestly don't do much translation work, but these guidelines may be helpful:

https://help.launchpad.net/Translations/StartingToTranslate

Keeping all of the above in mind, I would suggest filing this bug and patch upstream in the xchat tracker:

http://sourceforge.net/tracker/?func=browse&group_id=239&atid=100239

(Also look at xchat.org). It would then be up to them whether to accept the patch or not, and that would naturally then flow to Debian and Ubuntu.

As for your patch in particular, while I think it would be best submitted upstream, you did a pretty good job of putting the patch together. One thing that's missing is DEP 3 headers on your quilt patch:

http://dep.debian.net/deps/dep3/

By marking up the patch with these headers, you will help when the next person is evaluating the patch later, and deciding whether it has been superseded by a Debian or upstream change. It can also contain links to the upstream tracker that a future merger could look to to see if it's still applicable.

You might also take a look at the Ubuntu bug status guidelines:

https://wiki.ubuntu.com/Bugs/Status

Your contributions to Ubuntu are valuable to us, and I thank you for this one. Even though I'm going to mark my review as Disapprove, I still appreciate the work you've done. The review status just reflects my opinion that the bug and fix should be submitted upstream.

Cheers!

Barry, mpt believes the GNOME HIG is wrong and Preferences/Settings items in mens should have ellipses.

https://bugs.launchpad.net/indicator-sound/+bug/785571/comments/7

I don't believe he intends for Ubuntu to patch every single app though so there will be inconsistency since he hasn't managed to get the GNOME HIG changed. Nor is it likely that upstream would change their style to violate the GNOME HIG to fit in better on Ubuntu.

Personally, I think the HIG is right, but the inconsistency is rather annoying. Another Ubuntu-specific inconsistency is using "&" instead of "and" in System Settings. "Time & Date" is the Ubuntu panel.

What Jeremy said, plus I don't think it's worth carrying an Ubuntu patch for this alone.

The HIG's inconsistency with itself already causes inconsistency in XChat alone: the "Preferences" item doesn't have ellipsis, but all the various "Advanced" preferences items correctly do. So it's not as if Ubuntu is making anything worse.

Over a months without activity, comments above suggest the change should be rejected.
Also the diff is targeting a release version of Ubuntu.

I'm going to reject that merge proposal based on that, if you feel like this should be changed anyway, please resubmit against the current development version.

For what it's worth, my opinion is that we shouldn't diverge from Debian on such small changes as they end up being a pain to merge.