Messages

I found a bug with the content declarations.  The declaration for Content02 is using the declaration for Content01.

I'd like Content01 as black font with italics.
I'd like Content02 as blue font and no italics.

language2NumberOfContentDeclarations=02
language2Content01DisplayText=Italics
language2Content02DisplayText=Pinyin

language2Content01FontStyle: italic
language2Content02FontColour=0,0,255

But, Content02 is actually showing as black font with italics.

If I change Content2 to Content1, then Content2 shows the blue font OK:

language2NumberOfContentDeclarations=02
language2Content01DisplayText=Italics
language2Content02DisplayText=Pinyin

language2Content01FontColour=0,0,255
language2Content02FontStyle: italic

Oops, here you go

http://prdownloads.sourceforge.net/dictionarymid/DictionaryForMIDs_3.5.0(beta2).zip?download

Jeff

I uploaded a new version of the build environment.  You can download it here http://prdownloads.sourceforge.net/dictionarymid/DictionaryForMIDs_3.5.0(beta2).exe?download.

I only added another sample dictionary with content declarations.  It is in C:\Dict\Advanced\.

I also cleaned up newdict.html a little.  Nothing else is changed.

When we finish and publish the final version I thought we'd offer a ZIP file with all the tools and a self-extracting archive for Windows users.

Do you guys know how to use 7-zip to use a default extract folder?  For example, in WinZip and WinRAR when I make a SFX archive, I can tell the program to extract to C:\Dict\ by default.  How do you do that in 7-zip?  I thought it'd be nice if we use 7-zip instead of WinRAR or something.

Jeff

Thanks for looking into this.  It's no problem if the DictionaryForMIDs.properties must be in ISO-8859-1.  Personally I save everything in UTF-8.  So it's just a personal preference.

And I was thinking of the build environment for new users of DfM.  We have UTF-8 for all the options, so I thought it might be confusing if only the DictionaryForMIDs.properties is saved in ISO-8859-1.

dictionaryGenerationInputCharEncoding: UTF-8
indexCharEncoding: UTF-8
searchListCharEncoding: UTF-8
dictionaryCharEncoding: UTF-8

I like Jacob's idea of saving the user's DictionaryForMIDs.properties in UTF-8 and then changing it to ISO-8859-1 in dictionary\DictionaryForMIDs.properties (using \u0109, for example).

Jeff

Consider including that as a sample. 'evrything' includes setting languageNormationClassName and languageContentDisplayText etc, and with an input dictionary included entries like [01foo [02bar]] that actually uses these things

That's a good idea.  I'll add some content declarations to the sample dictionary file.

What is definitely also missing is an full example of doing everything, complete with all input files and a script for producing the output files.
And perhaps all a small minimal example sample

I have a very simple sample file in the Dictionary_input.txt file.  And I have the setup.bat and jar.bat files to build the dictionary.  Do you have any suggestions for making it better?  I put a link to the tools here http://prdownloads.sourceforge.net/dictionarymid/DictionaryForMIDs_3.5.0(beta1).exe?download.

But we need to be sure to emphasize that the tools and implementations for DictionaryForMIDs give absolutely no preference to Windows.

You're right.  Maybe we should have a separate newdict.html for Windows users and a separate one for Linux/Unix users?  I'm sorry, I only use Windows so I wouldn't be able to write instructions for Linux.  How do you guys build dictionaries on your machines (what is the equivalent of setup.bat and  jar.bat)?

Thanks a lot for your suggestions
Jeff

I worked a little on making the newdict.html file easier to follow for new people.  I think people have 2 main problems when they try to make a new dictionary: setting up their build environment, and writing a DictionaryForMIDs.properties file.

So I thought we should put all the tools needed into 1 file that people can download.  I put these tools together:
DictionaryForMIDs.jad
DictionaryForMIDs.jar
DictionaryGeneration.jar
JarCreator.jar
fontgenerator.jar

I also created the necessary directories and made DOS batch files to run DictionaryGeneration and JarCreator.

I put a test version of the build environment here http://prdownloads.sourceforge.net/dictionarymid/DictionaryForMIDs_3.5.0(beta1).exe?download.

Then I changed the newdict.html file a little to be easier to read.  I think the main difficulty for people was reading the technical details of the DictionaryForMIDs.properties file.  So I moved the details to a new newdictProperties.html file.

I also moved the details of DictionaryGeneration to newdictDictionaryGeneration.html and the details of JARCreator to newdictJARCreator.html.

What do you guys think?  Is this a good idea or not?  It'd mean a big change on how we release new versions.  For example, if we make a new version of DictionaryGeneration.jar, then we'd have to repackage all the other old files together and re-post it to the File Manager.  If we did that we change the version number from 3.5.0 to 3.5.1, for example.  Changing DictionaryForMIDs.jad & .jar would change the version number from 3.4.0 to 3.5.0, for example.

I wrote the instructions for Windows.  I'm guessing many people who would want to make a dictionary would be using Windows.  I'm thinking most people who run Linux would understand computers enough to change the build environment to meet their needs.  I'm not sure about people on a Mac or anything else.

Jeff

There is a small bug in DictionaryGeneration regarding UTF-8 files.  I like to save all files as UTF-8.  But, when DictionaryForMIDs.properties is saved as UTF-8, DictionaryGeneration gives an error.

The error is about the byte order mark (BOM) saved at the beginning of the DictionaryForMIDs.properties file.
http://en.wikipedia.org/wiki/Byte_order_mark

When I run DictionaryGeneration, I get this error:

Thrown de.kugihan.dictionaryformids.general.DictionaryException: Property infoTe
xt not found / Property infoText not found

infoText is the first item in DictionaryForMIDs.properties, therefore it gives the error.

In UTF-8, U+FEFF is stored as EF BB BF.  So, in DictionaryGeneration, would it be possible for it to ignore EF BB BF at the beginning of the file?

An easy work-around is to add a line break at the beginning of DictionaryForMIDs.properties.  But, new people trying to build a new dictionary might not know that.

Jeff

Thanks for the fix.  Everything works OK now.

Jeff

I am having trouble building the Esperanto-English dictionary using version 3.5.0.  When I use JARCreator 3.4.0 I get an error message about not finding NormationEpo.  I looked inside DictionaryForMIDs.jar for version 3.5.0 and I see NormationEpo.class in the folder.  I'm not sure why JARCReator wouldn't see the file.  I don't think we need a new version of JARCreator, do we?

Here is the error message:

Thrown de.kugihan.dictionaryformids.general.DictionaryClassNotLoadedException: C
lass could not be loaded: de.kugihan.dictionaryformids.translation.normation.Nor
mationEpo / Class could not be loaded: de.kugihan.dictionaryformids.translation.
normation.NormationEpo

de.kugihan.dictionaryformids.general.DictionaryClassNotLoadedException: Class co
uld not be loaded: de.kugihan.dictionaryformids.translation.normation.NormationE
po
        at de.kugihan.dictionaryformids.dataaccess.DictionaryDataFile.getObjectF
orClass(DictionaryDataFile.java:305)
        at de.kugihan.dictionaryformids.dataaccess.DictionaryDataFile.initValues
(DictionaryDataFile.java:256)
        at de.kugihan.dictionaryformids.general.UtilWin.readProperties(UtilWin.j
ava:36)
        at de.kugihan.jarCreator.JarCreator.buildApplicationUniqueIdentifier(Jar
Creator.java:227)
        at de.kugihan.jarCreator.JarCreator.main(JarCreator.java:61)
Exception in thread "main" de.kugihan.dictionaryformids.general.DictionaryClassN
otLoadedException: Class could not be loaded: de.kugihan.dictionaryformids.trans
lation.normation.NormationEpo
        at de.kugihan.dictionaryformids.dataaccess.DictionaryDataFile.getObjectF
orClass(DictionaryDataFile.java:305)
        at de.kugihan.dictionaryformids.dataaccess.DictionaryDataFile.initValues
(DictionaryDataFile.java:256)
        at de.kugihan.dictionaryformids.general.UtilWin.readProperties(UtilWin.j
ava:36)
        at de.kugihan.jarCreator.JarCreator.buildApplicationUniqueIdentifier(Jar
Creator.java:227)
        at de.kugihan.jarCreator.JarCreator.main(JarCreator.java:61)


Version 3.5.0 works fine with the English-Japanese dictionary.

Sorry, I tried to upload the source files I used to here.  But the limit size for attachments is 128kb.  So I just uploaded the DictionaryForMIDs.properties file.  Maybe try to build any dictionary file with that DictionaryForMIDs.properties file and see if you get the error.  If it's not possible to reproduce the error, I can e-mail the full source files.

Jeff

1) This means that DfM for general (for example european) J2ME phones cannot support search in any non-roman script at all, right?

Correct.

2) But there must exist chinese/japanese/greek phones with J2ME. Doesent these phones have a J2ME implementation installed that allows users to enter chinese/japanese/greek characters? Or is it like, chinese/japanese/russian can be typed in e.g. SMSes but is not available in J2ME applications?

Sorry, I should be more specific.  I should have written: you cannot search in a non-roman language unless your phone has a custom IME (Input Method Editor) for that language.

If you have a phone from a country that has a non-roman script, then the phone will have a custom IME to type in that language.  For example, if you live in Russia, then you will have a phone that can type in Russian.  Then you can search Russian -> Esperanto in DictionaryforMIDs.

But, if you live in Europe (or any other country with a roman script language), then your phone will not have a Russian IME.  You will not be able to search from Russian -> Esperanto.  You will only be able to search from Esperanto -> Russian.

So DictionaryforMIDs would need some code to create a custom IME that would allow us to type in any language that we want.

For example, in English if you press "2" once you get an "a".  If you press "2" twice, you get a "b".  We'd need some code to be able to change the letters you get.  For example, in Japanese, if you press "2" once you get an "ka".  If you press "2" twice, you get a "ki", etc.

3) Why dont I need a Chinese Normation class? I see the Japanese normation class is transliterating.

The Chinese dictionary does all the transliteration in the DictionaryUpdate class.  The Japanese dictionary does all the transliteration in the Normation class.  The Chinese dictionary is setup well.  I'd like to setup the Japanese dictionary the same.  But, until we can get the custom IME code I have to use the Normation class.

The Japanese dictionary makes searches 2 times slower than other dictionaries. When people press the search button, the dictionary searches first in hiragana (1 Japanese script), then it uses the Normation class, then searches a 2nd time in katakana (a 2nd Japanese script).  If I could use a DictionaryUpdate class, then there'd only be 1 search.

typing of chinese letters is done .... how?

Chinese is typed using transliteration too.

Jeff

5) The non-Latin languages are not tested very well. Ive done my best but I don't know how to enter e.g. Chinese or Japanese characters, and I am not sure it everything is OK here (assistance needed! :-)
I set the normation class, eg in eo-jp I have:
language2NormationClassName=de.kugihan.dictionaryformids.translation.normation.NormationJpn
is that enough or is there more to do?

Hi Jacob, for the Japanese dictionary, also use a DictionaryUpdate.  You can use the same one as the EDICT Japanese dictionary:

language2DictionaryUpdateClassName: de.kugihan.dictionaryformids.dictgen.dictionaryupdate.DictionaryUpdateEDICTJpn
language2NormationClassName: de.kugihan.dictionaryformids.translation.normation.NormationJpn

For the Chinese dictionary, use a DictionaryUpdate too.  You don't need a Normation class, though:
language2DictionaryUpdateClassName=de.kugihan.dictionaryformids.dictgen.dictionaryupdate.DictionaryUpdateCEDICTChi

For all the non-roman languages, you won't be able to search the non-roman language.  You'll only be able to search from Esperanto.  For example, you can only search Esperanto -> Russian or Esperanto -> Hebrew.  You can't search from Russian -> Esperanto or Hebrew -> Esperanto.

We're still waiting for someone to write the code to add a custom text input box for DictionaryforMIDs.  This would allow inputting languages which use non-roman scripts.  Here is a link to the discussion:
http://dictionarymid.sourceforge.net/forum/index.php?topic=52.0

Jeff

Huong

I fixed the Japanese dictionary.  づ ("du") and ぢ ("di") work correctly now.  Sorry, it took a little longer to fix than I thought.

Jeff

The version 3.5 files worked good.  Thanks for building them.  The errors with the version 3.4 files were strange.  Oh well.

Jeff

Gert

Can you please help me with 2 things?

1. Can you add these 2 files to the next version 3.5.0 of DictionaryForMIDs.jar\char_lists?

2. I want to manually add the new files to the current 3.4.0 version of DictionaryForMIDs.jar and release a version 3.4.0 of the Japanese dictionary.  But I get an error.

I removed the old files and added the new files with WinRAR.  Then I changed the MIDlet-Jar-Size in DictionaryForMIDs.jad to the new JAR file size.  But I get this error when I run JarCreator:

Exception in thread "main" java.util.zip.ZipException: invalid entry compressed
size (expected 1945 but got 1947 bytes)
        at java.util.zip.ZipOutputStream.closeEntry(Unknown Source)
        at java.util.zip.ZipOutputStream.putNextEntry(Unknown Source)
        at java.util.jar.JarOutputStream.putNextEntry(Unknown Source)
        at de.kugihan.jarCreator.JarCreator.writeJAR(JarCreator.java:176)
        at de.kugihan.jarCreator.JarCreator.main(JarCreator.java:83)

I get the error with version 3.1.2 and 3.4.0 of JarCreator.  I tried WinRAR and WinZip to add the files.  Both programs created the same filesize for the JAR file.  I remember I manually added the files a couple years ago, but I forgot what I did.  What mistake am I making?

Thanks
Jeff

Gert

I tested the new DictionaryGeneration with the Hindi and Thai dictionaries.  Everythings works OK.  Thanks for adding the code.

Jeff