Messages

So this answer should be read as an "OK" from my side

This makes me happy

I still need to spend some time on testing, then I will commit the updates to the SVN repository.

With best greetings,
Gert

Achim,

I am currently implementing in class TranslationExecution

   void executeTranslationBatch(TranslationParametersBatch translationParametersBatchObj)

Basically a TranslationParametersBatch is a Vector with TranslationParameters elements.

This will allow to have one call to TranslationExecution and get the translation results for several dictionaries.

I plan to implement an own thread per dictionary translation. E.g. 5 dictionaries -> 5 threads running in parallel (I will have to rework threading and thread synchronization in any case, cause I plan support for Javascript web workers).

When the first dictionary translation is done, then a call to deletePreviousTranslationResult() will be done; subsequently newTranslationResult(resultOfTranslation) will be called for each dictionary.

Ok for you ? ... a simple posting with "OK" is enough 

Best regards,
Gert

Hope that one day we will have a documented "regression test procedure". That is a list of test steps that we will apply each time before we release a new version. Only if all test steps are successful, then we will assume that there has not been any regression (i.e. no new bugs).

Well, for the time being, I think 3.5.9 should be ready for release with any dictionary.

Best regards,
Gert

That information on JSR75 permissions is very useful !

Gert

Fresh from the compiler here is DfM JavaME 3.5.9 for testing purposes: http://www.kugihan.de/dict/download/test_versions/3.5.9/DictionaryForMIDs_3.5.9_final_empty.zip

The only new feature is the Tamil translation.

Additionally there is an internal change: the use of the 'multiple dictionary' capable translation layer.

Any testing is welcome.

Best regards,
Gert

Achim,

wow - quick reaction !!

When I was first thinking about the topic the first idea was to remove the static methods

I was doing that for the class DictionaryDataFile (removing the static fields/methods), so now there is one instance of DictionaryDataFile per dictionary.

Where I'm not sure now is how multithreading is working now. Will there be multiple calls providing results? Or do they come in a batch once? Does it work in synchronous mode or only in asynchronous mode?

You hit the interesting point ! I was thinking quite a bit about how to do this. Finally, I did favour the presented solution, because there is only rather limited impact on the interface.

Let me explain: multithreading works as it did before. That means that a call to TranslationExecution.executeTranslation with executeInBackground will start a new thread that executes the translation. If you should do another call to TranslationExecution.executeTranslation before the previous translation completed, then that would interrupt the previous translation and start a new translation thread (this can happen for example with incremental search, where the user extended an expression before the translation results of the previous translation were there).

In order to run a translation over several dictionaries, you will have to run them one after the other. Each time when newTranslationResult is called, then the next translation can be executed.

Optionally, we could think to have an additional TranslationExecution.executeTranslationBatch where a list of translation jobs is passed in. Hmmmm, then TranslationResult could not carry the field dictionary, cause a TranslationResult would have several SingleTranslation each with a field dictionary. Guess that would not be hard to implement.

Hmmmm, or for a list of translation jobs there would be a list of TranslationResult, each for a separate dictionary (then the field dictionary in TranslationResult would be ok). Hmmmm, what are your ideas on that ?

With best greetings,
Gert

I already did adapt Java ME and Java SE to the new interface. I did not yet commit the changes to the SVN repository before I receive an 'OK'.

Here are a few hints for converting:

Old was:
FileAccessHandler.setDictionaryDataFileISAccess(dfmInputStreamObj);
DictionaryDataFile.initValues(false);

New is:
dictionary = TranslationExecution.loadDictionary(dfmInputStreamObj);


Updated is the access for the dictionary properties.

Old was (sample):
numLang = DictionaryDataFile.numberOfAvailableLanguages;

New is:
numLang = dictionary.numberOfAvailableLanguages;  // dictionary is returned from TranslationExecution.loadDictionary


And
Old was:

TranslationParameters translationParametersObj =
                  new TranslationParameters(addSearchCharacters(word),
                                          inputLanguages,
                                          outputLanguages,
                                          executeInBackground,
                                          DictionarySettings.getMaxHits(),
                                          DictionarySettings.getDurationForCancelSearch());


New is (new first parameter dictionary):
TranslationParameters translationParametersObj =
                  new TranslationParameters(dictionary,
                                          addSearchCharacters(word),
                                          inputLanguages,
                                          outputLanguages,
                                          executeInBackground,
                                          DictionarySettings.getMaxHits(),
                                          DictionarySettings.getDurationForCancelSearch());

Gert

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

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

Even 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

[static DictionaryDataFile]

Colleagues,

for years there had been no change of the interface to the Translation Layer - now there is one ! For the support for multiple dictionaries.

Until now, as a restriction, the Translation Layer only did support one dictionary at a time; this restriction came from the fact that information about the dictionary was stored in static fields of class DictionaryDataFile. I am currently updating the Translation Layer to work with several instances of DictionaryDataFile. This results in a few interface changes:

New in class TranslationExecution:
static DictionaryDataFile loadDictionary(DfMInputStreamAccess dictionaryDataFileISAccess);
static void               unloadDictionary(DictionaryDataFile );


The constructor of class TranslationParameters is extended with new first parameter dictionary:
TranslationParameters(DictionaryDataFile dictionary,
                      String             toBeTranslatedWordTextInput,
                      boolean[]          inputLanguages,
                      boolean[]          outputLanguages,
                      boolean            executeInBackground,
                      int                maxHits,
                      int                durationForCancelSearch)


TranslationResult.dictionary does indicate from which dictionary the translation was retrieved.


Removed will be the following:

Removed in class DictionaryDataFile:
initValues(boolean)

Removed class FileAccessHandler (complete class)



Changes required in the HMI Layer: [/font]

   
• the HMI Layer will have to use the return value of TranslationExecution.loadDictionary instead of the global DictionaryDataFile. This change can mostly be done by "search&replace" in the code.

Is this update ok ?? Or are there serious complaints ?


I myself plan to update the code for Java ME, Java SE,  DfM-Creator and WebApp mini-hmi. Achim, would that be possible that you update Android ? Actually, I think, the adaptation should be possible in one or two hours ... hope so 

I assume that this will be the last change of the interface to the Translation Layer for the next 15 years 

Best regards,
Gert

i have extracted the dictionary in the  src folder and can be detected by the device

Does that mean that you downloaded the source code, compiled it and installed the app on a device ?

but when i try to translate it returns the same word.i have tried for different dictionaries and returns the same.

Did you modify the source code ?

Regards,
Gert

Is there any interest in further development?

There is HUGE interest in further development !!! In my personal opinion the DictionaryForMIDs WebApp will be the most important platform for the future (well, probably second to Android ...).

I'm Front-end developer and can handle HTML/CSS/JS part.

That's what we search for !!
We have information for development of the front-end here: http://dictionarymid.sourceforge.net/WebAppDevelopment.html
And of course, we can help in case of any questions !

So ... if you want build one of the most important parts for mankind ... then just go ahead and implement the DictionaryForMIDs WebApp front-end

With best regards,
Gert

Well, we can help with the world's best dictionary application - which is DictionaryForMIDs ;-)

For others, a good developer will have a support forum too. Did you try to contact the developer ?

Gert

DictionaryForMIDs is not MSdictviewer.