844611 - Use entity rather than fixed string for "SeaMonkey" in help content

Status: RESOLVED FIXED

(SeaMonkey :: Help Documentation, defect)

Description

[rsx11m]

Once you start digging for "stuff" you find it.  ;-)
So, here comes some more (trivial) stuff:

Whenever the application name is to be included in labels or help content, the &brandShortName; entity should be used instead of a fixed string to allow for a different branding. This is violated in two instances of the help files.

Comment 1

[rsx11m]

Attachment: Proposed patch

Stefan, sorry for keeping you busy, but this is literally a 2-liner.

The first hunk addresses the code introduced by bug 657126 and should be straight-forward (i.e., definitely a case where the entity name has to be used).

The second hunk was a drive-by fix in bug 423282 and presents an example of browser-provided information. My thinking is that using the actual brand here should be better as well to present a user-recognized name, whereas the fixed version number may or may not match the branding, but that shouldn't present a problem to understand the example. Also, the UI locale is no longer presented in the UA string per bug 572656, thus I've removed the "French" part. Finally, I've modernized the OS version in this example as Win2k isn't quite up to date any more.

Whenever you have time to get to this...

Comment 2

[Stefan [:stefanh]]

Comment on attachment 717625 [details] [diff] [review]
Proposed patch


>-  use the French version of SeaMonkey 2.1 on a Windows 2000 computer.</p>
>+  use &brandShortName;&nbsp;2.1 on a 64-bit Windows&nbsp;7 computer.</p>

So on Mac we don't expose the 32-/64-bit in the ua (but in a few years we'll just have 64-bit builds there) and I don't think we have any 64-bit windows builds (we do expose the 64/32 bits, though). In other words, you should probably leave out the 64-bit part here. We should update the SeaMonkey version to the current (2.19 since we're on trunk).

r=me with those 2 nits fixed.

Comment 3

[Stefan [:stefanh]]

Oh, sorry - forgot to mention that unless you really want them, you could leave out the non-breaking spaces - we don't use these anywhere else in help.

Comment 4

[rsx11m]

Attachment: Final patch

(In reply to Stefan [:stefanh] from comment #2)
> So on Mac we don't expose the 32-/64-bit in the ua (but in a few years we'll
> just have 64-bit builds there) and I don't think we have any 64-bit windows
> builds (we do expose the 64/32 bits, though).

Ok, Windows exposes the 32-bit build on a 64-bit platform it with "WOW64" in the UA string, Linux has a "x86_64", but I agree that this may be a confusing detail.
 
> We should update the SeaMonkey version to the current (2.19 since we're on trunk).

Done.

(In reply to Stefan [:stefanh] from comment #3)
> Oh, sorry - forgot to mention that unless you really want them, you could
> leave out the non-breaking spaces - we don't use these anywhere else in help.

Done. The idea was to prevent "Windows 7" to break with "Windows" fitting in one line and "7" ending up in the next, which looks a bit odd, but removed those if it's not done anywhere else.

Comment 5

[Ian Neal]

(In reply to rsx11m from comment #4)
> Created attachment 717655 [details] [diff] [review]
> Final patch
> 
> (In reply to Stefan [:stefanh] from comment #3)
> > Oh, sorry - forgot to mention that unless you really want them, you could
> > leave out the non-breaking spaces - we don't use these anywhere else in help.
> 
> Done. The idea was to prevent "Windows 7" to break with "Windows" fitting in
> one line and "7" ending up in the next, which looks a bit odd, but removed
> those if it's not done anywhere else.
I would say on that basis I agree we should keep the non-breaking spaces (perhaps there are other areas of help that need that too?)

Comment 6

[rsx11m]

Ok, I'll make the change here, don't know if any other instances are affected.

Comment 7

[rsx11m]

Attachment: Final patch (v2b)

This reverses comment #3. Since it was optional, I'm carrying forward the r+.

I've searched over the help directory and didn't find any other occurrence of Windows+<version>. There are a couple of "OS X" which may have a similar issue, but changing those to "OS&nbsp;X" should probably be a separate bug.

Comment 8

[rsx11m]

Push for trunk of this version now, please.

Comment 9

[Stefan [:stefanh]]

http://hg.mozilla.org/comm-central/rev/740e3eba2335