Messages

Colleagues,


We have 4 DfM implementations that we support

   
• Java ME: for the huge number of traditional mobiles, still frequently sold in developing countries, in other countries rapidly replaced by smartphones
• Java SE: for classic desktop systems, e.g. Microsoft Windows, Linux
• Android: the shooting star for smartphones and tablets; crucial for the future of DictionaryForMIDs, cause among those users who are using DfM the Android users probably will have the biggest share (well, that is my guess).
• upcoming: WebApp: for iPhone, Windows Mobile, FirefoxOS, Tizen, and the rest; (besides, also runs on Windows, Linux, Android)

For dictionary publishing:

   
• Java ME: App is included in the dictionary JAR file; OTA download still not implemented (big problem, cause most owners of  Java ME mobiles do not know how to download/install an app).
• Java SE: can directly load a downloaded dictionary JAR file
• Android: reference to dictionary JAR needs to be added to 'Android dictionary database' (Achim, what is the right term for this ?)
• WebApp: relies on HTML5 'Application Cache' for offline capability; dictionary JAR file needs to be extracted so that each of the files are accessible via HTTP. I will make a separate posting on this to explain details.

Publishing dictionaries for all these implementations is quite a challenge and an effort:

   
• the dictionary JAR file, packed in ZIP file together with JAD and copyright files, needs to be uploaded to the Sourceforge FRS
• download page needs to be amended (dictxxx.html).
• the dictionary JAR needs to be manually added to the 'Android dictionary database' (Achim it is manually, right ?)
• the dictionary JAR file needs to be extracted for the WebApp (this is done by a shell script; separate posting to explain follows). I guess in the future we also need to provide a line for the WebApp on the download page. Hmmm, any ideas on this ? We should put additional links for the WebApp for each dictionary on the download page, or any other idea ?

Dear Stars Soft, can you do this each time when a new dictionary gets published ?


Let me know your thoughts on this.


With best greetings,
Gert

Currently no testing suggested ...

... uhm, with my shell script to correct that UTF BOM I screwed up the file directory1.csv of several dictionaries. This will result in some strange Japanese characters being displayed.

I will recreate the dictionaries and make a posting when this is done. Until then, please do not complain about Japanese translation results 

Best regards,
Gert

My part of work is pending to release better webApp DfM.  Kindly choose one of UI for improvements.

Hmmmm, really not easy to have a preference. Well, if I would have to state a preference, I think the metro look might be mine.

Gert

And i got "Dictionary class could not be loaded" error message on some dictionaries such as.
1. Ned - Spa (MP)
2. Ned - Por (MP)
3. Ned - Ita (MP)
4. Ned - Ger (MP)
5. Ned - Fra (MP)
6. Ned - Eng (MP)
7. Hil - Eng
8. Ger - Vie
9. German Phone Prefix
10. German Zip Code
11. Ger - Tgl
12. Eng - Cze webz
13. Eng - Def Wordnet
14. Eng - Rom (Var)
15. Eng - Tag - Spa (CAL)
16. Eng - Hin (freedict)
17. Eng - SMS

I just tested with the current version: I did not encounter any bug there. Can you confirm ?

Regards,
Gert

Stars Soft,

I did run a shell script that replaces the BOM-markers in directoryxxx.csv files with 0-bytes (I think only 3 or 4 dictionaries were affected).

So, that "Invalid UTF8 sequence" should be gone - if it still shows up, please make a posting.

Regards,
Gert

Stars Soft,

I just added your new files for the mini_hmi (.css and jquery) to the manifest. Now the dictionaries should all work offline again. May require a prior cache wipe.

Best regards,
Gert

Dear Stars Soft,

that all sounds very promising !

I will look at your proposals; question: would it make sense to let the user choose in an option dialogue ? Well, would that be possible with reasonable effort ? Hmmm, guess that would make things too complicated. No, not good idea, let us choose one.

Meanwhile I am hacking a shell script that replaces those BOM-characters with 0-bytes (really a wild hack, but it should be good as a workaround).

Gert

Click on the option to get sliding effect.  I'm also working with other themes to provide better UI experiance.

Wow - that is great !


Meanwhile I did investigate on that "Invalid UTF8 sequence" error thrown by Chrome: this is not a bug in Chrome. Chrome behaves according to the specification:http://encoding.spec.whatwg.org/#decode. I personally think that specification is strange because when you explicitly tell XMLHttpRequest with overrideMimeType to use a different encoding (that is what the spec says too), then this is ignored later when the browser does parse the file and detects that there is a BOM. (class HTRInputStream, method  readFileJS: http://svn.code.sf.net/p/dictionarymid/code/trunk/WebApp/DictionaryForMIDs_Javascript/Java_for_GWT/src/de/kugihan/dictionaryformids/dataaccess/fileaccess/HTRInputStream.java).

Chrome previously supported XMLHttpRequest.responseBlob. That was removed in one of the past releases. That means that there is no way to synchronously read a binary file from an non-web worker. Binary reads are necessary for the dictionaryxxx.csv files.

I plan to implement web workers. However I tend to postpone this until a GWT version with better and more stable web worker support is released; also this will be quite some effort, cause Javascript web workers do not allow the same as Java threads do. At the side: the GWT team just fixed a bug that I encountered: http://code.google.com/p/google-web-toolkit/issues/detail?id=7088.

So I am searching for a workaround for that BOM problem: when putting a dictionary online for the web app, then we could run a script that replaces the BOM bytes with 0-bytes on all dictionaryxxx.csv files. Hmmm, maybe sed could do this.

Ok, next I will write some explanations how to put a dictionary online for the web app. Then we can discuss the way forward.

Best greetings,
Gert

I updated the mini_hmi with the 'metro' UI and the new WebApp Translation Layer.

I still need to do a lot of testing. Obvious to me are the following problems:

   
• mini_hmi: the Option Window does not work well; I did not spend any time to fix this, cause I think opening a new window for setting options is very old- fashioned and there should be more modern ways of showing options. For example so that the options slide in on a button press. Any volunteers who like to work on that ?
• WebApp Translation Layer: Chrome shows an "Invalid UTF8 sequence" exception when it encounters a csv file that starts with an UTF-8 BOM; it should also read such files as binary data and not try to interpret its content. This is likely connected to this Chrome bug: https://code.google.com/p/chromium/issues/detail?id=174477; I will probably write another bug report. As a workaround we could modify DfM-Creator dictionary generation to throw away any BOM-characters on the dictionary files.

Regards,
Gert

The WebApp Translation layer is adapted too now. I committed the updates to SVN.

This was quite an effort, also due to flaws in GWT.

The updated and extended documentation is here:
http://dictionarymid.sourceforge.net/WebApp/htdocs/WebAppDevelopment.html
http://dictionarymid.sourceforge.net/WebApp/htdocs/WebAppTranslationLayer.html

I still have to resolve a few "todo" points in the documentation.

I also adapted the mini_hmi to the new interface. I deliberately took one of those nice-looking versions from V.P. Guru for this. The result is here: http://svn.code.sf.net/p/dictionarymid/code/trunk/WebApp/Apps/mini_hmi/

I will work on deployment of the updated version next (means: adapting manifest files and putting everything on the Sourceforge server). And I will also update the documentation for this.

Note that right now the updates are not yet ready for testing. One of the reasons is that for the moment I postponed the implementation of web worker support in the Translation Layer and now there is a problem with reading binary data in Chrome (web apps can read binary data, but only in web workers).

Regards,
Gert

I adapted the description at http://dictionarymid.sourceforge.net/development.html.

My next job will be the adaptation of WebApp Translation Layer.

Regards,
Gert

Dear DictionaryForMIDs supporters,

We are searching (still ...) for a Java ME developer who could work to resolve exisiting problems with the class de.kugihan.dictionaryformids.hmi_java_me.lcdui_extension.StringColourItem.

Already some time ago problems did show up on several devices when displaying translation results with "coloured display" (this is done by class StringColourItem; there are other postings in this forum on this topic, you could search in this forum for "StringColourItem").

And also recently we were receiving reports that on some devices the display of the translation result with the coloured display does not work correctly.

So we are searching for a Java developer who is willing to spend time to work on StringColourItem; probably this class needs some fundamental overhaul; so I guess it will take some time to get this implemented and fully tested.

Anyone who can support our project here ? Would be highly welcome 

You find the source here in our Subversion repository: http://svn.code.sf.net/p/dictionarymid/code/trunk/JavaME/src/de/kugihan/dictionaryformids/hmi_java_me/lcdui_extension/StringColourItem.java
For general information on development, see here: http://dictionarymid.sourceforge.net/development.html

And of course, if you need additional information, just make a posting in this forum, we will help !

Best regards,
Gert

Ok !

For me it is really suprising how you achieved that enormous progress in design with relatively few additions with HTML/CSS.

Regards,
Gert

I just commited my updates to SVN:

• DfM-Creator is adapted to the new interface, Karim, you simply need to update from SVN
• Achim, Android will need to be adapted
• Java ME is adapted
• Java SE is adapted
• WebApp: I will need to adapt the WebApp Translation Layer (currently the WebApp Java code will not compile), regenerate the Javascript code, and then adapt the mini_hmi - I will do this after updating the documentation on the web pages

I will update the documentation on the web pages as my next activity, Achim, with the information from the postings above, I believe it should be not so difficult to adapt to the changed interface.

Of course most of all, if there should be any problems or questions, then please ask !

Best regards,
Gert

I am amazed how the HMI looks in your proposals !!

Currently there is an adaptation ongoing for the Translation Layer interface (see other postings in the Developers part of the forum). Once I will have adapted the WepApp Translation Layer, I would like to adapt the mini_hmi. Which of your three versions should I use ?

With best greetings,
Gert