This is the very first release of the htmlApp ! Well, actually only the Javascript for Translation Layer is complete. We still need to find someone who is implementing a nice HTML user interface. Who likes to create a nice HMTL file for the htmlApp ?
Anyway, here are 2 dictionaries for testing:
IDP EngLat: http://dictionarymid.sourceforge.net/htmlApp/EngLat_IDP/ (http://dictionarymid.sourceforge.net/htmlApp/EngLat_IDP/)
A small dictionary for testing; hard coded translation direction: Latin to English (you can search for example for the word amor)
CEDICT: http://dictionarymid.sourceforge.net/htmlApp/ChiEng_CEDICT/ (http://dictionarymid.sourceforge.net/htmlApp/ChiEng_CEDICT/)
The famous huge CEDICT; hard coded translation direction: English to Chinese.
The current HTML user interface is for testing only (I call this test HTML 'mini_hmi').
Please only test these applications if you have an internet 'flatrate' (i.e. you do not pay for downloading files) !
When you enter one of the URLs above, maybe your internet browser will ask you if you want to install the application (depends on the browser). Then the complete dictionary will be downloaded and be available for offline use. I.e. once downloaded you do not need the internet access for using the dictionary.
In the htmlApp the "Cache Info"-button will open a popup where the 'cache events' are logged. During an active download there will be new 'progress' entries; at the end there will be the 'cached' status if things are fine. Or an 'error' status if something went wrong.
If you open the application after downloading and then press the "Cache Info"-button, then there should be an 'Application Cache Status' of 1 (= "idle"). A value of 0 would indicate "uncached".
Some notes concerning the various internet browsers:
- Firefox: everything should run fine on version 4 (still in beta). Version 3.6 seems to have problems when more than one dictionary is in the application cache.
- WebKit based browsers (e.g. Apple Safari, Google Chrome, Samsung Dolfin, and most other mobile browsers): the WebKit developers explained that WebKit does not yet have a handling for the size of the 'Application Cache'; temporarily the size of WebKit's Application Cache is hardcoded [Gert: I believe the limit 5 MB]. For that reason, the huge CEDICT will not work as an offline dictionary. Hope that this gets fixed in WebKit very soon.
- Microsoft Internet Explorer: does not work for Internet Explorer version 8 (cause Application Cache is not supported and XMLHttpRequest.overrideMimeType is not yet implemented); Internet Explorer version 9 may support this - can somone test ?
- Opera: Can someone test this ?
Ok, hope there will be a lot of testers - I am keen to read your test results !
Best regards,
Gert
Hi Gert,
I tried the Latin-English version a few days ago on Android 2.2 (HTC Dream): It was working fine! The search for amor was quite fast but the search for am* took some time. Impressive though!
Right now I wanted to try the English-Chinese dictionary but only received the attached errors.
-Achim
Achim,
thank you very much for your test !! :)
About your problem with CEDICT:
1. I made tests with a few WebKit-based browsers: all of them show the problem that you describe.
2. From the output that Google Chrome provides, it seems to me that something goes wrong when one of the files is extracted from the application cache (the problem occurs with the Translation Layer Javascript files, these are part of the application cache for EngLat_IDP and for ChiEng_CEDICT). Seems the wrong 'application cache group' is chosen by the WebKit browser, which then later results in a breach of the 'same origin' policy for reading the file DictionaryForMIDs.properties.
3. I tend to believe that this is a WebKit bug; but I need to deeper dig into that before I submit a bug report to the WebKit team.
If you delete all your caches in your browser, then open CEDICT again, then this error should not appear again. [it would appear again if CEDICT is successfully loaded in the application cache and then you open EngLat_IDP].
But worse ... I found a second problem that shows up with the WebKit browsers: if your translation happens to hit the file directory1.csv, then there will be the message "Invalid UTF8 sequence". There seems to be a problem with handling the UTF-8 BOM in that file (at least there). Guess this time it is not a WebKit bug.
For this second problem there is a clean way to solve it; however this will require quite some changes; need to figure out more there.
Well, most of all thank you for testing !!!
Gert
So ... I had been working hard on those two problems:
First: About the problem with "Exception bei XMLHttpRequest":
I submitted a bug report at the Google Chromium folks: http://code.google.com/p/chromium/issues/detail?id=68479 (http://code.google.com/p/chromium/issues/detail?id=68479). They acknowledged the bug ("This is a good bug") :) . Let's see when this bug gets fixed in the affected browsers.
Second: "Invalid UTF8 sequence":
I implemented a better 'standard'-conforming way to read the dictionary files, using XMLHttpRequest.responseBlob. However it turned out that the WebKit team just implemented this feature a few months ago and I guess there is hardly any released WebKit based browser that supports XMLHttpRequest.responseBlob. For example the latest beta of Google Chrome does not yet support that. So I will postpone that feature for a while.
Ok, so now I will have to stop my development activities on the htmlApp for a while (due to other tasks). In any case I will still be able to actively support when there are questions on the htmlApp.
Regards,
Gert
can we implement Jquery for translation Layer?
Quotecan we implement Jquery for translation Layer?
Yes, it it possible to use JQuery, for the User Interface Layer (the Translation Layer itself is generated via Google's Web Toolkit). You also can read and support here: http://dictionarymid.sourceforge.net/forum/index.php?topic=278.0 (http://dictionarymid.sourceforge.net/forum/index.php?topic=278.0)
Gert
Just tested both with Opera 11.10 (Windows version), works with and without cache.
QuoteJust tested both with Opera 11.10 (Windows version), works with and without cache.
That is a good information - thanks for testing !
Gert
Did new tests with current browser versions:
Internet Explorer 9 (Windows): Don't work
Opera 11.51 (Windows): Works
Opera Mobile 11.10 (Android): Works, but sometimes error messages while loading property file
Firefox 7.0.1 (Windows): Works
Chrome 14 (Windows): Works
Did new tests with Opera 12.13 (current version): Works still great with most dictionaries, but sometimes reloading page after first visit might be needed to get it working.
Some dictionaries throw an exception like this:
http://dictionarymid.sourceforge.net/WebApp/dictionaries/dictionary%20EngGer%20(freedict)/
<dictionarymid.sourceforge.net>
Thrown de.kugihan.dictionaryformids.general.CouldNotOpenPropertyFileException: Property file could not be opened: DictionaryForMIDs.properties / Property file could not be opened: DictionaryForMIDs.properties
Gert,
The appcache "XMLHttpRequest.responseBlob" error has not been resolve by chorme. They suspend the actions against your bug report. Please, get into that thread and follow it up for us.
https://code.google.com/p/chromium/issues/detail?id=68479 (https://code.google.com/p/chromium/issues/detail?id=68479)
Even today i'm getting the same error with Chrome Version 29.0.1547.76 m
QuoteEven today i'm getting the same error with Chrome Version 29.0.1547.76 m
That problem was resolved in previous versions of Chrome. Did it creep in again ? Ok, I will check that.
Regards,
Gert
Heck, yes, I confirm, that Chrome bug does show up in the current Chrome version again ! Was fixed for older versions.
I will try to get it fixed by the Chrome developers again.
Thanks for pointing at that problem !
Workaround is to delete the application cache prior to loading another dictionary with Chrome (see chrome://appcache-internals/).
Regards,
Gert
I just now upgrade chrome to Version 30.0.1599.66 m and cleared the caches, now its working fine without any appcache problem. if we load more no. of dictionaries, then we suppose to clear cache to avoid appcache error.
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
Thanks for the list of dictinonaries that seem to have a problem with loading the Normation class - that is really helpful. I will look at that once I am finished with the "multiple dictionaries" feature.
I spent some time about that Chrome bug: it seems it is not exactly the same as it was in the old versions; seems the bug only shows up when the WebApp is executed but the appcache is not yet filled; I need to spend more time there to better narrow down when the problem shows up and when not.
Thank you very much for your hints ! I will work on that ... one after the other.
Gert
QuoteAnd 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
Gert,
I've tested webApp with EngLat (IDP) dictionary. The translation layer is working perfectly with chrome.