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)
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?
Comment 1•20 years ago
|
||
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
Comment 2•19 years ago
|
||
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•19 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
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
Updated•18 years ago
|
QA Contact: timeless → lxr
Comment 6•17 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.
Comment 7•5 years ago
|
||
mxr is gone, mass closing.
https://searchfox.org/ is a much better alternative.
Status: NEW → RESOLVED
Closed: 19 years ago → 5 years ago
Resolution: --- → WONTFIX
Updated•4 years ago
|
Product: Webtools → Webtools Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•