Closed Bug 47676 Opened 20 years ago Closed 18 years ago

HTTP auth password dialogbox is not localizable.

Categories

(Core :: Networking: HTTP, defect, P3)

x86
Windows NT
defect

Tracking

()

VERIFIED FIXED
mozilla1.0

People

(Reporter: ftang, Assigned: darin.moz)

References

()

Details

(Keywords: l12y)

reproduce procedure
1. use localize build ja/de/fr
2. visit http://www.w3.org/International/Group
The dialog is not localizable. The bad code is in 

mozilla/netwerk/protocol/http/src/nsHTTPChannel.cpp

2026 valeski      1.92          //TODO localize it!
2027 scc          1.155         nsAutoString message; 
message.AssignWithConversion("Enter username for "); 
2028 shaver       1.186         // later on change to only show realm and then 
host's info. 
2029 scc          1.155         message.AppendWithConversion(iChallenge);
2030 valeski      1.92          
2031                            // Get url
2032 warren       1.180         nsXPIDLCString urlCString; 
2033 warren       1.183         mURI->GetPrePath(getter_Copies(urlCString));
2034 shaver       1.186             
2035 warren       1.183         nsAutoString prePath = 
NS_ConvertToString(urlCString); // XXX i18n
2036 warren       1.180         rv = 
mPrompter->PromptUsernameAndPassword(nsnull,
2037                                                                      
message.GetUnicode(),
2038 warren       1.183                                                   
prePath.GetUnicode(),
2039 morse        1.201                                                   
nsIPrompt::SAVE_PASSWORD_PERMANENTLY,
2040 shaver       1.186                                                   
getter_Copies(userBuf),
2041                                                                      
getter_Copies(passwdBuf),
2042 warren       1.180                                                   
&retval);
2043 shaver       1.186         if (NS_FAILED(rv))
2044 gagan        1.129             return rv;

Please move these string into string bundle.
this is localizability issue. Without it, we can not ship localized client. 
nsbeta3
Keywords: nsbeta3
actual behavior
See English string "Enter username for " in localize build.

expect behavior
in localize build see these text translated into japanese/french/germany
We've got a string bundle for this stuff: 
netwerk/resources/locale/en-US/necko.properties

This is gagan's code -- reassigning.
Assignee: warren → gagan
Target Milestone: --- → Future
Whiteboard: [nsbeta3-]
http bugs to "Networking::HTTP"
Assignee: gagan → darin
Component: Internationalization → Networking: HTTP
QA Contact: teruko → tever
Target Milestone: Future → M19
removing stale nsbeta3 keyword.
Keywords: nsbeta3
Whiteboard: [nsbeta3-]
Target Milestone: --- → Future
If someone can suggest how this might be done, I'll have a go - but I can't find 
other examples of how it's done elsewhere... Do I really need to create a 
StringBundleService as suggested on 
http://www.mozilla.org/projects/intl/string-resources.html ?

Gerv
yes, you need to use stringBundle to retrieve it from 'necko.properties'. You
should be able to find example code in mozilla with lxr.
Sample code is in mailnews/compose/src/nsSmtpProtocol.cpp in 
nsSmtpProtocol::GetUsernamePassword()
Target Milestone: Future → mozilla1.0
darin: I should make the point here that I'm finding this a bit beyond me, and 
you shouldn't rely on me fixing it... Sorry about that :-( It's not at all as 
straightforward as I thought it was.

Gerv
Keywords: l12y
Keywords: nsBranch
Blocks: 99142
No longer blocks: 99142
This is targeted for 1.0, let's mark this one nsbranch- for this round.
If we want more secured features, I'd suggest we take this.
Marking nsbranch- as it was decided in the August bug triage that we wouldn't
have enough time in eMojo to fix this.  Let's revisit for MachV.
Keywords: nsbranch-
Keywords: nsbranch
Blocks: 107067
Keywords: nsbranch-
adding nsbeta1
Keywords: nsbeta1
Doesn't this fixed in version 1.2 of nsHttpChannel.cpp (11 May 2001) ?
See nsHttpChannel::PromptForUserPass(), around lines 1548-1577...
denis: yeah, i think you are correct.  marking FIXED.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
verified
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.