Created attachment 15830 [details] [review]
Proposed patch against HEAD.

Created attachment 15831 [details]
Screenshot illustrating the changes.

Changing some bug data.

regs,
 Chris

Looks reasonable. My main question would be: we avoided the 
word "focus" on purpose, so a better group title there
would be good.

Also s/behaviour/behavior/ in default locale

Created attachment 15834 [details] [review]
Updated patch according to Havoc's suggestions.

I used "Selection Behavior" as category title.

regs,
 Chris

Any other ideas?

I'm not part of the usability team (in other words, feel free to
totally ignore my suggestion), but "Window Selection Behavior" seems
like a decent title to me.

I'm going to add screenshot, HIG, and usability keywords.

"Activation"?

Something about this control panel seems fishy, though I can't put
my finger on it.

Activation may be the best, but if we rename it to "Activation",
"Window Activation" or "Activation Behavior", we've got to rename the
strings inside the activation category, too - we would have to replace
select by activate.

regs,
 Chris

Can we get concensus on this?

Just "Window Selection" maybe? seems most consistent with the 
existing text. Adding "Behavior" seems redundant, really.

I like "Window Selection".
Anybody against it?

regs,
 Chris

You could make the dialog title "Window Behavior Preferences"; then
you can remove the repetition of "behavior" from the group headers,
and just call them "Selection" and "Click".  Maybe that would look a
bit odd, though.

I'd definitely suggest s/grab/drag, though.

I'm pretty sure the docs team will have something to say about the
wordiness and terminology in this dialog though, so cc'ing a couple of
them for comments :)

Here are my suggestions for this dialog:

s/Focus Behaviour/Selection Behavior [1]
s/Select windows when the mouse moves over them/Point to window to
select
or
s/Select windows when the mouse moves over them/Point to select
s/Raise selected windows after an interval/Raise selected window after
an interval

[1] Window is not required here as it is in the name of this
preference tool

NEW SECTION
Move Behavior
s/Press-and-hold this key and grab a window to move it/To move a
window, press-and-hold this key then drag the window [2]

[2] "it" is problematic for l10n. In the above example, there could be
confusion about whether "it" refers to the window or the key.

s/Click Behaviour/Titlebar Behavior
Where does the term "Super" key come from? In Windows documentation
this key is referred to as the "Windows logo key" or "WINDOWS"

Note also that there is some discussion in bug 105502 about the term
"Roll Up".

Super is the traditional X terminology for that key; I don't know 
if some old workstation keyboards have a key labeled super or not.

Eugene: I disagree with you about "Press-and-hold this key and grab a
window to move it". It's preconditioned that a key on the keyboard
can't be moved. "To move a window "To move a window, ..." doesn't
sound as good as the matter proposal, at least to my ears - but don't
count on my subjective conviction as I'm not a native speaker.
I agree with the general proposal of avoiding "it", but just if there
is any possibility of being ambigiuous.

regs,
 Chris

Chris: strictly speaking you are correct that there is no ambiguity 
in the meaning of the word "it" in this context, and this usage would 
be perfectly acceptable in an everyday situation. That said, 
rewriting a text string to element "it" almost always clarifies the 
meaning, and this effect is especially true in the technical context. 
Eugene's suggested rewrite provides the natural flow sequence of 
concepts, in other words: What do I want to do -> What do I have to 
do to achieve this goal. 

Also, the flow sequence that Eugene suggests is used elsewhere in the 
desktop UI and application UIs, in user documentation such as the 
User Guide, and in the Help manuals. 

Pat

"That said, rewriting a text string to element "it" almost always
clarifies the meaning"
I agree with you, but
1. In many situations no further clarification is needed. E.g.: I'd
rather use "Point to window to select it" instead of "Point to window to
select". Select...but what? I'd expect that after such an ellipsis a
few options are presented while the usage of "it" finishes the
sentence. In this context it's IMO needed to fill an acoustic gap
2. If it requires the author to use unusual sentence constructions,
the translators may have problems with those as well.

I've got a totally different proposal to fit the needs of good
translations whose authors ought not to take those "it"s wrong:
We should have a simple way of adding comments for translators to
glade files as we just have for plain source files (comments before
gettext strings are evaluated). It should be easy-to-implement and
requires slight additions to glade and it's file format.

"Also, the flow sequence that Eugene suggests is used elsewhere in the 
desktop UI and application UIs, in user documentation such as the 
User Guide, and in the Help manuals."
I don't think the argument counts. It's a 2.3 proposal and argumenting
that a rewrite is wrong makes progress stagnate.

regs,
 Chris

Chris: 
Regarding your point 1 above, I see what you mean by gap. But I would
fill the gap with "the window" not "it". I agree with Pat that
eliminating "it" almost always clarifies the meaning, and that is true
in this case.

I was going to suggest "Point to window to select the window" at first
but thought it was unnecessary given the context, that is:
 Window Preferences
   Selection Behavior
     Point to window to select

However, I now see that "Point to window to select the window" is
clearer. "Point to window to select it" still requires effort on the
part of the user to understand what "it" refers to. Even is that is a
small effort, it is still an effort which we should try to spare the
user.

Regarding your point 2, I don't think "Point to window to select the
window" is an usual sentence construction. However, I would agree that
"Point to window to select" is a bit terse.

And regarding your proposal, I think the key is to get the
English-language labels clear, concise, and unambiguous in the first
place, rather than to document the meaning of the "it"s separately for
translators.

To paraphrase Gordon Geckon, terse is good. Especially in UI labels. 

Frankly, seeing as how the option in question is in the Windows 
Preferences dialog, Focus Behavior group, I think that the option 
label: "Point to select" is ample. 

Really. 

Pat

Created attachment 16143 [details] [review]
Updated patch.

Created attachment 16144 [details]
Screenshot showing the newest version of my patch

Chris: this looks good, I like the shortening of the second option
label to "Raise after selection". I have two minor nits.

Nit 1: I think the sequence of information should be:

Selection Behavior
Move Behavior
Titlebar Behavior

The select and move sections are more closely related, that's why I
think they should be closer together.

Nit 2: s/Super (or "Windows logo")/Super (or Windows logo)

Also, we could do s/Super (or "Windows logo")/Super

If you choose the latter, I can define the Super key in the User Guide
Glossary, saying on an Windows keyboard it has a Windows logo, on a
Sun keyboard, it has a diamond symbol, and so on. What do you think? I
think when I was working on the Sawfish documentation we referred to
this as the Meta key.

Eugene: Nit 1 has been fixed.

> If you choose the latter, I can define the Super key in the User Guide
> Glossary, saying on an Windows keyboard it has a Windows logo, on a
> Sun keyboard, it has a diamond symbol, and so on. What do you think? I
> think when I was working on the Sawfish documentation we referred to
> this as the Meta key.
The first part of your proposal sounds good to me. We should avoid
platform/OS specific hints and instead use meta terms suitable for all
users (like your "Meta" or "Super" proposal).
But I absolutely don't want to use "Super" in this dialog while
Sawfish users will see "Meta". Remember our promise of unification? :)
A quick google search tells me that the expression "meta key" is used
~9 times as often as "super key" whereas "Super" occurs in some other
context as well: Database systems have such a terminus technicus.

regs,
 Chris

Another proposal:
If we want to simplify as much as possible, why don't we
s/_Interval before raising:/Raise _delay: ?

regs,
 Chris

Note that Super and Meta are different keys. The dialog 
actually dynamically checks which one you have in your keymap and uses
that one. 

In other words, type "xmodmap", if you have Meta in some of the output
you'll see Meta, if you have Super you'll see Super.

So have we reached consensus or are we going to discuss this forever
without making a decision?

Chris: I think 'Interval before raising' is better, because it is the
"positive" form. 'Raise delay' is negative. While they both mean the
same thing.

As I see it here, a consensus has been reached.
The current dialog looks horrible compared to this one. Please check
it in :)

Consider adding a comma after "press and hold this key"

So, "To move a window, press-and-hold this key then drag the window:"

So, "To move a window, press-and-hold this key, then drag the window:"

Does this patch still apply?

The discussed changes to the window prefs have been checked in, I'm closing this
bug since there are no more outstanding issues.  If you feel certain issues
haven't been properly addressed please open a new bug as this one has gone on
for too long, reference this bug in any new bugs.