478468 - lowercase interface elements in message window header bar are inconsistent UI (mail header labels and button labels should be capitalized)

Status: RESOLVED FIXED

(Thunderbird :: Message Reader UI, defect)

Description

[Joachim Kock]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_6; en-us) AppleWebKit/525.18.1 (KHTML, like Gecko) Version/3.1.2 Safari/525.20.1
Build Identifier: version 3.0b1: the about box says: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.18) Gecko/20081105 Thunderbird/2.0.0.18 Mnenhy/0.7.6.0

In the new header bar (expanded), the header fields now appear 
with lowercase initial.  There are two good reasons to stick with
proper capitalisation:

One is that since the beginning of email, those headers have had 
proper capitalisation, and this is what you see if you look into
the raw source of the message.

The other is that there is a long tradition in typography and in
computer interface design to use proper capitalisation in static
text widgets as well as in buttons.

There is a similar problem with the buttons: "reply…", "forward…"
etc.  Buttons should have capitalised text.

You may object that it makes no big difference.  Indeed it is
not a big deal.  But what could be the reason that led the
programmer to change the capitalisation?

Reproducible: Always

Steps to Reproduce:
1. Open a received message
2.
3.
Actual Results:  
header fields and buttons appear with lowercase initial

Expected Results:  
they should be properly capialised

Comment 1

[Joachim Kock]

From the comments in Bug 456818 it seems that these strings were introduced
around 2008-11-23.  In comment#18 there is this excerpt from a diff:

+<!ENTITY hdrReplyButton.label "reply">
+<!ENTITY hdrForwardButton.label "forward">
+<!ENTITY hdrJunkButton.label "mark as junk">
+<!ENTITY hdrTrashButton.tooltiptext "delete">

It seems clear then, that as far as the buttons are concerned the bug can be 
fixed by modifying these entity declarations.  Of course it will also assume 
a search throughout the code base to ensure that the button labels are not
referenced anywhere.

I also read in Bug 456818 about a "string freeze".  Of course the
developers will know when it is an appropriate time to fix the problem. 
As mentioned, this is a minor issue indeed.

Cheers,
Joachim.

Comment 2

[Mark Banner (:standard8)]

(In reply to comment #0)
> User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_6; en-us)
> AppleWebKit/525.18.1 (KHTML, like Gecko) Version/3.1.2 Safari/525.20.1
> Build Identifier: version 3.0b1: the about box says: Mozilla/5.0 (Macintosh; U;
> Intel Mac OS X; en-US; rv:1.8.1.18) Gecko/20081105 Thunderbird/2.0.0.18
> Mnenhy/0.7.6.0

If your about box says something different then you've overridden your user agent (possibly via Mnenhy).

> One is that since the beginning of email, those headers have had 
> proper capitalisation, and this is what you see if you look into
> the raw source of the message.
> 
> The other is that there is a long tradition in typography and in
> computer interface design to use proper capitalisation in static
> text widgets as well as in buttons.

Why should it stay the same? Just because that's the way it has always been done?

If I recall correctly the change was purposely done to change the emphasis of the display - i.e. not focusing on the labels With Big Capital Letters, but the actual information that a user needs to know.

Anyway, I'm pretty sure this is won't fix. cc'ing Bryan who is our user-experience lead to confirm this.

Comment 3

[Joachim Kock]

> Why should it stay the same? Just because that's the way it has 
> always been done?

That's correct.  I invoked typesetting tradition and computer
interface tradition.  Let me in fact invoke the rules and guidelines
for usage of the English language (as well as most other latin-script
languages): Start with a capital letter.

> If I recall correctly the change was purposely done to change 
> the emphasis of the display - i.e. not focusing on the labels 
> With Big Capital Letters, but the actual information that a user 
> needs to know.

I don't buy this argument.  Escaping from standard usage is what
will catch the attention, like saying 'Hey, I'm a new fancy button,
notice my nonchalant lack of capitalisation!'  It is a well-known
trick in marketing to invent alternative usage of uppercase and
lowercase letters.  If Thunderbird wants to make the buttons
discrete and objective -- and I agree with striving for this --
I think it is better to stick to tradition.

Just my two cents.  But of course it is fair enough if the
interface expert decides to close the bug as WONTFIX.

Cheers,
Joachim.

PS: Even for cross-platform application design, it is always worth
taking a quick glance at the Apple Human Interface Guidelines
http://developer.apple.com/documentation/userexperience/Conceptual/AppleHIGuidelines/XHIGText/chapter_14_section_3.html#//apple_ref/doc/uid/TP30000365-BABDIBBH
Microsoft does too.  These guys know what they are doing.

Comment 4

[Bryan Clark (DevTools PM) [:clarkbw]]

I'm reading 2 parts here, it's hard to judge the overall usage of lowercase.

1) Labels in the subject header.  I switched us from the "traditional" capitalization to a lowercase header because I wanted to decrease the salience of the labels.  Lowercase text plus a reduced contrast helps to push the the labels into the background, allowing the user content more visibility.  The information is placed in a consistent order and tends to define itself, with the labels only needed for clarification.  Meaning that when you read the subject line you are not often confused between the subject and the name of the person sending the messages.  If a person were confused the labels are there as guides, however I don't want them to be required reading every time a person reads the subject line.

Capitalized labels make the sentence start with the label (sentence starts with To,Cc, Subject).

ex: To: Bryan Clark

Lowercase labels make the sentence start with the user content.

ex: to: Joachim Kock

Additional changes in the colouring decrease the contrast and further remove the label from the line.

ex: //to:// Joachim Kock

These are common typographical techniques so I'm not sure what traditions you're referring to are being violated.

The original "traditional" label layout of "Suject: ..." likely has no real typographical background and more likely just follows what the email headers used.  However there are a number of other ways in which Thunderbird manipulates the headers to make them more readable and understandable for the user.

2) Button text capitalization.  I completely agree that there are reasonable arguments [1] to be made for both the lowercase and capitalization of the text on buttons.  I wanted these buttons, because there are a few of them and they are inline with the content to only stand out a little as buttons.  I tried a number of different combinations (Capitalization with flat borders, lowercase with flat borders, lowercase with button borders, etc.) to make them stand out, but not overrun the visible content area around them. YMMV

A HIG is excellent for describing the decisions made in a release such that other developers can understand and integrate well.  This is because a HIG is not a forward looking document as much as it is looking backwards and describing the commonalities purposefully shared. I've worked on a HIG before.
http://library.gnome.org/devel/hig-book/stable/credits-active-authors.html.en

[1] I hasten to mention that tradition is never a clean argument.  There are a number of traditions that have continued for good reason and just as many, if not more, that have stopped for good reason. (I get to quote T.S. Elliot!) "A tradition without intelligence is not worth having"

I would recommend a WONTFIX here for TB in general, but would like to provide an easy solution to this.  I believe if you add the following into your userChrome.css you would get the capitalization you want. (untested)

/* header labels */
.headerNameBox > .headerName { text-transform: capitalize; }
/* button text */
.msgHeaderView-button { text-transform: capitalize; }

Comment 5

[Joachim Kock]

Thank you for the detailed explanations in #4.

WONTFIX is a reasonable resolution, if I am the only person
complaining.

Cheers,
Joachim.

Comment 6

[Bryan Clark (DevTools PM) [:clarkbw]]

Just thinking back to this bug recently that this might have been over an l10n issue that I didn't realize at the time.  Alexander gave a great explanation in bug 495485 of how the lowercase strings look very strange in German.  If this was the case you could open a new bug about adding a translation note to the strings so that locales can decide what is best.

Comment 8

[Peter Lairo]

There seem to be two different (although related) issues here:

1. Capitalization of buttons (Reply, Reply all, Forward, Delete)

2. Capitalization of labels (From, To, Subject, Date)

(In reply to comment #4)
> 1) I wanted to decrease the salience of the labels [e.g., From, Subject, To].

A gray color is perfectly sufficient to achieve this.

> The original "traditional" label layout of "Suject: ..." likely has no real
> typographical background

That is not true. The typographical background is that it looks better, and titles have been capitalized throughout history.

Grammatically, the label (e.g., "Subject") is a *title*; and tiles are capitalized[1]. Failing to do that is wrong  (besides looking conspicuously bad).

[1] http://www.drgrammar.org/faqs/#83

> 2) Button text capitalization. [...] I would recommend a WONTFIX

I fully agree that the buttons should be capitalized for the grammatical reasons linked above and for consistency with the text version of all other toolbars in the known universe.

One of these things needs to happen:

 1. Capitalize the buttons text
 2. Capitalize the labels (e.g., Subject, to)
 3. Do both #1 and #2

I hope it will be #3.

This bug needs to be REOPENED!

Comment 9

[Peter Lairo]

(In reply to comment #8)
> for consistency with the text version of all other
> toolbars in the known universe.

I meant: for consistency with Thunderbird's toolbar. ;-)

Comment 10

[Peter Lairo]

Please make this bug block bug 456814.

Comment 11

[John Beranek]

I very much agree, I think the lower case labels and email headers look horrible and clash with the rest of the Thunderbird UI.

Comment 12

[jweber2]

I agree the lower case looks out of place with all the other typography choices. Looks like someone trying to emulate an old Swiss graphic designer.

Comment 14

[Miguel]

I strongly agree with the request and I would kindly ask for this to be reconsidered.

As I previously commented, most email clients (Evolution, Outlook, LiveDesktop  and Apple Mail) use capitalized buttons and label versions of the ones we're discussing here.

Although I understand that typographical techniques are more complex than what I know I also think that what we really want is a professional appealing look and for most of us, a professional look is hardly compatible with not tradition related but grammatical mistakes. As it's been commented in the previous comments there are other techniques if we want move the focus out of the labels.

I'm bringing this back to the community attention as I think it's an important issue and workaround provided in comment #4 doesn't seem to work in Thunderbird 3.0.

Regards,

Comment 15

[mark]

I'd agree that this should ideally be changed, or at least made configurable. The suggested fix in userchrome.css doesn't seem to work.

As far as reasons go, my biggest would be consistency with the rest of the UI, both with regard to the buttons and the 'from' and 'to' labels (which are 'From' and 'To' when composing a new mail).  

The Re: in replies is currently capitalized, so the arguments in comment #4 are inconsistent in this regard too (which is not to say that I'd like the Re: changed to re: )

Comment 17

[Richard Mlynarik]

WONTFIX is unacceptable.

People take time to suggest product improvements, even if they don't have the skill or the pain tolerance (the Mozilla/TB new contributor energy threshold is just about infinite from my perspective) to actually code the fix.  Blowing them off is unhelpful.

There's a real, if trivial, problem here.  If there weren't nobody would notice is, and nobody would report it.

(And yes, I have contributed many many many man-years to free software, thank you, so don't pull the beaten-upon unpaid volunteer line!  I know all about it.)

I strongly suggest marking this bug as REOPENED, even if at a priority that means nobody is likely to get around to resolving it any time soon.  At least that acknowledges (a) the defect and (b) the validity and worth of user-contributed bug reporting.

The present TB UI appearance is *wrong* (not just in my personal opinion) and, in an ideal world, would be *fixed* at some time in the future.  End of story!

PS sorry to have filed a dupe bug and wasted somebody's time there.  I did try to search, but was incompetent in some way.

Comment 21

[Richard Mlynarik]

Bug 478468: WONTFIX.
Bug 516190: WONTFIX.
Bug 516190: WONTFIX.
Bug 533741: WONTFIX.
Bug 534603: WONTFIX.
Bug 544183: WONTFIX.
Bug 550804: WONTFIX.
Bug 541145: WONTFIX.
Something's UNRESOLVED somewhere, though.

Comment 22

[barry.scott]

Here here Richard.

WONTFIX is unacceptable.

The UI looks like yuor don't care. Fix it to be consistent.

Comment 23

[Kean Johnston]

This "WONTFIX" is very seriously misguided.

This "reason" most especially so:

> 1) Labels in the subject header.  I switched us from the "traditional"
capitalization to a lowercase header because I wanted to decrease the salience
of the labels.  Lowercase text plus a reduced contrast helps to push the the
labels into the background, allowing the user content more visibility.  The
information is placed in a consistent order and tends to define itself, with
the labels only needed for clarification.

The human brain, which is ultimately what is processing the UI, is an extremely advanced pattern recognition device. Whenever anything changes a pattern it forces the brain to re-process, thus drawing attention to whatever has changed. For anyone who has been reading English for more than a year, any sentence or sentence-like structure that does not begin with a capital is going to draw your attention. I recently upgraded from 2.0 to 3.1 and the *VERY FIRST THING* I noticed, before any of the other UI changes, was this.

Even aside from the header lines not being capitalized, the "other actions" menu simply looks amateurish. Any reason given for making it that way pales into insignificance versus the millions and millions of programs out there that correctly capitalize menu names and options. Same with the buttons. With all due respect to whoever made this change, but it is simply wrong, and assigning this as WONTFIX is a terrible idea. Please re-open and assign and fix this. It has completely jaded my opinion of Thunderbird 3.

Comment 24

[Ryan Golightly]

Take it from the industry leaders. They have been at this for years and have huge research and development budgets to devote to just such issues.

Microsoft Windows User Experience Interaction Guidelines:
http://msdn.microsoft.com/en-us/library/aa511258.aspx
"Capitalization
Use title-style capitalization for titles, sentence-style capitalization for all other UI elements."

Introduction to Apple Human Interface Guidelines:
http://developer.apple.com/mac/library/documentation/UserExperience/Conceptual/AppleHIGuidelines/XHIGIntro/XHIGIntro.html
"Capitalization of Interface Element Labels and Text
All interface element labels should be capitalized in either title style or sentence style."

Comment 25

[Rimas Kudelis [use needinfo to ping]]

Bryan, would you perhaps reconsider your position given all the comments and duplicates? It's obvious that unusual capitalisation draws undesired attention instead of helping to avoid it.

Comment 26

[Andrew Sutherland [:asuth] (he/him)]

Reopening a WONTFIXed bug is not appropriate; please direct continued concern to the MDAT newsgroup.

https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

Comment 27

[Aaron Lawrence]

MDAT = mozilla.dev.apps.thunderbird for those less in the know.
http://groups.google.com/group/mozilla.dev.apps.thunderbird/topics?pli=1

Comment 28

[Thomas D. (:thomas8)]

(In reply to comment #26)
> Reopening a WONTFIXed bug is not appropriate; please direct continued concern
> to the MDAT newsgroup.

If you want to express your support for this bug:

-> please VOTE for this bug using (vote) button at the top
-> find an existing or open a new topic at MDAT newsgroup to voice your support:

http://groups.google.com/group/mozilla.dev.apps.thunderbird/topics
news://news.mozilla.com:119/mozilla.dev.apps.thunderbird

-> post the link to any such topic in this bug so that other interested parties can join
-> otherwise, "further important evidence" should be added to this bug.

> https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

O.T. I myself have only recently cited BMO's etiquette in no uncertain terms where it was necessary, but I am feeling very uncomfortable when we start citing the etiquette as a knock-out argument against a clearly benevolent, if mistaken action by an engaged member of the community like Rimas, who has never to my knowledge had any inclinations of being uncooperative. Apart from the fact that you should indeed not change a bug's wontfix resolution unless knowing beyond doubt you are entitled to (2.1), I cannot see Rimas' comment in violation of any clauses of the netiquette, on the contrary: The netiquette explicitly allows to question wontfix decisions when there's "further important evidence" (2.2), which clearly applies here.

Comment 29

[Thomas D. (:thomas8)]

Attachment: Screenshot 1a: Current header pane with lower case labels

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2

Explanation to follow...

Comment 30

[Thomas D. (:thomas8)]

Attachment: Screenshot 1b: Current header pane with lower case labels (bare-bone), showing strong salience of non-native buttons (bug 525210)

Explanation to follow...

Comment 31

[Thomas D. (:thomas8)]

Attachment: Screenshot 2: Header pane with proper capitalization

Cooperation with Bryan has been so good because while he is obviously the ultimate instance for TB design decisions, he is usually open-minded about potential alternatives and willing to listen to well-founded arguments and take them serious. From excellent cooperation with Bryan, I have learned that a screenshot says more than a thousand words. So here's Screenshot 2, as a first impression of what we are talking about:

Imagine... Header pane with proper Capitalization...! (What a relief!)

What you should do to evaluate the visual difference is download Screenshots 1, 2, and 3 (to come) to your hard disc, and then use a full-screen graphics viewer like Irfanview to toggle back and forth while looking at the sections of the UI that change (ideally on at least 1152x864dpi screen resolution @17" non-wide).

Observations:

1) Header-labels (From, Subject, To...):

1a) Clearly, Bryan succeeded in significantly decreasing the salience of header labels by applying reduced contrast (font-color:grey), which is the reason for 1b.

1b) Consequently, the perceived change after re-capitalizing the header-labels (From, Subject, To...) is rather insignificant: They do not stand out any more than before (in Bryan's terms: Undesired salience of header labels is rather unaffected by capitalization).

1c) On the contrary, they definitely do look better, "more correct", thus less salient (as intended by Bryan).

1d) They are more consistent with Composition, where header-labels are capitalized (like any other labels in the whole UI, for that matter).

1e) They are more consistent with what we print on paper (where noone would ever think of printing them lower-case!).

2) Button labels (and labels inside "Other Actions" menu):

Per comment 4, Bryan had a two-fold design goal for the buttons:
> [goal 1:] to make them stand out
> [goal 2:] but not overrun the visible content area around them

Rephrasing these goals using Bryan's terminology:

goal 1: to make header button labels more salient than the rest of the UI
goal 2: not to make header button labels too much more salient than the rest of the UI

Theoretically, that's *not* a contradiction, but a question of degree.
Practically, it's a very thin line to walk on, both the intention and the success of which should be re-evaluated.

Looking at Screenshot 1a (attachment ######):

goal 1: Clearly, Bryan succeeded in "making the buttons stand out", i. e. increasing the salience of header labels by applying a special button layout (visible blue borders, 3D look).

goal 2: Clearly, the current UI fails on goal 2. The header buttons are MUCH more salient than the rest of the UI, because they feature a non-native button layout that's grossly different from any other visible buttons in Thunderbird's main UI (judging from my Win XP system; ymmv). Look at Screenshot 1b (attachment ######) where I removed distracting parts of the UI so that the difference comes out more clearly: The salience of header buttons, compared to other buttons like those on main toolbar and filter bar, is *strong* (they stand out a lot; sorry, I can't help but call this an eyesore. Hence bug 525210, which btw has ui-review+ from Bryan on attachment 409064 [details]). 

2a) To sum up: The current salience of header button labels is very high, due to their special layout which is significantly different from any other buttons in the main UI (permanent visible blue borders and 3D look). 

2b) Compared against the high salience of the current *design* of the header buttons (2a), the perceived visual change after re-capitalizing the button-labels (Reply, Reply all, Forward...) is not very significant: They still stand out a lot, but they do not stand out much more than before (in Bryan's terms: salience of header labels is rather unaffected by capitalization).

2c) Arguably, buttons with capitalized labels look better, "more correct", thus less salient (which might be a small, yet insufficient step towards goal 2, because of 2d).

2d) Capitalized button labels are more consistent with any other button labels in the whole of TB's UI

2e) Capitalized button labels are more consistent with any other button labels in virtually any other application

(N.B.: I cheated a bit in the "Other Actions" menu, where I tried the compromise of initial caps instead of title-style wordwise capitalization which is the default for menus; no strong feelings about that).

Comment 32

[Thomas D. (:thomas8)]

Attachment: Screenshot 3: Header pane with proper capitalization AND native layout (bug 525210)

Enters Screenshot 3:

Imagine... Header pane with proper capitalization AND native layout!
(What a redemption! *sigh_of_relief_that_everything_is_back_to_normal*)

Comment 33

[Thomas D. (:thomas8)]

Towards finding a compromise solution for this bug

IMO, we should approach this bug together with bug 525210: buttons in message header should look native. Extra benefit of the combined solution:
- buttons without permanent button border can be positioned further-up on the header-pane without looking bad
- without changing button height (on hover), we can thus have a permanent vertical space gain of 4px, which is a lot given adamant reactions about our new space-eating header, filter bar etc.

- Note that Screenshot 3 (attachment 464422 [details]) does not yet feature the full vertical space gain that's possible with fixing bug 525210.
- Note that that we even save *horizontal* space, although we might want to add a bit more distance between the buttons now that they don't have a permanent border any more.
- Buttons have the usual "buttonize-on-hover" behaviour known from the main toolbar.

Looking at the evidence presented in comment 31 and this comment 33, as visualized in Screenshots 1-3 (attachment 464413 [details], attachment 464415 [details], attachment 464419 [details], and attachment 464422 [details]):

IMO there is a strong case for returning default capitalization to the respective UI elements (as proposed by this bug). Wontfix resolution should be reconsidered in view of this "further important evidence" (in addition to numerous previous comments and duplicates, including bug 525210, comment 7)

Proposed solution for this bug (retaining most, if not all of Bryan's original design goals):

-> Capitalize header labels, button labels, and menus inside "Other Actions" (this bug), AND
-> Fix bug 525210: Native look for message header buttons

As numerous evidence from this bug suggests, this will have virtually no negative impacts on Bryan's design goals regarding salience:

- We have reason to assume that any deviation from deFault capitalization patterns has the risk of over-salience (hence this bug)
- Capitalization in header labels is insignificant (neutralized by non-salience of grey font-color)
- Capitalization in button labels will at least be salience-neutral if combined with bug 525210
- Capitalization in "Other Actions" Menus follows from afore-mentioned changes

Comment 34

[Thomas D. (:thomas8)]

(In reply to comment 31, and comment 33)
Linkification of screenshot attachments was incomplete in comment 31, and misleading in comment 33, should be:

Screenshot 1a: Current header, lower case (attachment 464413 [details])
Screenshot 1b: Current header, lower case bare-bone (attachment 464415 [details])
Screenshot 2: Better header, capitalized (attachment 464419 [details])
Screenshot 3: Best header, capitalized & native look (attachment 464422 [details])

Comment 35

[Thomas D. (:thomas8)]

You can temporarily try the changes of Screenshot 3 "live" on your own TB by tweaking the Layout with DOM Inspector Addon (after Restart of TB, or customizing toolbar, changes will be lost): 

- download and install DOM Inspector Addon to Thunderbird (https://addons.mozilla.org/en-US/firefox/addon/6622/ -> TB > Tools > Addons > Install...).
From DOM Inspector:
- File > Inspect Chrome Document > CurrentFolder - YourAccount - TB
- Then click "Find a node to inspect by clicking on it", and click on the desired UI element in TB (e.g. hdrReplyToSenderButton button, do not try the junk or delete button first time, and do smart-reply-all last).
- In DOM-I window, the desired element all the way down the tree is now selected. On the right, there's properties pane showing Object - DOM Node.
- Double-click on nodeName "class" and change the value from "toolbarbutton-1 msgHeaderView-button hdrReplyToSenderButton" to "toolbarbutton hdrReplyToSenderButton".
- Double-click on nodeName "label" to change the label to your liking.
- Repeat for other buttons and header-labels with find&inspect by click as above.

Do NOT ask support questions about this procedure here in this bug.

Comment 36

[Thomas D. (:thomas8)]

http://getsatisfaction.com/mozilla_messaging/topics/lowercase_text_for_message_labels_buttons (currently, 12 users have this problem, and the comments are worth reading)
http://getsatisfaction.com/mozilla_messaging/topics/thunderbird_3_the_good_the_bad_the_ugly
http://getsatisfaction.com/mozilla_messaging/topics/version_3_message_pane_layout

Comment 37

[Andrew Sutherland [:asuth] (he/him)]

(In reply to comment #28)
> O.T. I myself have only recently cited BMO's etiquette in no uncertain terms
> where it was necessary, but I am feeling very uncomfortable when we start
> citing the etiquette as a knock-out argument against a clearly benevolent, if
> mistaken action by an engaged member of the community like Rimas, who has never
> to my knowledge had any inclinations of being uncooperative. Apart from the
> fact that you should indeed not change a bug's wontfix resolution unless
> knowing beyond doubt you are entitled to (2.1), I cannot see Rimas' comment in
> violation of any clauses of the netiquette, on the contrary: The netiquette
> explicitly allows to question wontfix decisions when there's "further important
> evidence" (2.2), which clearly applies here.

Rimas is indeed a valued contributor; I mean him no ill will and I agree that we do not want to needlessly shut down conversation...

But this is not a debate club.  Sometimes decisions will be made that people do not agree with, especially when it comes to UI/UX decisions.  In order to move the product forward we cannot then spend hours debating the decision further.

(For the purposes of "further important evidence", citing UX studies at a UX professional is not really "further important evidence".  A bug that is WONTFIXED because it is believed there is no dataloss and then it turns out there is dataloss is further important evidence.)

The recourse, especially in cases like this, is to create an extension that rectifies the perceived problem.  If it turns out that a million people care enough about the capitalization to install the extension, that speaks volumes without requiring extensive and subjective debate that slows down the product.

Comment 38

[mark]

The Mail Tweak extension, which is not an official Mozilla add-on (it doesn't show up when searching under 'Get Add-ons') includes this functionality, among other things.  

It will be difficult to tease out exactly how many of the users of this add-on are using the capitalization option.

Comment 39

[Rimas Kudelis [use needinfo to ping]]

Thanks to Thomas for defending me. I must agree, I do abuse my rights on bugzilla sometimes, and to be honest, I don't think this will change.

However, one of the reasons why I reopened this bug was that after reading Bryan's comment, it seemed to me like he himself doesn't have a strong position WRT this question. Maybe I was wrong.

(In reply to comment #37)
> The recourse, especially in cases like this, is to create an extension that
> rectifies the perceived problem.  If it turns out that a million people care
> enough about the capitalization to install the extension, that speaks volumes
> without requiring extensive and subjective debate that slows down the product.

What if they don't care enough to install an extension, but they do care in general? From my PoV, this problem is too small to install an extension to fix. But that doesn't mean it's not a problem at all.

Comment 40

[Joachim Kock]

> The recourse, especially in cases like this, is to create an extension that
> rectifies the perceived problem.  If it turns out that a million people care
> enough about the capitalization to install the extension, that speaks volumes
> without requiring extensive and subjective debate that slows down the product.

It seems to be much easier to sneak in new 'features' than to revert
them if they turn out to be bad ideas.  Following the idea of the
quote above, why didn't the inventer of this lowercase feature first
write an extension, and then depending on the number of downloads, the
feature could be nominated for merging into the trunk?  Could you even
imagine anyone downloading such an extension, or imagine dozens of
people writing feature requests on Bugzilla, demanding that
Thunderbird adopt lowercase button labels?

What most likely happened is that one developer tried to design some
new buttons, showed them to a few other developers, who without
thinking too much about it said they liked them, and that's all.  I
wonder if such a conversaion is recorded anywhere on a forum or in a
mailing list archive...  Maybe the discussion took place on a chat,
where nobody cares about punctuation, spelling, capitalisation or
anything, and nobody even noticed that the capitalisation was wrong!

Now the issue has been analysed more deeply, and one could have hoped
that the developers, with the further insight provided, could
reconsider the case.  But it is a wasted effort, because the bug has
been declared WONTFIX.

Joachim.

Comment 41

[Rimas Kudelis [use needinfo to ping]]

Thomas, care to write a newsgroup post? I was going to, but then figured out that I couldn't do better than just paste your comments... Plus, I feel quite overwhelmed ATM, so if you could do that, please do... :)

Comment 42

[VTA]

Hello,

I stumbled across this EPIC BATTLE over a few upper case letters (because it bugs the hell out of me every time I read any mail) and I've got to say this is both amazing and depressing.

Depressing because I rely on Thunderbird and have used it for more than 5 years now, but I can't see how the long term support or evolution of the product is assured given what I read here.  Upgrades never seem to fix anything I or anybody on my team use to read our mail, and the user interface just keeps taking more and more bizarre turns.  (eg Does anybody LIKE the latest mailbox search bar thing?)

I wonder if any of you developers can manage to take a step back and listen to the sorts of things you are saying?

1.  I unilaterally decided this is great, even though it jars with the established UI on every platform on which the software runs, and even though it jars with the UI of the software system itself.  Into the release it goes!

2. Go to hell, customers.  I don't care what you think.  I don't care how many of you think it.  I don't care that nobody, nobody!, out there in the real world of real users understands my genius.

3. WONTFIX. So there.

4.  You disagree?  You're IN BREACH OF ETIQUETTE.  Etiquette!  That's rich coming from people who introduce defects into software and then tell their users to pound sand.

5.  Do something involving a "MDAT newsgroup"?  WTF?  WTF!!

6.  Well a "MDAT newsgroup seems awfully like a private boys club run by the same boys who caused a problem in the first place.  But feel free to MDAT away, customers!  See if we care.  You've already taken the trouble to identify a problem, register with our system, search for the problem in our home-grown database, try to understand "components" and other jive in the giant web form, report the problem ... but that's not good enough!  You need to register with an MDAT newsgroup if you want to get anywhere with us!

7. We asked our best buddies if they thought we were awesome, and they said, "Sure!  You're awesome.  And a big innovator in CapITalIzATION reDesiGN.  One day the world will recognize your genius."

8. You end users can take it upon yourselves to spend a month working out how the heck to write an "extension" for our incredible byzantine software kludgefest.  And then you must take it upon yourselves to distribute and promote this extension to the world, to people who, on the whole, don't want "extensions", don't want to be system maintainers, don't want to deal with iffy third-party add-ons, and JUST WANT STUFF TO WORK OUT OF THE BOX.

9. Maybe we'll count the number of people who download your extension, developed at your own cost.  Or maybe we don't.  We have no criteria other than A BELIEF IN OUR OWN PERFECTION.  Besides, if nobody downloads it it proves we are perfect, and if lots of people download it it proves that a downloadable extension if the perfect solution.

10. Suck it.  WONTFIX.  Etiquette!


I work as a software engineering manager and I wouldn't put up with any of this nonsense for a nanosecond; you'd be looking for another line of work as soon as you could clear your desk.  And I'll never hire any of you in the future ... which is your loss, because I work for a great company, where we believe in open source, treat PROFESSIONAL developers very well, hire people around the world based on skills not on proximity to the home office, and try to make great software that our customers will love.


You people really need to step back, take a breath, lay off the offensive "etiquette" trip, and consider just how you are acting and how you look to people who aren't your personal Thunderbird insider buddies.

And that's all I have to say.  All over a couple dozen ASCII characters missing the shift key.

Comment 43

[Jeremy Jongsma]

Bryan,

http://s3.amazonaws.com/satisfaction-production/s3_images/265718/Header_pane_with_proper_capitalization_and_native_layout__flat_hover-effect_.png

There is a great solution, if you want the buttons to blend in more.  Flat buttons with a hover effect.  And it has the side benefit of correct capitalization and looking elegant.

Comment 44

[Simon Taylor]

This is ridiculous. The justification for the change seems very weak, and clearly there are people who are very annoyed by this. Even if there was some evidence it did have some significant effect on "salience" it is simply incredibly inconsistent with the rest of the UI. How on earth can that be a WONTFIX?!

Counting the number of people who complain or try to install and add-on to fix it is clearly flawed as it is far too much hassle for most people (I've spent a while searching for an addon without success and just registered a bugzilla account to post my disappointment).

For me, I'll be heading back to Thunderbird 2.

Comment 45

[Dan Mosedale (:dmosedale, :dmose)]

VTA, there are clearly a bunch of things going on here.  You disagree with the UX change that was made.  That's valid.  You're angry.  That too is valid; UX changes can be uncomfortable.  You have experience as a software manager and would make several decisions involved here differently, if it were your decision.  That's reasonable as well.

You also appear to believe that whether or not developers behave civilly towards each other is not important.  You're certainly entitled to that opinion.  However, this project depends heavily on people who volunteer their contributions, and one of the reasons that we don't have as many contributors as we'd like is because developers who don't have extremely thick skin contribute less and even leave the project.

More to the point, you felt that it was reasonable to post an angry, attacking rant here after already having become aware of the Bugzilla etiquette guidelines, which specifically points out that those things are not ok.

If I'm forced to choose between making Bugzilla more hospitable to contributors and keeping your account open, I will choose making Bugzilla more hospitable.  Specifically, if I become aware of you violating the guideliness again, I will disable your Bugzilla account.

If you or anyone else feels the need to reply, you're welcome to do so in direct email to me.

Comment 46

[bacole9]

I use the following script and patch file to restore the capitalization of message headers to match thunderbird 2 (and to match the established convention of al other mail user agents I've encountered in my 26+ years of use).  While rfc822 doesn't actually require such capitalization, it's not reasonable to ignore the long established convention if user experience is valued.

This is pretty simple to clean up, I'm rather astonished this problem persists in the mainline.

This script is US-centric, pathnames vary, etc, but you get the idea:

cd /usr/lib64/thunderbird-3.1/chrome
mkdir x
cd x
unzip ../en-US.jar
# patch locale/en-US/messenger/msgHdrViewOverlay.dtd
patch -p0 < ~/thunderbird.fix/patch
zip -r en-US.jar .
cd ..
mv en-US.jar en-US.jar.orig
mv x/en-US.jar .
rm -rf x


Patchfile:
*** locale/en-US/messenger/msgHdrViewOverlay.dtd.orig	2010-09-15 18:56:12.000000000 -0700
--- locale/en-US/messenger/msgHdrViewOverlay.dtd	2010-06-05 10:14:02.000000000 -0700
***************
*** 35,59 ****
  
   ***** END LICENSE BLOCK ***** -->
  
! <!ENTITY toField2.label "to ">
! <!ENTITY fromField2.label "from ">
! <!ENTITY senderField2.label "sender ">
! <!ENTITY organizationField2.label "organization ">
! <!ENTITY replyToField2.label "reply-to ">
  
! <!ENTITY subjectField2.label "subject ">
  <!--# LOCALIZATION NOTE (ccField2.label): DONT_TRANSLATE -->
! <!ENTITY ccField2.label "cc ">
! <!ENTITY bccField2.label "bcc ">
! <!ENTITY newsgroupsField2.label "newsgroups ">
! <!ENTITY followupToField2.label "followup-to ">
! <!ENTITY tagsHdr2.label "tags ">
! <!ENTITY dateField2.label "date ">
! <!ENTITY userAgentField2.label "user-agent ">
! <!ENTITY referencesField2.label "references ">
! <!ENTITY messageIdField2.label "message-id ">
! <!ENTITY inReplyToField2.label "in-reply-to ">
! <!ENTITY originalWebsite2.label "website ">
  
  <!ENTITY editMessageDescription.label "This is a draft message">
  <!ENTITY editMessageButton.label "Edit…">
--- 35,59 ----
  
   ***** END LICENSE BLOCK ***** -->
  
! <!ENTITY toField2.label "To ">
! <!ENTITY fromField2.label "From ">
! <!ENTITY senderField2.label "Sender ">
! <!ENTITY organizationField2.label "Organization ">
! <!ENTITY replyToField2.label "Reply-To ">
  
! <!ENTITY subjectField2.label "Subject ">
  <!--# LOCALIZATION NOTE (ccField2.label): DONT_TRANSLATE -->
! <!ENTITY ccField2.label "Cc ">
! <!ENTITY bccField2.label "Bcc ">
! <!ENTITY newsgroupsField2.label "Newsgroups ">
! <!ENTITY followupToField2.label "Followup-To ">
! <!ENTITY tagsHdr2.label "Tags ">
! <!ENTITY dateField2.label "Date ">
! <!ENTITY userAgentField2.label "User-Agent ">
! <!ENTITY referencesField2.label "References ">
! <!ENTITY messageIdField2.label "Message-ID ">
! <!ENTITY inReplyToField2.label "In-Reply-To ">
! <!ENTITY originalWebsite2.label "Website ">
  
  <!ENTITY editMessageDescription.label "This is a draft message">
  <!ENTITY editMessageButton.label "Edit…">

Comment 48

[Brendan Eich [:brendan]]

Ok, now that we are (I hope) past etiquette issues, why is this bug still WONTFIX? Bryan?

/be

Comment 49

[Blake Winton (:bwinton) (:☕️)]

(In reply to comment #48)
> Ok, now that we are (I hope) past etiquette issues, why is this bug still
> WONTFIX? Bryan?

Bryan has moved on to a different role in Mozilla, and probably isn't thinking about this bug anymore.  Since I'm the new UX Lead, it's more my call…

I'm sort of torn between opening a new bug (to better ignore the unpleasant history in this one), and re-opening this one (to respect Joachim's and the other contributors work so far).  On balance I think re-opening this bug is the better idea, since that puts the burden on me instead of on the volunteers.

Now for the useful part of this comment.  ;)

I think something like <https://bugzilla.mozilla.org/attachment.cgi?id=464422> seems like a reasonable way to go, but since we switched the icons to monochrome (and because some people could choose text-only buttons), I'm not sure that the buttons would look button-y enough when they're totally flat.  So I would prefer we keep the outline of a button around them, at least.  On the Mac, it looks like <http://dl.dropbox.com/u/2301433/Screenshots/MonoButtons.png>

I also think it would be reasonable to leave the button style changes to bug 525210, and use this bug to just change the case of the labels and buttons.

Thanks,
Blake.

Comment 50

[Blake Winton (:bwinton) (:☕️)]

Oh, it might also be worth mentioning that the next version of Apple's Mail.app has removed the From/Subject/Date labels entirely <http://dl.dropbox.com/u/2301433/Screenshots/LionMail.png>.  That might be a reasonable direction for us to go as well…

Comment 51

[Tom Holub]

Yay.

I think removing the labels entirely could work; it would be important to make them distinct enough via formatting that it's obvious which is the From and which is the Subject.  (In the Mail.app screen shot it's done by bolding the From).  I also would be interested to know how Cc: is handled in Mail.app; whether someone is in the From or Cc: list is an important piece of information that can't be lost.

Comment 52

[Rimas Kudelis [use needinfo to ping]]

(In reply to comment #49)
> I also think it would be reasonable to leave the button style changes to bug
> 525210, and use this bug to just change the case of the labels and buttons.

Agreed!

(In reply to comment #50)
> Oh, it might also be worth mentioning that the next version of Apple's
> Mail.app has removed the From/Subject/Date labels entirely
> <http://dl.dropbox.com/u/2301433/Screenshots/LionMail.png>.  That might be a
> reasonable direction for us to go as well…

It might be worth looking at, but I hope we're not going to blindly copy every design decision of the Apple team. :) In either case, is that topic related to this bug?

Comment 53

[Blake Winton (:bwinton) (:☕️)]

(In reply to comment #52)
> (In reply to comment #50)
> > Oh, it might also be worth mentioning that the next version of Apple's
> > Mail.app has removed the From/Subject/Date labels entirely
> > <http://dl.dropbox.com/u/2301433/Screenshots/LionMail.png>.  That might be a
> > reasonable direction for us to go as well…
> 
> It might be worth looking at, but I hope we're not going to blindly copy
> every design decision of the Apple team. :)

Nope.  Just the good ones.  ;)  (This may or may not be one of the good ones, which is why I think it's worth looking at.)

> In either case, is that topic related to this bug?

Only tangentially, because if we remove the text entirely, than the case doesn't matter so much.  :)

Later,
Blake.

Comment 54

[Rimas Kudelis [use needinfo to ping]]

(In reply to comment #53)
> (In reply to comment #52)
> > In either case, is that topic related to this bug?
> 
> Only tangentially, because if we remove the text entirely, than the case
> doesn't matter so much.  :)

Ah right, I forgot about the header labels, and only had the buttons on my mind. I think however, that greying them out is fine, there's no need to hide them. But well, 'looking at this' could still be done on another bug...

By the way, as a leader of the lt locale, I some time ago decided to do something I didn't quite enjoy doing, and simply "fixed" this bug for my locale. In Bryan's place, I would've really hated someone ignoring my decision like that, but being in my place, I hated those lowercase buttons even more... I just noticed that forgot to fix header labels though... Which I guess says enough about their salience. :)

Comment 55

[Blake Winton (:bwinton) (:☕️)]

(In reply to comment #54)
> Ah right, I forgot about the header labels, and only had the buttons on my
> mind. I think however, that greying them out is fine, there's no need to
> hide them. But well, 'looking at this' could still be done on another bug...

Yep.  Oh, to whomever is working on the patch, don't forget the "other actions" button!  I often miss it, hiding down in the corner there…

> By the way, as a leader of the lt locale, I some time ago decided to do
> something I didn't quite enjoy doing, and simply "fixed" this bug for my
> locale. In Bryan's place, I would've really hated someone ignoring my
> decision like that, but being in my place, I hated those lowercase buttons
> even more... I just noticed that forgot to fix header labels though... Which
> I guess says enough about their salience. :)

:)

Thunderbird is worked on by a community of people.  While there is a corporation paying some people, I don't think it should be run in a corporate style, with unquestionable decisions coming down from the top.  If Bryan failed to convince you (and apparently Brendan Eich! :) that the lower-case labels were the correct thing to do, then perhaps that decision should be revisited.

Andrew Sutherland said "Sometimes decisions will be made that people do not agree with, especially when it comes to UI/UX decisions.  In order to move the product forward we cannot then spend hours debating the decision further.", and while I think he's a spectacularly bright person, I'm not sure I agree with him in this case.  I suspect that a better way to move the product forward is to convince people of the direction you want to take it, and get everyone on board.  Sure, you would still have the hours of debates, but at least you would have them at the start, and after they were over everyone would be on the same page.

Along those lines, I'm posting UI ideas at <http://breakingtheegg.tumblr.com/> for discussion.  To be up-front, the comment policy there is "Only helpful, constructive, non-complaining comments will be allowed in this space.  Comments which don't meet the standards of this blog will be deleted, probably without notice."  I actively welcome comments there which disagree with my opinion (as long as they have good reasoning behind them), but I will have no hesitation deleting comments which are insulting or unhelpful.  (As it turns out, just the other day I deleted a comment which supported my point of view, because it was insulting, and wasn't particularly helpful.)

Thanks,
Blake.

Comment 56

[Thomas D. (:thomas8)]

(In reply to comment #55)
> Thunderbird is worked on by a community of people.  While there is a
> corporation paying some people, I don't think it should be run in a
> corporate style, with unquestionable decisions coming down from the top.  If
> Bryan failed to convince you (and apparently Brendan Eich! :) that the
> lower-case labels were the correct thing to do, then perhaps that decision
> should be revisited.
> 
> Andrew Sutherland said "Sometimes decisions will be made that people do not
> agree with, especially when it comes to UI/UX decisions.  In order to move
> the product forward we cannot then spend hours debating the decision
> further.", and while I think he's a spectacularly bright person, I'm not
> sure I agree with him in this case.  I suspect that a better way to move the
> product forward is to convince people of the direction you want to take it,
> and get everyone on board.  Sure, you would still have the hours of debates,
> but at least you would have them at the start, and after they were over
> everyone would be on the same page.

OT: <emotional> That comment of Blake is sensational, and if put into practice, could start a new culture of cooperation, responsibility and rationality in TB UI development that could go a long way in reviving and revitalising the bird and make it fly high for a majority of users rather than stumbling on the ground with clipped wings due to the ideosyncracies of some few developers that are sometimes a little too quick in their tendency of shooting down justified criticism with the netiquette gun. Thank you!!! </emotional>

Comment 57

[rsx11m]

(In reply to comment #50)
> Oh, it might also be worth mentioning that the next version of Apple's
> Mail.app has removed the From/Subject/Date labels entirely. That might be a
> reasonable direction for us to go as well…

This would be a problem if someone uses the mailnews.headers.* preferences to show custom headers by default, or in View > Headers > All mode, so such a step would require a bit more thorough thoughts.

Comment 58

[Brendan Eich [:brendan]]

Who will take assignment of this bug?

/be

Comment 59

[Thomas D. (:thomas8)]

brendan, as long as the bug is assigned to nobody, the status should not be "assigned", to avoid confusion.

Comment 60

[Brendan Eich [:brendan]]

(In reply to comment #59)
> brendan, as long as the bug is assigned to nobody, the status should not be
> "assigned", to avoid confusion.

Sorry, accidental reopen, but I'll let it ride based on Blake's recent comments. Thanks for NEW'ing.

/be

Comment 61

[Thomas D. (:thomas8)]

Blake, in line with your suggestion to use this bug for changing the header labels and button labels only (better late than never; congratulations on that UI decision!!!), and in the interest of swift progress, I suggest that any further changes to the header pane, like removing (some of) the header labels altogether, should be considered and dealt with in separate bugs.

So we need a patch along the lines of code in comment 1 and comment 46.
Blake, do we need new entity names for the whole long list of headers & labels just because of changing capitalization, or can we find a more intelligent way of notifying translators about this minor change?

Comment 62

[Blake Winton (:bwinton) (:☕️)]

Yeah, removing header labels and other header pane changes are definitely separate bugs.  :)

My understanding is that we need new entity names, but perhaps someone in #l10n would know of a better way to communicate to the translators.

Thanks,
Blake.

Comment 63

[rsx11m]

As a rule of thumb, if the entities were changed when the labels were forced to be lower-case I'd also create new entity names when reverting that change.

Comment 64

[Blake Winton (:bwinton) (:☕️)]

It looks like they were, as per http://hg.mozilla.org/comm-central/rev/bc29303430f4#l8.12

What are the localization rules/best practices for changing them back to the previous entity names?  (But leaving the values without the ":"s.)

Comment 65

[rsx11m]

Since they have sequence numbers already anyway, just make them *Field3.* to indicate the change (maybe going back to the old label isn't such a good idea, especially if the ":" isn't added back again).

Comment 66

[Thomas D. (:thomas8)]

Likewise, do we want spaces in the labels? (suppose not). Does not having the spaces or colons affect other localizations, like RTL languages?

Comment 67

[Alex]

Still present in 5.0.

Comment 68

[Mark Banner (:standard8)]

(In reply to comment #67)
> Still present in 5.0.

Thank you, we know - that is why this bug is marked as new and not as fixed. Generally you don't need to tell us that a bug is still present unless there is an explicit request to verify whether or not it is still present.

Comment 69

[Rimas Kudelis [use needinfo to ping]]

Attachment: Convert labels to Title Case and tooltips to Sentence case

I guess it won't be fixed until somebody comes up with a patch, right? :) Here's one.

Comment 70

[Rimas Kudelis [use needinfo to ping]]

Attachment: Patch, v.2

Per IRC chat with Blake and Jim, here's a revised version of the patch, and request for review from Jim instead of Blake.
If this is all fine, please commit on my behalf. I'm not sure I have commit access to comm-central. :)

Comment 71

[Jim Porter (:squib)]

Comment on attachment 558963 [details] [diff] [review]
Patch, v.2

Review of attachment 558963 [details] [diff] [review]:
-----------------------------------------------------------------

There were a couple of entity names that didn't get updated in msgHdrViewOverlay.xul, but I've fixed them locally, so you don't need to worry about that. Before I check this in though, is there a reason you removed the "don't translate" comment for the Cc label? Was that comment just inaccurate?

::: mail/base/content/msgHdrViewOverlay.xul
@@ +189,4 @@
>  
>                <toolbarbutton id="hdrForwardButton"
>                               label="&hdrForwardButton.label;"
>                               tooltiptext="&hdrForwardButton.tooltip;"

These entities should be updated.

@@ +427,5 @@
>                                               flex="1"/>
>                </row>
>                <row id="expandedtagsRow" collapsed="true">
>                  <label id="expandedtagsLabel" class="headerName"
>                         value="&tagsHdr2.label;" control="expandedtagsBox"/>

Here too.

@@ +434,3 @@
>                <row id="expandedcontent-baseRow" collapsed="true">
>                  <label id="expandedcontent-baseLabel" class="headerName"
>                         value="&originalWebsite2.label;"

And here.

::: mail/locales/en-US/chrome/messenger/msgHdrViewOverlay.dtd
@@ -43,3 @@
>  
> -<!ENTITY subjectField2.label "subject ">
> -<!--# LOCALIZATION NOTE (ccField2.label): DONT_TRANSLATE -->

Any reason for removing this comment?

Comment 72

[Rimas Kudelis [use needinfo to ping]]

(In reply to Jim Porter (:squib) from comment #71)
> Comment on attachment 558963 [details] [diff] [review]
> Patch, v.2
> 
> Review of attachment 558963 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> There were a couple of entity names that didn't get updated in
> msgHdrViewOverlay.xul, but I've fixed them locally, so you don't need to
> worry about that.

Oops, my bad. Thanks for catching!

> Before I check this in though, is there a reason you
> removed the "don't translate" comment for the Cc label? Was that comment
> just inaccurate?

I consider it as inaccurate and useless. And by looking at http://mxr.mozilla.org/l10n-central/search?string=ccField2.label, it seems I'm not the only one. Thus I decided to simply drop it.

Comment 73

[Jim Porter (:squib)]

Checked in: http://hg.mozilla.org/comm-central/rev/3495c70f54d1

I'm sure the UI will look vaguely off to me for the next week or so... :)

Comment 74

[Thomas D. (:thomas8)]

Halleluja! Sanity prevails... Thank you, Rimas, for having mercy on this one!

Just curiosity: Looking at this...

> +<!ENTITY toField3.label "To ">
> +<!ENTITY fromField3.label "From ">
> +<!ENTITY senderField3.label "Sender ">
> +<!ENTITY organizationField3.label "Organization ">
> +<!ENTITY replyToField3.label "Reply to ">

...I still have this question:

(In reply to Thomas D. from comment #66)
> Likewise, do we want spaces in the labels? (suppose not). Does not having
> the spaces or colons affect other localizations, like RTL languages?

Iow, what's the point of having trailing spaces inside a label, which more often than not will have to be trimmed by the code and replaced by colons?

(In reply to Rimas Kudelis from comment #72)
> (In reply to Jim Porter (:squib) from comment #71)
> > Comment on attachment 558963 [details] [diff] [review]
> > Patch, v.2
> > Before I check this in though, is there a reason you
> > removed the "don't translate" comment for the Cc label? Was that comment
> > just inaccurate?
> 
> I consider it as inaccurate and useless. And by looking at
> http://mxr.mozilla.org/l10n-central/search?string=ccField2.label, it seems
> I'm not the only one. Thus I decided to simply drop it.

Hmmm. "bcc" is a lot shorter than "blind copy" in whichever language, I suppose those translations take up much more UI space than intended, e.g. in message reader's header pane?

Comment 75

[Rimas Kudelis [use needinfo to ping]]

(In reply to Thomas D. from comment #74)
> Just curiosity: Looking at this...
> 
> > +<!ENTITY toField3.label "To ">
> > +<!ENTITY fromField3.label "From ">
> > +<!ENTITY senderField3.label "Sender ">
> > +<!ENTITY organizationField3.label "Organization ">
> > +<!ENTITY replyToField3.label "Reply to ">
> 
> ...I still have this question:
> 
> (In reply to Thomas D. from comment #66)
> > Likewise, do we want spaces in the labels? (suppose not). Does not having
> > the spaces or colons affect other localizations, like RTL languages?
> 
> Iow, what's the point of having trailing spaces inside a label, which more
> often than not will have to be trimmed by the code and replaced by colons?

Honestly, I don't know. I'm not sure whether or not those spaces are needed at all. I left them as is because my patch is basically just a trivial search-replace operation. I didn't touch anything else. I guess removal of those spaces could be a subject for yet another followup bug.

> Hmmm. "bcc" is a lot shorter than "blind copy" in whichever language, I
> suppose those translations take up much more UI space than intended, e.g. in
> message reader's header pane?

Yes, they do take up more space. But localized labels are meaningful, unlike abbreviations 'Cc' or 'Bcc', which do not make sense initially. In any case, whether or not (and how) to translate them, is up to the localizers.

Comment 76

[Thomas D. (:thomas8)]

Undoing accidental component change of comment 61.

Comment 77

[Thomas D. (:thomas8)]

(In reply to Rimas Kudelis from comment #75)
> I guess removal of those spaces could be a subject for yet another
> followup bug.

Filed followup Bug 686427 - Remove trailing spaces from mail header string entities

> > Hmmm. "bcc" is a lot shorter than "blind copy" in whichever language, I
> > suppose those translations take up much more UI space than intended, e.g. in
> > message reader's header pane?
> Yes, they do take up more space. But localized labels are meaningful, unlike
> abbreviations 'Cc' or 'Bcc', which do not make sense initially. In any case,
> whether or not (and how) to translate them, is up to the localizers.

+1

Comment 78

[alta88]

what possible reason could there be for changing the entity names?  anyone using these names, to legitimately reuse translations and for consistency of like named elements elsewhere, is going to have to branch.

there is no way (afaik) to make this backward compatible in the same version of an extension.  worse, though OT, is undefined entities are still a hard fail.

Comment 79

[Jim Porter (:squib)]

(In reply to alta88 from comment #78)
> there is no way (afaik) to make this backward compatible in the same version
> of an extension.  worse, though OT, is undefined entities are still a hard
> fail.

Just fork the files that use the entity names and use appversion in your chrome.manifest to choose the right file for your overlays.

Comment 80

[Rimas Kudelis [use needinfo to ping]]

(In reply to alta88 from comment #78)
> what possible reason could there be for changing the entity names?

I think changing the entities was the consensus we reached through discussion. The reason for changing them is rather simple, and the same as always – without changing entity names, localisers would have likely not noticed this change.

> anyone using these names, to legitimately reuse translations and for
> consistency of like named elements elsewhere, is going to have to branch.

I'm not very sure that anyone is actually supposed to simply reuse those translations. You never really know how the word may have to differ in different contexts in a localized version, you can't just assume that what's OK for English, is OK for all other locales too.

Comment 81

[alta88]

(In reply to Rimas Kudelis from comment #80)
> (In reply to alta88 from comment #78)
> > what possible reason could there be for changing the entity names?
> 
> I think changing the entities was the consensus we reached through
> discussion. The reason for changing them is rather simple, and the same as
> always – without changing entity names, localisers would have likely not
> noticed this change.
> 

admittedly i am not familiar with the core tool, but Babelzilla will flag as new a value change, so it doesn't seem correct at all to require an entity change to get a value change noticed.  are you saying changing any string value means you have to change the name too.. i don't think so.

> > anyone using these names, to legitimately reuse translations and for
> > consistency of like named elements elsewhere, is going to have to branch.
> 
> I'm not very sure that anyone is actually supposed to simply reuse those
> translations. You never really know how the word may have to differ in
> different contexts in a localized version, you can't just assume that what's
> OK for English, is OK for all other locales too.

the context, in this case, is exactly the same, labels/buttons are merely located in a different dom widget.  i think most people who are careful with entities understand linguistic nuances.


(In reply to Jim Porter (:squib) from comment #79)
> (In reply to alta88 from comment #78)
> > there is no way (afaik) to make this backward compatible in the same version
> > of an extension.  worse, though OT, is undefined entities are still a hard
> > fail.
> 
> Just fork the files that use the entity names and use appversion in your
> chrome.manifest to choose the right file for your overlays.

yes.  but still.  for a project so heavily reliant on addons, i would think any entity, function, variable etc change would need a heavy preponderance of justification first.  yet i see trivial and unnecessary changes all the time and each adds unproductive churn for the addon dev.

Comment 82

[Mark Banner (:standard8)]

This is getting very off-topic for this bug. I'll address one or two things here, but please do any further follow-ups in the dev lists.

(In reply to alta88 from comment #81)
> admittedly i am not familiar with the core tool, but Babelzilla will flag as
> new a value change, so it doesn't seem correct at all to require an entity
> change to get a value change noticed.  are you saying changing any string
> value means you have to change the name too.. i don't think so.

It depends on the specific change. In this case, localisations may have followed the essence of what we did originally, so I think changing the name is reasonable.

> yes.  but still.  for a project so heavily reliant on addons, i would think
> any entity, function, variable etc change would need a heavy preponderance
> of justification first.  yet i see trivial and unnecessary changes all the
> time and each adds unproductive churn for the addon dev.

As always, it is a balance and judgement call - between tidying the code up and leaving a mess, between ensuring localisations are up to date and risking them not being so, etc.

Oh, btw, I can think of at least one way extensions can get themselves compatible with more than one version even with string changes, but please ask on the lists if you want hints.