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)

Assignee

Description

9 years ago
As soon as Firefox 4 is released, we should make the remote xul error page localizable.
Assignee

Updated

9 years ago
Blocks: 623482
Summary: Make XUL error page localizable → Make "Remote XUL unsupported" error page localizable
Duplicate of this bug: 639593

Comment 2

8 years ago
(In reply to comment #0)
> As soon as Firefox 4 is released, we should make the remote xul error page
> localizable.
Keywords: l12y

Comment 3

8 years ago
Shouldn't this page got translated BEFORE 4.0 release?

Comment 4

8 years ago
(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

8 years ago
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)
Assignee

Updated

8 years ago
Whiteboard: [strings] → [strings][needs review]

Comment 6

8 years ago
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

8 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]

Comment 8

8 years ago
(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

8 years ago
Pushed:
http://hg.mozilla.org/mozilla-central/rev/65ad9cb63ca2
Status: ASSIGNED → RESOLVED
Last Resolved: 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...
Assignee

Comment 11

8 years ago
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
Assignee

Comment 13

8 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
Depends on: 651486

Updated

8 years ago
Depends on: 649121
You need to log in before you can comment on or make changes to this bug.