309854 - [l10n] Security warning when leaving encrypted pages is not localizable

Status: RESOLVED DUPLICATE of bug 248160

(Camino Graveyard :: General, defect)

Description

[Marcello Testi]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.4.1) Gecko/2002 - Netscape 6.2, Mac OS X
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.4.1) Gecko/2002 - Netscape 6.2, Mac OS X

If you enable the warning in the security pref pane and actually leave an
encrypted page going to a non-encrypted one, you are shown a warning. This
warning should be localizable, but it's nowhere to be found inside the *.lproj
folders

Reproducible: Always

Steps to Reproduce:
1. Use a localized version of Camino and make sure your system language matches
the localization used
1. Activate the first option in the security pref pane
2. Visit Bugzilla
3. Visit caminobrowser.org

Actual Results:  
Regardless of the language you are using, the warning you get is shown in English

Expected Results:  
The pkg should contain a string or a .nib file inside *.lproj folders, in order
to make the string localizable

Comment 1

[Marcello Testi]

The problema affects also the dialog for mixed (encrypted/non-encrypted) pages.
At this point, I guess that also the low encryption warning should be affected,
but I don't know how to test it.
To see the mixed warning: https://online.fineco.it/public/banking/menocosti.asp

Comment 2

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

This is the chrome bug again :-(  Looks like those come from NSS:

http://lxr.mozilla.org/mozilla/source/security/manager/locales/en-US/chrome/pipnss/security.properties

*** This bug has been marked as a duplicate of 248160 ***

Comment 3

[Marcello Testi]

I'm not that much into bugzilla common practices, but I think it might be
correct to call a "depends on 248160" for this bug, instead of closing as dupe.
If we continue to append "applies also to..." to the bottom of bug 248160, I
suspect we might miss something when we try to fix it.
Moreover, I suspect that this particular one might be a a regression, since I
can remember myself translating those strings in the past for Camino/Chimera.

Comment 4

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

I think that it's an edge case that could probably be argued either way.  Since
that bug began by listing a series of strings, to me it makes more sense to keep
all the strings there. Moreover, at this point, we know that the strings that
won't be translated are all ones that end up in embed.jar, so to get all the
strings, just unzip embed.jar (well, only a subset of those foo.properties files
are actually used in Camino).

I'm not sure how this particular set of strings could be a regression, though,
because they are packed in embed.jar just like all the others.

Comment 5

[Marcello Testi]

The regression could be that once we used custom Camino strings for these
dialogs and now we lean on Gecko. The suspect arises also because only recently
the problem has been notified by international users.