Closed Bug 25958 Opened 25 years ago Closed 24 years ago

mail window title should say "Netscape" not "Mozilla".

Categories

(SeaMonkey :: MailNews: Message Display, defect, P1)

x86
Windows 98
defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: jglick, Assigned: bugzilla)

References

Details

(Whiteboard: [PDT+])

3 Pane Mail-window title dislayed is "Mozilla", this needs to be changed for B1.

Please see UE spec for details.

http://gooey/client/5.0/specs/mail/messenger/messenger.html#Title
QA Contact: lchiang → nbaca
This is done by some shared code somewhere. Maybe danm? nominating for beta1.
Assignee: phil → danm
Keywords: beta1
Summary: 3 Pane mail - window title shouldn't say "Mozilla". → ail window title should say "Netscape" not "Mozilla".
Putting on PDT+ radar for beta1.
Whiteboard: [PDT+]
Changing summary to "Mail" instead of "ail"

;-)
Summary: ail window title should say "Netscape" not "Mozilla". → mail window title should say "Netscape" not "Mozilla".
Since Travis redesigned window title setting, the three-pane mail/news window no 
longer has a centrally-controlled "Mozilla" moniker added. The m/n window title 
is now completely specified in commandglue.js:ChangeFolderByURI, so I'm fobbing 
this off on alecf.
Assignee: danm → alecf
noise, ignore

adding tao to the CC

Tao, is there a global string bundle and string ID that has "Netscape" in the

commercial build, and "Mozilla" in the mozilla build?

No. The closest thing I can find is:

tasksOverlay.dtd :

	<!ENTITY  mozillaButton.label "Mozilla">

In fact, we ask localizers not to translate them since "Netscape" and "Mozilla"
are TMs. However, these strings still need to be externalized into *.dtd or 
 *.properties since not Netscape branded versions are supposed to removing the
"Netscape" branding.


Thanks for asking.


Tao, are you filing a new bug? can you put me on the CC?

My guess is that we should have a generic branding properties file in
chrome://global/locale/ for common strings like this.
ok, I've created the global string bundle and set up the dependancy.... 
Next step is making a netscape-specific string bundle, and making mail honor it.
Status: NEW → ASSIGNED
Depends on: 27294
Whiteboard: [PDT+] → [PDT+] 2/11
Target Milestone: M14
Hi, Alec:

Do you still need a new bug? Could you use this bug to cover both?

Let me know!


Thanks for the good work!
mozilla-side fix reviewed by putterman, just need to add to the netscape tree
Priority: P3 → P1
yay, this is done.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Build 2000-02-14-16M14: NT4, Linux 6.0
Build 2000-02-14-12M13: Mac 8.6.1
Reopening

I don't know if it's a focus problem but after a message is selected in the 
Thread pane, the Title Window uses the format of "<folder> on account" (i.e. 
Inbox on qatest20@netscape.com). It doesn't mention "Netscape" or follow the 
format that the spec specifies.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
oh damn, I forgot to checkin this file.
Status: REOPENED → ASSIGNED
Whiteboard: [PDT+] 2/11 → [PDT+] fix in hand
checked in!
Status: ASSIGNED → RESOLVED
Closed: 25 years ago25 years ago
Resolution: --- → FIXED
by the way, I checked in what I believe is minimal for beta1 - it matches the
spec except for the <subject> part. We should open a new non-PDT+ bug for that.
Waiting for a good Linux build.

- NT4 build 2000-02-15-09M14: Incorrect. It states <folder> for <account> - 
Mozilla. (i.e. Inbox for qatest20@netscape.com - Mozilla)
- Mac build 2000-02-09M14: It appears correct because it references Netscape. 

Is this a build problem?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
yes, I believe it is.
I'll fix this tomorrow when I have a windows build
Status: REOPENED → ASSIGNED
Whiteboard: [PDT+] fix in hand → [PDT+] 2/17 windows build problem
I don't know, if that help for JS, but there is a macro definition in allxpstr.h
for the product <http://lxr.mozilla.org/seamonkey/source/include/allxpstr.h#26>.
This works fine for me with a Mozilla debug build from this mornig. Title 
correcly update when I select a folder and the product name is Mozilla.
Sorry, I didn't read correctly the problem. It's not fixed!
With a commercial debug build from today, Messenger 3panes window correctly say 
Netscape (while it was saying Mozilla with a Mozilla build). However, the 
browser window still say "Mozilla".

I have an hard time to download a commercial release build.
Assignee: alecf → ducarroz
Status: ASSIGNED → NEW
Whiteboard: [PDT+] 2/17 windows build problem → [PDT+] 2/18 windows build problem
Status: NEW → ASSIGNED
The ns version of file "brand.properties" isn't part of any of the commercial 
pakage (Win32, Mac & Unix).

I have a fix in hand but wont be able to test it myself! We need to check it in 
and wait for the new commercial installer.
Whiteboard: [PDT+] 2/18 windows build problem → [PDT+] 2/18 commercial pakage problem. Fix in hand
here is the fix:

Index: packages-mac
===================================================================
RCS file: /m/src/ns/xpinstall/packager/packages-mac,v
retrieving revision 1.22
diff -r1.22 packages-mac
18a19
> viewer:Chrome:global:locale:en-US:brand.properties
Index: packages-unix
===================================================================
RCS file: /m/src/ns/xpinstall/packager/packages-unix,v
retrieving revision 1.12
diff -r1.12 packages-unix
42a43
> bin/chrome/global/locale/en-US/brand.properties
Index: packages-win
===================================================================
RCS file: /m/src/ns/xpinstall/packager/packages-win,v
retrieving revision 1.38
diff -r1.38 packages-win
r=leaf
Fixed and checked in

Status: ASSIGNED → RESOLVED
Closed: 25 years ago24 years ago
Resolution: --- → FIXED
Whiteboard: [PDT+] 2/18 commercial pakage problem. Fix in hand → [PDT+]
Build 2000-02-22-16M14: NT4
Build 2000-02-22-12M14: Linux 6.0
Build 2000-02-22-11M14: Mac 8.5.1
Verified Fixed. The window title now references "Netscape".

I will create a new bug for the window title not conforming completely with the 
spec.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.