Closed Bug 329724 Opened 15 years ago Closed 14 years ago

understand Safe Browsing's localization situation

Categories

(Toolkit :: Safe Browsing, defect)

defect
Not set
major

Tracking

()

RESOLVED FIXED
Firefox 2 beta2

People

(Reporter: fritz, Assigned: Pike)

References

Details

(Keywords: fixed1.8.1, late-l10n, Whiteboard: [l10n-needed] [mustfix])

Attachments

(1 file)

We haven't tried the UI with hard-to-get-right languages such as CJK or RTL languages like hebrew. We need to try these out and understand our limitations, and fix any problems we find.
QA Contact: nobody → safe.browsing
OK, some thoughts after doing l10n of the file phishing-afterload-warning-message.dtd

1) link to antiphishing.org must be localizable, it makes no sense for non-English users to link to an English language site.

2) the message's structure is weird, all this *.partX, *.linkX and *.dot entities; I suppose it may also cause problems for non-LTR locales. Usually you should have one entity for a message, maybe containing the complete HTML source? (compare e.g. credit.translation in credits.dtd: http://lxr.mozilla.org/l10n-mozilla1.8/source/pl/browser/chrome/browser/credits.dtd#9 )

3) minor issues: the naming conventions seem totally not Mozilla-like,
Agreed Marek, as also discussed on #l10n IRC, this should be localised and explained to the community

If you intend to let localizers change the antiphishing.org, you should write
a proposal on what that's supposed to be.
Not that I'm convinced that the antiphishing.org webpresence is the site we
want to link to. Not that I understand what we link there for at all, that'd
require some serious reverse engineering of 4's and 5's.

Please work on a localization plan for web-links with the Corporation engineer
that guides the integration. It needs to be clear if we want to see special
sites, if not, why we link to a site, if anybody is supposed to check local sites,
and if so, by which rules.
The following resources need to be localized:

  - the message itself (see 343084)
  - links to mozilla.com pages (see 343084)
  - links to the report a false positive
  - link for "get me out of here" (see 339032)

This needs to be done as part of our l10n strategy for tier 1 and 2 locales.
Depends on: 339032, 343084
Flags: blocking-firefox2+
Keywords: late-l10n
Target Milestone: --- → Firefox 2 beta2
(In reply to comment #5)
>   - links to the report a false positive
> 
> This needs to be done as part of our l10n strategy for tier 1 and 2 locales.

Can I get a list of tier 1 and 2 locales?  The report a false positive page has been localized for Google Toolbar supported languages, but we may need to add more.
The proposed tier 1 + 2 locales can be found at http://wiki.mozilla.org/Firefox2/Requirements#Locale_Support

These are the locales with the largest internet population, number of Firefox users, or potential for growth.  It's hard to know where to draw the line.
(In reply to comment #5)
> The following resources need to be localized:
> 
>   - link for "get me out of here" (see 339032)

You wrote in 339032:

> It should really take the user to the localized Firefox Start page.

In that case, does it need to be separately localized?
(In reply to comment #1)

> 2) the message's structure is weird, all this *.partX, *.linkX and *.dot
> entities; I suppose it may also cause problems for non-LTR locales. Usually you
> should have one entity for a message, maybe containing the complete HTML
> source? (compare e.g. credit.translation in credits.dtd:
> http://lxr.mozilla.org/l10n-mozilla1.8/source/pl/browser/chrome/browser/credits.dtd#9
> )

We just localized this text into hebrew for an upcoming release of Google Toolbar and there were only small RTL issues (namely, the brackets around the Report link being backwards).  It's not actually HTML, it's a chunk of XUL, so we can't just put HTML in the dtd file.  We may be able to change it to HTML, but I haven't tried.
> You wrote in 339032:
> 
> > It should really take the user to the localized Firefox Start page.
> 
> In that case, does it need to be separately localized?
> 

No, you should get it directly from the string bundle, and not the pref, to take beltzner's words out of his mouth.
With respect to the RTL story, I think we should have a mockup of the reworked message first and then find out how to localize that.
I'm afraid that we'll end up with something not-so-fortunate whichever way we technically go, but we only can make that compromise once we have the complexity of the message itself.
Whiteboard: [l10n-needed] [at risk]
Axel, what's the path forward here?  What do we need to check/implement to ensure this is the right thing?
Assignee: nobody → l10n
Whiteboard: [l10n-needed] [at risk] → [l10n-needed] [mustfix]
Summary: understand our localization situation → understand Safe Browsing's localization situation
Resolve the dependent bugs first, and then get some localized builds up and tested.
I'm not exactly sure why bug 343084 is in the state it is in.
Bug 339032 is [at risk], at least it says so.

I'm not sure why you assigned this bug to me, though. I can ask the questions, but I doubt I can answer them, apart from technical implemenation comments.
I'm going to try to summarize the thread, so people can tell me where I've misunderstood:

- Some of the content is in the browser (in dialogs and preferences?).  We know how to localize this kind of content; no issue.

- Some of this browser content may not be localizable in a way that's grammatically correct in (for example) RTL or Asian langauges.  Comment #9 says that RTL is in decent shape, comment #11 wants more feedback.

*** Action: Can someone point me at the files in question, so we can ask a CJK and RTL localizer to weigh in?  Please tell me the English text is frozen by now.

- Some of the content includes links to mozilla.com.  Ideally, these URLs should be generated in our new standard format, http://www.mozilla.com/LOCALE/path/

*** Action: Did this already happen?  Is it going to happen?  Should I stop kidding myself?

- We know how to localize those mozilla.com pages.  No issue.

- Some of the content links to antiphishing.org?  Or has this been definitely abandoned?

*** Action: If any links to antiphishing.org remain, someone should write alternative text for the localizers to translate.  For an issue of security, I would prefer to give a short, simple explanation rather than link to a page that the user probably can't read.

...

Have I got it mostly right?
Tony can you confirm the URL situation?

Simon can you help out on RTL verification?
(In reply to comment #15)
> Tony can you confirm the URL situation?

All the urls are in prefs (browser/app/profile/firefox.js).  They understand {moz:locale} for locale so can be updated to point to whatever the actual pages are (e.g., http://www.mozilla.org/{moz:locale}/report_phish/...)
I'm looking at RTL issues now, but first this caught my eye:

 <!ENTITY safeb.palm.p1.linkStatusText "Read more &#133;">

Don't use Windows-1252 codepoints in entities, use the unicode value &#8230;
There aren't any problems with the text layout in RTL languages once the chrome is set to RTL, but as this screenshot shows, there is a problem with the positioning of the bubble: the tail is aligned correctly with the warning icon, but it should be at the left side of the bubble instead of the right side.
The patch to support large fonts included code that if the bubble falls off the browser window, it moves into the center of the browser window without the tail.  I think in RTL languages this will always get triggered making the bubble visible and centered.

I'll see if I can get a more proper fix, but we might not want to block b2 for this.
(In reply to comment #14)
> - Some of the content includes links to mozilla.com.  Ideally, these URLs
> should be generated in our new standard format,
> http://www.mozilla.com/LOCALE/path/

This will be handled by a patch in bug 346242.

> - Some of the content links to antiphishing.org?  Or has this been definitely
> abandoned?

Definitely abandoned.

> Have I got it mostly right?

Mostly; there was also the question of where "Get me out of here" goes, and we decided (in some other bug) to make that the user's homepage, which it now does (if that can't be found, we do about:blank, so again, no l10n issue).

I think we can resolve this bug fixed, now.
Looks like all Fx2 issues are resolved here, thanks to everyone who contributed to cleaning this up.
Status: NEW → RESOLVED
Closed: 14 years ago
Keywords: fixed1.8.1
Resolution: --- → FIXED
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.