I would like to ask each l10n team to submit a dictionary extension to
addons.mozilla.org:
1) First, you need to have the myspell .aff and .dic files for your language
dictionary. These can be under any open-source license, including GPL.
2) Feed these files into the webtool at
http://benjamin.smedbergs.us/dictionary-packager/
the "version" field should match up with release numbers for your localized
dictionary if possible.
3) The webtool should feed you a dictionary XPI of the name fr-dictionary.xpi
4) go to https://addons.mozilla.org/developers/ and submit the extension to
the addons system. It should be automatically marked compatible with Firefox
2.0b2 to 2.0.0.* and Thunderbird 2.0b2 to 2.0.0.*. You should manually mark
the extension compatible with SeaMonkey 1.1. Add the extension to the
"dictionaries" category of Firefox, Thunderbird, and SeaMonkey.
I will go through and approve the dictionaries on addons.mozilla.org fairly
regularly.
--BDS
Benjamin Smedberg wrote:
> 4) go to https://addons.mozilla.org/developers/ and submit the extension
> to the addons system. It should be automatically marked compatible with
> Firefox 2.0b2 to 2.0.0.* and Thunderbird 2.0b2 to 2.0.0.*. You should
> manually mark
> the extension compatible with SeaMonkey 1.1. Add the extension to the
> "dictionaries" category of Firefox, Thunderbird, and SeaMonkey.
I made it to this step, but here I get the following error:
> > Warning: Invalid argument supplied for foreach()
in /opt/update/core/inc_global.php on line 365
> > Error! The MaxAppVer for Firefox of 2.0.0.* in install.rdf is invalid.
> > Error! The MinAppVer for Thunderbird of 2.0b1 in install.rdf is invalid.
> > Error! The MaxAppVer for Thunderbird of 2.0.0.* in install.rdf is
invalid.
> > Errors were encountered during install.rdf checking...
> >
> > How to fix this:
> >
> > * See the list of valid version numbers
> > * minVersion (MinAppVer) values may only contain values 0-9 and '.'
because they have to be an absolute version. minVersions like 1.0+ or
1.5.0.* are not allowed.
> > * Your version has not been found in the addons database but it
should be. See #a...@mozilla.org in IRC if you think this is in error.
> >
> > Aborting...
What should I do about it?
Cheers
Aleks
> What should I do about it?
Fixed, I think. Please try again.
--BDS
I've tried again, but get exactly the same error. Maybe it takes a while for
any changes you've made to take effect?
Cheers
Aleks
Well, this may sound a bit "aolish", but: me too. :)
--
Marek Stępień <mar...@aviary.pl>
AviaryPL - polski zespół lokalizacyjny Mozilli
http://www.firefox.pl/ | http://www.mozilla.org.pl/
Firefox accepts the following version numbers
Firefox 2.0.0.* {ec8030f7-c20a-464f-9b0e-13a3a9e97384}
Firefox 2.0a1 {ec8030f7-c20a-464f-9b0e-13a3a9e97384}
Firefox 2.0a2 {ec8030f7-c20a-464f-9b0e-13a3a9e97384}
Firefox 2.0a3 {ec8030f7-c20a-464f-9b0e-13a3a9e97384}
Firefox 2.0b1 {ec8030f7-c20a-464f-9b0e-13a3a9e97384}
Firefox 3.0a1 {ec8030f7-c20a-464f-9b0e-13a3a9e97384}
But Thunbderbird only accepts
Thunderbird 2.0a1 {3550f703-e582-4d05-9a08-453d09bdfdc6}
Thunderbird 3.0a1 {3550f703-e582-4d05-9a08-453d09bdfdc6}
Marek Stepien escribió:
> What should I do about it?
ok, the issues are fixed. Please *remake* your XPI using the
benjamin.smedbergs.us/dictionary-packager website, and resubmit to addons.
It should automatically accept the proper version numbers now.
--BDS
Great, it seems to work now (it still produces a few errors, but that
doesn't seem to affect the upload, etc).
However, the name of the dictionary and the description seem to be
incorrectly encoded, and likewise the generated filename - the letter Č is
made out to be �, or '_auml_' for the filename. Can this be fixed?
Cheers
Aleks
Hmm, it still fails for me with "Language code must be
ab[-CD[-modifier]]" when I use "de-DE" as the Language code.
Maybe the problem is in fact not the language code, but the really huge
.dic file, which is 9.6 MB (!) for the current German (DE) dictionary...
It worked OK for me for the much smaller de-CH dictionary, but de-DE and
de-AT are much bigger files (yes, German has three variants, and I even
left out those for the legacy writing rules).
Robert Kaiser
> However, the name of the dictionary and the description seem to be
> incorrectly encoded, and likewise the generated filename - the letter Č is
> made out to be �, or '_auml_' for the filename. Can this be fixed?
Interesting... I tested this using unicode characters and it seemed to work
for me.
I'm confused, though... you say the name of the dictionary is incorrectly
encoded? How can that be, since the name of the dictionary should be
cz-dictionary.xpi ?
--BDS
Perhaps... I tried uploading French dictionaries and pretending it was de-DE
langcode and that worked.
I can't change the max upload limit on my server, so you may need to package
that dictionary by hand, or copy the PHP files to your own server and
package it there.
--BDS
Well, yes, the original filename was in fact sl-dictionary.xpi, but after
having uploaded it, the server renamed it into:
_auml_rkovalnik_za_slovenski_jezik-0.1-fx+zm+tb.xpi
Unicode seems to work *inside* the XPI, because the description was
correctly read by the server on upload; however, when it was saved on the
website, it got wrongly encoded.
Should I attempt the entire procedure again with a name which doesn't
contain any non-ASCII letters? (I can use 'slovar' instead of 'črkovalnik'
if need be.) But then someone would need to delete the current version, as
I don't seem to have the permissions to do so.
Cheers
Aleks
> Unicode seems to work *inside* the XPI, because the description was
> correctly read by the server on upload; however, when it was saved on the
> website, it got wrongly encoded.
ok... let's not worry about the filename, since users don't really see that.
I think there's a way for you to update the description of the extension
after you've submitted it. (I know there is in my interfaces, but I'm an AMO
admin so I'm not sure whether your interface shows the same UI). Please try
that first. If it doesn't work, send me the description you want to use, and
I'll try using my edit system to update it.
We perhaps should file a bug agianst AMO about the incorrect encoding
detection. When you read AMO pages, what charset is the browser using?
--BDS
I'm seeing the same... Looks like AMO doesn't understand UTF-8 correctly :(
Definately looks like a bug of AMO to me.
Robert Kaiser
OK, having the de-CH one it's easy to repackage the others using the
same layout and adopted install.* files, I'll do that...
Robert Kaiser
Argh, and now AMO chokes on that 2.5 MB .xpi files :(
Robert Kaiser
OK, I've updated the description and name to one that uses ASCII characters
only. However, that kind of solution probably isn't practicable for most
languages - especially those which use only non-ASCII characters (eg Arabic
or Chinese). I suppose it might make sense to wait to see what their
experience is with the AMO system.
When viewing AMO pages, the browser uses Unicode, as it of course should:
the charset IS in fact specified in the HTML headers. I think the problem
must be with the form-processing scripts - ie with that part of the system
which transcribes what is given in forms into its database, or perhaps the
part which reads the database and serves it in HTML form?
(oops, I apparently sent this by email by accident; reposting to the
newsgroup)
Cheers
Aleks
> 1) First, you need to have the myspell .aff and .dic files for your
> language dictionary. These can be under any open-source license, including
> GPL.
Italian dictionary is released under GPL license but it's not maintained by
us. This team releases an xpi version with a lot of files inside (gpl
license, thanks, readme, etc. etc.); can I add these files to the xpi
generated by your script before submitting the xpi to AMO?
Francesco.
Yes.
--BDS
Please search/file/cc me.
--BDS
Looks like the same problem as already filed here:
https://bugzilla.mozilla.org/show_bug.cgi?id=332459
Robert kaiser
Robert Kaiser escribió:
>
> Looks like the same problem as already filed here:
> https://bugzilla.mozilla.org/show_bug.cgi?id=332459
>
> Robert kaiser
And there is a good workaround if you can write the description in
ISO-8859-1.
Quoting the bug:
The workaround I found for now is that after loading the Item Edit page,
to change the browser into ISO-8859-1, enter data and submit, and that
will work (if the characters you want work in that charset).
Robert, I recall that both the swiss and the austrian dicts are
supplementals to the regular german dictionary, at least that's the info
I get on thunderbird-mail.de.
I wonder if you should package those up to include the german
dictionary, or even use extension dependencies.
Axel
The swiss is a separate dictionary, the Austrian is meant to extend the
de-DE one, but I think we don't support pointing a "de-AT" entry to use
"de-DE.dic + de-AT.dic" like OOo does, so I did a de-AT.dic which
actually has both merged into one.
Nevertheless, the de-DE.dic alone is 9.6 MB in uncompressed form, and
the de-DE XPI file is 2.5 MB, which is still not accepted by AMO, though
they tried to fix that yesterday.
Robert Kaiser
Extension dependencies wouldn't be working. Thunderbirds/Seamonkeys
myspell implementation doesn't support the combination of 2 or more
dicts. So dependencies would only install both dicts - not more.
Alex Ihrig
Robert
No luck with the Greek spelling dictionary . I've submitted once, but
seems that is not accepted, and now the addons system claims that I am
not the owner of the dictionary and rejects any new dictionary
submissions. If someone can committed me for me the file is at
http://www.pkst.gr/el-dictionary.xpi
Thanks
Kostas