Closed Bug 243798 Opened 20 years ago Closed 5 years ago

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

Categories

(Webtools Graveyard :: MXR, defect)

x86
Windows XP
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: timeless, Unassigned)

References

()

Details

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
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
Closed: 19 years ago
Resolution: --- → INVALID
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 → ---
Assignee: server-ops → chase
Status: REOPENED → NEW
QA Contact: justin → timeless
No cycles to fix LXR bugs.
Assignee: chase → nobody
QA Contact: timeless → lxr
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.

mxr is gone, mass closing.
https://searchfox.org/ is a much better alternative.

Status: NEW → RESOLVED
Closed: 19 years ago5 years ago
Resolution: --- → WONTFIX
Product: Webtools → Webtools Graveyard
You need to log in before you can comment on or make changes to this bug.