Why does lxr think dom.properties is a binary file?

NEW
Unassigned

Status

Webtools
MXR
14 years ago
5 years ago

People

(Reporter: timeless, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

14 years ago
1. load http://lxr.mozilla.org/seamonkey/source/dom/resources/locale/dom.properties
1' Binary File: dom.properties
1` something closer to
http://lxr.mozilla.org/seamonkey/source/dom/resources/locale/dom.properties?raw=1,
but with line numbers...

on my system:
R:\2004>type \mozilla\dom\resources\locale\CVS\Entries
/dom.properties/1.7/Wed Feb 18 21:39:08 2004//

there's no -kb tag...
what's so special?
Reassigning to default owner/qa on endico's open bugs so I don't have to watch
her to get mail on them.
Assignee: endico → myk
QA Contact: myk → justdave
Myk used to be the default assignee for this component.  Reassigning all remaining open bugs owned by him that he doesn't appear actively involved in to the default assignee/qa for later reassignment.
Assignee: myk → server-ops
QA Contact: justdave → justin

Comment 3

12 years ago
That file appears to be long gone. The closest I could find was:

http://lxr.mozilla.org/seamonkey/source/dom/locales/en-US/chrome/dom/dom.properties

and it seems OK... 

If you find another file that is binary and should not be, please open another bug.

Thanks for you report!
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → INVALID
(Reporter)

Comment 4

12 years ago
ok, the answer is that the file has just one very long line, and lxr concludes that it must therefore be a binary file.
Status: RESOLVED → REOPENED
Component: Server Operations → LXR
Product: mozilla.org → Webtools
Resolution: INVALID → ---
(Reporter)

Updated

12 years ago
Assignee: server-ops → chase
Status: REOPENED → NEW
QA Contact: justin → timeless

Comment 5

12 years ago
No cycles to fix LXR bugs.
Assignee: chase → nobody
QA Contact: timeless → lxr

Comment 6

10 years ago
This happens for l10n very often, for example, 

http://lxr.mozilla.org/l10n/source/ne-NP/browser/chrome/branding/brand.dtd

My suspect is that too much utf-8 isn't good either, but I have no code to back that up.

This is even more annoying to localizers, as they are more likely to assume that they broke something than that lxr is just not too happy about non-ASCII.

My hope would be that if we made lxr check for utf-8 instead of ascii, this wouldn't be too hard to fix, but I have no idea how to find the right spot in the lxr sources to back that up.
You need to log in before you can comment on or make changes to this bug.