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
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
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 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → DUPLICATE
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.
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.
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.
You need to log in before you can comment on or make changes to this bug.