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.
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.
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!
ok, the answer is that the file has just one very long line, and lxr concludes that it must therefore be a binary file.
No cycles to fix LXR bugs.
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.