385458 - UI strings using "browser" when meaning "application"

Status: RESOLVED FIXED

(Core Graveyard :: Security: UI, defect)

Description

[Robert Kaiser]

We have a few UI strings in Security UI that are talking about a "browser" when the code could be used in non-browser applications. We should use "application" instead in those places.

Comment 1

[Kai Engert (:KaiE:)]

I agree

Comment 2

[Robert Kaiser]

Attachment: patch v1: replace "browser" with "application"

This patch removes all uses of "browser" in security UI, using "application" instead in most cases.

Comment 3

[Kai Engert (:KaiE:)]

Comment on attachment 269402 [details] [diff] [review]
patch v1: replace "browser" with "application"

I think I should r- this patch.

I was told, when strings change their semantic, the string ID should change.

In order for the patch to be complete, we'd have to change all the places in the sources where these string IDs are used, too.

Comment 4

[Axel Hecht [:Pike]]

I'm afraid we need to rev the entity names once again, too. The change is semantic, and we do want localizers to pick this change up without having a test available to do so without changing the names.

Are those files overwritten by Firefox specific files?

Comment 6

[Marek Stępień [:marcoos, inactive]]

(In reply to comment #4)
> Are those files overwritten by Firefox specific files?

Not all of them.

BTW, if you're changing "browser" to "app" you should also replace "webmasters" with "administrators" and "websites" with "servers". (Yes, currently if there's sth wrong with a certificate, Thunderbird 2 tells you to contact the *webmaster* about problems with a *website*).

Comment 7

[Robert Kaiser]

http://mxr.mozilla.org/seamonkey/search?string=CrlImportSuccess looks to me as this string was unused, so I think we might be able to just remove it - is this really true?

Same for http://mxr.mozilla.org/seamonkey/search?string=CrlUpdatePrefsSetConfirmation - we can kill this as well, right?

Comment 8

[Robert Kaiser]

(In reply to comment #6)
> BTW, if you're changing "browser" to "app" you should also replace "webmasters"
> with "administrators" and "websites" with "servers". (Yes, currently if there's
> sth wrong with a certificate, Thunderbird 2 tells you to contact the
> *webmaster* about problems with a *website*).

For a browser that would be perfectly valid, for a mail client it probably isn't, right. Could you either file a different bug on that or clearly identify which strings need to be changed for this?

Comment 9

[Robert Kaiser]

Attachment: patch v2: also change string IDs

This patch also changes all involved string IDs and kills the two strings mentioned before.

I'll file a followup against Camino so that they fix their camino/embed-replacements/locale/en-US/pipnss/pipnss.properties but I don't want to touch any Camino-specific stuff as long as they claim to be "like Firefox".

Comment 10

[Marek Stępień [:marcoos, inactive]]

(In reply to comment #8)
> For a browser that would be perfectly valid, for a mail client it probably
> isn't, right.

Yeah, but what sense does it make to get rid of the word "browser" and leave all the "browserisms" in place?

>  Could you either file a different bug on that or clearly identify
> which strings need to be changed for this?

Almost the whole newserver.dtd
http://lxr.mozilla.org/mozilla/source/security/manager/locales/en-US/chrome/pippki/newserver.dtd#44

- newserver.title ("website")
- newserver.reason1 ("browser", "site")
- newserver.reason2 ("site")
- newserver.notify ("site's webmaster")

Comment 11

[Kai Engert (:KaiE:)]

Comment on attachment 270900 [details] [diff] [review]
patch v2: also change string IDs

r=kengert

It's still not perfect. I wish there were a better universal word than "application". But I agree this patch is more correct.

You could leave out the change to newserver.dtd and newserver.xul. I will very likely remove that soon. See bug 327181.

Comment 12

[Robert Kaiser]

I checked in all parts of the patch nevertheless - it doesn't hurt to check in an already finished patch to files that go away - it would be useless to work even more on newserver.dtd like stated in comment #10 though ;-)

Comment 13

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Why not use &brandShortName; instead, rather than the very generic "application"?

Comment 14

[Robert Kaiser]

&brandShortName; only easily works in DTDs/XML, and my coding skills aren't good enough (yet) to inject this into JS or C++ code, I think...