Messages

It seems that most devices show correct translation results when "coloured display" is switched on. However in the past there had been reports that there are devices where the translations are not correctly shown in the "coloured display".

Can anybody tell us the name of a device which does not show the translation results correctly in the coloured display ? If you have such a device, can you tell us the device name and also the dictionary where you have the problem (if possible tell us the exact file name of the downloaded dictionary) and a word for translation where the problem does show up.

Here under this posting, we want to collect all reports of people about the "coloured display".

To switch on the "coloured display", choose "Settings" from the menu, navigate to "Coloured display" and switch it on. As in the screenshot below. Of course, if you are using DictionaryForMIDs on a non-English device, "coloured display" and "Settings" will be translated to your language (for most parts of the world).

Also, there is a sample screenshot which shows how coloured display looks like; that example is from the English-Japanese EDICT dictionary.

For questions, please ask !

With best greetings,
Gert

P.S.: For any Java developer who would like to do some rework on that topic, please see this posting: http://dictionarymid.sourceforge.net/forum/index.php?topic=421.0.

Uhm, what is U+A78C ? Wikipedia and others tell me that the glottal stop is U+0294.

Regards,
Gert

A word at the beginning: DictionaryForMIDs runs on several platforms, including traditional phones, Android, PCs and modern web browsers.

For dictionaries with non-latin characters, typically an UTF encoding is used for the character set, with UTF-8 being the most frequentl (UTF-16 would be fine, too).

PCs, modern web browsers should be able to display all Unicode characters out of the box; I also would assume this applies to Android. Traditional phones (= Java ME technology) usually are not capable to display all Unicode characters; for this reason DictionaryForMIDs supports the bitmap fonts on Java ME. Bitmap fonts allow to display on traditional phones all characters of a dictionary even if this is not directly supported by the traditional phone.

The Java language supports the Unicode characters. I just looked up, the Unicode code for the glottal stop is U+0294, there seems to be an U+02C0 variant and some others.

After that long explanation: can you post your inputdictionaryfile, or an extract from it, plus the file DictionaryForMIDs.properties  and also the complete generated JAR file (or post a link to where I can donwload it) ? And please point to a section where that glottal stops occurs ?

Gert

Fine !

When you are done with setting up your dictinonary, would it be possible that you send it to Stars Soft (see http://dictionarymid.sourceforge.net/contact.html) for publishing on our web site ?

Regards,
Gert

Yes, choose the right Normation class, it will handle upper/lower case for searching.

Probably for English you should use NormationEng, for German use NormationGer, e.g.:

Code Select Expand

language1NormationClassName: de.kugihan.dictionaryformids.translation.normation.NormationEng
language2NormationClassName: de.kugihan.dictionaryformids.translation.normation.NormationGer


If this does not solve the problem, please print the exact error message.

Regards,
Gert

I guess, Gert will expand DfM webApp to support more than 2 languages.

Ha, I already spent much time on the OptionWindow, cause I am really not familiar with development of HTML/Javascript ... and I have such a long todo list with other pressing items 


Besides, the DictionaryForMIDs WebApp is also even running on the Wii U, it looks very nice there too 

Regards,
Gert

Achim,

I added the member translationParametersObj to the class TranslationResult.

Does that solve your information need ... ?

Regards,
Gert

Hallo Achim,

- Does executeTranslationBatch() honor parameters.isExecuteInBackground or is this flag ignored and translation always runs in background?

Yes, this parameter is evaluated (for Java; not for Javascript); if set to false, no new thread is spawned. Uhm, at least that's what it is supposed to be ... is there a problem with that ?

- Is there a way to find out according to which TranslationParameters of the given batch the callback newTranslationResult(resultOfTranslation) is returning? I'd need this information to have a grouped view of the results, ie. output "English -> German" and the results, then "German -> English" and the corresponding results.

Hmmm, I think that is not possible. I will implement that !


Keep asking !!
Gert

Good news: thanks to the support of V.P. Guru, the OptionWindow is now operable !

I just updated the mini_hmi on the web server. It is now possible to select the translation direction on the mini_hmi user interface.

One restriction: only 2 language dictionaries are currently supported by the OptionWindow.

Thanks to V.P. Guru !
Gert

I recreated the WebApp dictionary files with a corrected script, so the files are ok now.

No problems should show up for any translation. If you find that the WebApp does any translation incorrectly, or if there is even an Exception message, please report !

Regards,
Gert

The directory stucture is great !

I completed the scripts, see here: http://dictionarymid.sourceforge.net/WebApp/htdocs/WebAppCreateDictionaries.html

Deviating from my proposal above, createWebAppFiles.sh does not take an -all command line argument. Instead, in order to create all WebApp dictionaries, the script createAllWebAppFiles.sh is used.

Regards,
Gert

I just tested with Internet Explorer 10: even not Internet Explorer 10 does provide sufficient HMTL5-capability ! The WebApp Translation Layer does report this problem during startup. Translations will not work with Internet Explorer 10.

According to the Microsoft documentation the Internet Explorer version 11 will work.

Regards,
Gert

It is _very_ useful that you could test it on so many browsers !

I do have to make a restriction, though, on IE8: the WebApp Translation layer uses several HTML5 features; IE8 does not support HTML5; I believe also IE9 has some limitations in HTML5 capabilities.

Means Internet Explorer 8 will not run the DictionaryForMIDs WebApp, possibly Internet Explorer 9 neither.

I uploaded a new version of the WebApp Translation layer. That version checks the availability of the needed HTML5 freatures during startup. If something is missing, then this is reported in an alert box.

Best regards,
Gert

Colleagues,

we now have the DictionaryForMIDs logo in SVG format (vector format), see attached. 1x Inkscapeformat, 1x normal.

Thanks to  J.i.M. (für Just in Motion) !

With best greetings,
Gert

Colleagues,

here is a description how the publishing of WebApps works currently.

First, for general information: the WebApp uses the files that are contained in the dictionary JAR files, so say it more precisely, the files that are in the "dictionary" path of the JAR file. Those files need to be accessible from the Sourceforge web server. The WebApp uses the HTML5 "Application Cache" feature to download each of the dictionary files into the browser. When the user selects the URL for a dictionary, then the browser automatically downloads all the dictionary files and from that point on that dictionary is available for offline use. That means, also without an internet connection, when the user selects the URL for the dictionary, then the WebApp will start with the offline loaded dictionary.

For each dictionary the dictionary JAR file is extracted (dictionary path only) and stored at /home/project-web/dictionarymid/htdocs/WebApp/dictionaries.

The dictionary subdirectory is named as the corresponding directory in the File Release System. For example, the name for the CEDICT dictionary is "/home/project-web/dictionarymid/htdocs/WebApp/dictionaries/dictionary EngChi (CEDICT)".

Extracting the files from the dictionary JAR plus establishing links for the WebApp, including application cache manifest files, PHP files and htaccess file is done by the shell script createWebAppFiles.sh. See here:
http://svn.code.sf.net/p/dictionarymid/code/trunk/WebApp/Tools/CreateWebAppFiles/createWebAppFiles.sh
[note: at the time of writing this posting, that script is not functional; I will update it following the input of Stars Soft]

The shell script createWebAppFiles.sh must be executed from the Sourceforge shell service. I.e. at the Linux command prompt available at shell.sourceforge.net.

createWebAppFiles.sh does walk through each of the directories at /home/frs/project/d/di/dictionarymid. Each directory has a subdirectory with a version number. The script createWebAppFiles.sh picks the subdirectory with the highest version number. The zip file in that directory is unzipped and the containing dictionary JAR is extracted (path dictionary).

Dear Stars Soft, I have a question, is this structure implemented for all dictionaries (the names in < and > are placeholders):
<dictionary name>/<dictionary version>/<dictionary>.zip
?

If yes, I think then we could keep the current script approach; I probably will update the script so that it takes a command line argument:
"-all": create WebApp files for all dictionaries at /home/frs/project/d/di/dictionarymid
"<dictionary name>": create WebApp files only for the dictionary with <dictionary name> at /home/frs/project/d/di/dictionarymid

Then, when <new_dictionary> it published and uploaded to the FRS the following command needs to be run:

createWebAppFiles.sh  <new_dictionary>

That's all - the script will create all files for the <new_dictionary> WebApp. It will automatically be available to users at http://dictionarymid.sourceforge.net/WebApp/dictionaries/<new_dictionary>

Dear Stars Soft, what is your opinion on that ?

If that is ok, then I will update the script createWebAppFiles.sh so that it works and handles the command line parameter.

With best greetings,
Gert





Destination