Make "Remote XUL unsupported" error page localizable

RESOLVED FIXED in mozilla5

Status

()

defect
RESOLVED FIXED
9 years ago
8 years ago

People

(Reporter: mounir, Assigned: mounir)

Tracking

({l12y})

Trunk
mozilla5
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [strings])

Attachments

(1 attachment)

As soon as Firefox 4 is released, we should make the remote xul error page localizable.
Blocks: 623482
Summary: Make XUL error page localizable → Make "Remote XUL unsupported" error page localizable
Duplicate of this bug: 639593
(In reply to comment #0)
> As soon as Firefox 4 is released, we should make the remote xul error page
> localizable.
Keywords: l12y
Shouldn't this page got translated BEFORE 4.0 release?
(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).
Posted patch Patch v1Splinter Review
We should try to not miss the Firefox 5 train.
Assignee: nobody → mounir.lamouri
Status: NEW → ASSIGNED
Attachment #524219 - Flags: review?(jonas)
Whiteboard: [strings] → [strings][needs 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.
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).
Pushed:
http://hg.mozilla.org/mozilla-central/rev/65ad9cb63ca2
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Whiteboard: [strings][needs landing] → [strings]
Target Milestone: --- → mozilla2.2
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...
What issue should I expect? Seems to work here but I might not be looking at the correct error.
(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.
Depends on: 648268
(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
Depends on: 649121
You need to log in before you can comment on or make changes to this bug.