Closed
Bug 625760
Opened 13 years ago
Closed 13 years ago
Make "Remote XUL unsupported" error page localizable
Categories
(Core :: XUL, defect)
Core
XUL
Tracking
()
RESOLVED
FIXED
mozilla5
People
(Reporter: mounir, Assigned: mounir)
References
Details
(Keywords: l12y, Whiteboard: [strings])
Attachments
(1 file)
8.70 KB,
patch
|
sicking
:
review+
|
Details | Diff | Splinter Review |
As soon as Firefox 4 is released, we should make the remote xul error page localizable.
Updated•13 years ago
|
Summary: Make XUL error page localizable → Make "Remote XUL unsupported" error page localizable
(In reply to comment #0) > As soon as Firefox 4 is released, we should make the remote xul error page > localizable.
Keywords: l12y
(In reply to comment #3) > Shouldn't this page got translated BEFORE 4.0 release? The strings were added after the Fx4 string freeze so were hardcoded as English-only (see bug 623482).
Assignee | ||
Comment 5•13 years ago
|
||
We should try to not miss the Firefox 5 train.
Assignee | ||
Updated•13 years ago
|
Whiteboard: [strings] → [strings][needs review]
Attachment #524219 -
Flags: review?(jonas) → review+
Comment on attachment 524219 [details] [diff] [review] Patch v1 >diff --git a/browser/locales/en-US/chrome/overrides/appstrings.properties b/browser/locales/en-US/chrome/overrides/appstrings.properties >--- a/browser/locales/en-US/chrome/overrides/appstrings.properties >+++ b/browser/locales/en-US/chrome/overrides/appstrings.properties >@@ -58,8 +58,9 @@ externalProtocolTitle=External Protocol [snip] >+remoteXUL=This page uses an unsupported technology that is no longer available by default in Firefox. Shouldn't this use %S here and then format it for brandShortName in nsDocShell.cpp using FormatStringFromName? That's how it's done for confirmRepostPrompt.
Assignee | ||
Comment 7•13 years ago
|
||
All strings in browser/locales/en-US/chrome/overrides/appstrings.properties include Firefox. confirmRepostPrompt is the only exception. Those strings are in browser/ so, AFAIK, the only way to have the name different of Firefox is when using nightlies where the name is Minefield. Given that the code to set the string in nsDocShell.cpp is generic and doesn't include adding the brand name, I do not think it's worth making things more complicated. If you think it is, please, file a follow-up to change all "Firefox" to brandShortName.
Whiteboard: [strings][needs review] → [strings][needs landing]
(In reply to comment #7) > All strings in browser/locales/en-US/chrome/overrides/appstrings.properties > include Firefox. Hmm, so they do. This is easily confirmed by typing "htttttttp://mozilla.org" into the location bar and pressing enter on a trunk nightly. You get "Firefox doesn't know how to open this address..." instead of "Minefield...". I thought these had all gone long ago, but apparently not. Bug 546383 and bug 336029 are already on file. I guess this should be checked in as-is then and someone should work on removing the hardcoded "Firefox" afterwards (possibly me if I find some time).
Assignee | ||
Comment 9•13 years ago
|
||
Pushed: http://hg.mozilla.org/mozilla-central/rev/65ad9cb63ca2
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Whiteboard: [strings][needs landing] → [strings]
Target Milestone: --- → mozilla2.2
Comment 10•13 years ago
|
||
Comment on attachment 524219 [details] [diff] [review] Patch v1 > <!-- Include app-specific error messages - do not change this in localization! > Some applications might override netErrorApp.dtd with their specific version, > this inclusion needs to be intact for that approach to work correctly. --> > <!ENTITY % netErrorAppDTD SYSTEM "chrome://global/locale/netErrorApp.dtd"> > %netErrorAppDTD; >+ >+<!ENTITY remoteXUL.title "Remote XUL"> >+<!ENTITY remoteXUL.longDesc "<p><ul><li>Please contact the website owners to inform them of this problem.</li></ul></p>"> I think that the %netErrorAppDTD; needs to be the last line to work...
Assignee | ||
Comment 11•13 years ago
|
||
What issue should I expect? Seems to work here but I might not be looking at the correct error.
Comment 12•13 years ago
|
||
(In reply to comment #11) > What issue should I expect? Seems to work here but I might not be looking at > the correct error. It would make it impossible for netErrorApp.dtd to override that string.
Assignee | ||
Comment 13•13 years ago
|
||
(In reply to comment #12) > (In reply to comment #11) > > What issue should I expect? Seems to work here but I might not be looking at > > the correct error. > It would make it impossible for netErrorApp.dtd to override that string. Follow-up pushed: http://hg.mozilla.org/mozilla-central/rev/a780787bc923
You need to log in
before you can comment on or make changes to this bug.
Description
•