From Bugzilla Helper: User-Agent: Mozilla/4.72 (Macintosh; I; PPC) BuildID: INVALID I am unable to decompress/use the MozillaTranslator.jar file, most likely because of a weird ZIP header (that is what both StuffIt and MacZip reports). Reproducible: Always Steps to Reproduce: 1. Download MozillaTranslator.jar (tried both as ASCII and BINARY) 2. Try to run with Applet runner (MRJ 2.2), does not work: launches Netscape (which reports security error: corrupt JAR file) (this is irrelvant though, since Apple's MRJ is only based on 1.1.8, so it shouldn't _really_ work, but the compressed files are still corrupt (the same goes with other Localisation things, like language packs)

adding self to CC

This is properly duo to the fact that there are "minor" differnces between the traditional zip format (as used by e.g. winZip) and the jar file format. I'll check with the mailing list of my Java IDE and see if they know anything. any particular reason why you need to decompress it ? perhaps I can help solve it somehow btw. mozillaTranslator is not a applet, but a standalone application.

Note that the same header problem also applies to the language pack .zip's on the localization page, such as http://ftp.mozilla.org/pub/mozilla/l10n/lang/nb1b/ mozilla-win32-lang-sv-SE.zip

Well, nothing could really be solved here, since I have no knowledge of a (freely) availible Java 1.2 (2?) runtime software for Mac OS.

There should be no differences in zip and "jar" archive format. The JAR differences are in manifest and signature files contained within the zip archive.

But there *is* a difference. My zip program (Powerarchiver) says language packs created by MozillaTranslator are invalid (but unzips them correctly anyway).

anything new on this ? if it still happens can anyone point me to a "invalid" jar ?

I'm unable to test this, unfortunately. I don't think this is a problem aymore though. It was most likely a local problem.

I do believe this was caused be a bug in the program where i saved the folder separator as \ like in C:\windows\something\myfile.txt instead of using unix style / as in home/henrik/myfile.txt. I think thats why my windows util never complained, but it broke on macs. This bug as long been fixed, so if anyone still is having problems with the zip/jar/xpi files on mac or unix please reopen bug

The MozillaTranslator component is moving to the Mozilla Localisations product.

Version 5.02 on osx 10.2.2: attempting to launch the file gives the following error: --- Jar Launcher The jar file "mt502.jar" couldn't be lauched. It probably doesn't contain a "Main-Class" defenition in the manifest. To be able to launch this jar, you will need to add one. --- what is this? How can I launch the translator?

marking MAJOR, since it prevents me from running the app

The same header problem also applies to localization es-AR jarfiles, but Mozilla seems to work fine. There is a tip from a user, about es-AR.jar: "I had a closer look at the jar file. For some weird reason, there are zero-length files in there with the same names as some of the directories. If such a file gets extracted first, then WinZip is unable to create the directory and thus, the files which would normally reside in that folder will be skipped. I am not sure why these zero-length files are in the .jar file at the first place, but I seem to be able to remove them manually (in WinZip) and then unzip the archive without errors." I'm working on: Mozilla Spanish/Argentina localization project. Mozilla 1.0.1/1.2.1. MT 5.02, Sun's JDK 1.4, Linux Mandrake 8.2, kernel 2.4.19, AMD Duron.

Any news here? I really want to join the translation effort, but this issue is blocking me :-(

yea, what about this bug? can you test it on a mac somehow?

Someone using Mac OS X can confirm this problem still persists? If not, I'm in favour of closing this bug.

Reassigning every MT bug to me.

It has been a month since I asked for confirmation and nobody has replied, so I'm closing this bug.

is this problem fixed

I think this is pretty irrelevant nowadays. Opening JAR directly by the user shouldn't be needed and, anyway, when I took over MozillaTranslator development I probably switched IDE from what Henrik was using to NetBeans. Regarding langpacks, MozillaTranslator created langpacks valid for old XPFE architecture, not for XUL/Toolkit, so they are not used anymore. Last, but not least, I added long time ago a feature to allow using binary zip/unzip utilities instead of built-in Java capabilities. All in all, nobody should be experimenting this bug today.