Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - Gert

Pages: [1] 2 3 ... 7
1
Open Talk / Hack of this forum (31th May 2019)
« on: 02. June 2019, 10:35:44 »
For information of forum users:
On May 31, 22:20 o'clock (CEST), this forum site was hacked (even with an up to date web server and forum software).
Many PHP files were manipulated (mostly advertising should be displayed while visiting the web site). But the manipulation created invalid PHP code, so in most cases the web server never delivered the forum site.

A backup of all files from Thursday to Friday night was restored, all manipulated files were overwritten by doing this. The forum database was not changed after comparing with an older backup. Forum posts are not lost, everything is back.

We don't know, if any information was read from the database. If this was done, so user passwords are not in immediately danger, because they are saved hashed and salted in the database. But it could be possible that the forum users' email addresses are known to the attacker.

---

Many thanks to our excellent forum administrator Stefan, who quickly reacted to this incident!!

Gert







2
General discussions / Some Web Page cleanup ongoing
« on: 12. December 2015, 08:12:55 »
I am currently doing some cleanup on the web pages.

Will inform you about the progress.

Regards,
Gert

3
Problems / DfM WebApp on Windows Phone 8.1
« on: 19. July 2014, 07:25:56 »
We did receive a report, that on a Windows Phone 8.1 there is a message that the html5 overideMimeType is not supported. This message does mean that the dictionary files, which are locally stored on the device in the html5 application cache, cannot be read, i.e. translations will not work.

The DfM WebApp runs nicely since version 11 of the Internet Explorer; Internet Explorer versions prior to 11 (e.g. Internet Explorer 9 and Internet Explorer 10) had a poor support for HTML5 and the DfM WebApp does not run on those older Internet Explorer versions.

What version of Internet Explorer is running on Windows Phone 8.1  ?

Regards,
Gert

4
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.

5
General discussions / DictionaryForMIDs icon in SVG format
« on: 01. November 2013, 04:47:50 »
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

6
General discussions / DictionaryForMIDs publishing for WebApps
« on: 31. October 2013, 16:42:31 »
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

7
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

8
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

9
General discussions / DfM JavaME 3.5.9 for testing
« on: 05. October 2013, 20:01:49 »
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

10
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  8)

Best regards,
Gert

11
Colleagues,

we had a cumbersome defect in our DfM SVN repository data. The Sourceforge team thinks this may have the result of writing to the  repository via https.

For this reason, if you have write access to the DfM SVN repository, please use only "svn+ssh":

svn+ssh://username@svn.code.sf.net/p/dictionarymid/code

Best regards,
Gert

12
Colleagues,

there has been some confusion about the SVN repository location since the upgrade of Sourceforge software.

As part of the Sourceforge software upgrade the SVN repository was moved to this location:
read-only access: http://svn.code.sf.net/p/dictionarymid/code
[https is discouraged - see other posting] read-write access: https://svn.code.sf.net/p/dictionarymid/code/ or
read-write access: svn+ssh://username@svn.code.sf.net/p/dictionarymid/code/

See also here: http://dictionarymid.sourceforge.net/SVNRepositoryAccess.html

More information on accessing svn on sourceforge is provided here: https://sourceforge.net/p/forge/documentation/svn/

Web access address is https://sourceforge.net/p/dictionarymid/code/HEAD/tree/trunk

Unfortunately the old repository is still active and accepts commits; I will make a support request to Sourceforge to set it readonly.

Beginning of this week I did merge all commits that were made to the old repository since the Sourceforge SW update into the new repository; so all files are now in the new repository.

Just contact me in case of questions.

Best regards,
Gert

13
DfM-Creator - general / DfM-Creator 0.6 beta available
« on: 05. March 2013, 17:02:24 »
DfM-Creator 0.6 beta is available from our web server: http://dictionarymid.sourceforge.net/.

Please send feedback directly per email to Karim ( dfmcreator (a) gmail.com )

Regards,
Gert

14
Colleagues,

this DfM forum is now located at http://dictionarymid.sourceforge.net/forum/index.php (before it was at http://dictionarymid.german-fighters.com). Thanks to Stefan for moving the forum here !!

Now the forum shall stay at this location forever :)

If you still have a bookmark to the olf location, please update your bookmarks to http://dictionarymid.sourceforge.net/forum/index.php.

Currently, within existing forum postings, the links to other forum postings still point to the old location. Stefan plans to update this during the next days.

With best regards,
Gert

15
General discussions / Firefox OS also supported
« on: 20. December 2012, 20:16:18 »
I just tested the DictionaryForMIDs WebApp with the Firefox OS simulator: runs fine there !

Here is the webapp file for CEDICT:
http://dictionarymid.sourceforge.net/WebApp/dictionaries/dictionary EngChi (CEDICT)/CEDICT.webapp

Hope there will soon be a volunteer who improves our 'mini_hmI' into a nice and complete HTML5 user interface.

Regards,
Gert

Pages: [1] 2 3 ... 7