dictionarymaker-devel Mailing List for Dictionary Maker
Brought to you by:
bmcalister,
tfogwill
Menu
▾
▴
dictionarymaker-devel — Developer list - for discussion of topics related to further development of DM.
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
(11) |
Sep
(4) |
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
|
From: Bryan Mc A. <mca...@gm...> - 2009-10-23 07:59:47
|
Dictionary Maker 2.16 beta has been released! The following changes have been included in the latest release: (Get the latest release from https://sourceforge.net/projects/dictionarymaker) New Features: --------------------- - A totally new version of the manual has been created, together with a tutorial document. Bug fixes: --------------- - The cursor behaves more consistently and returns to the correct place. - Ambiguous words' pronunciations are displayed correctly. - Auto and Incremental modes removed until Incremental mode can be fixed. - File > Close menu option works correctly now. - Phonemes with number and special characters load correctly. - Already classified words are no longer displayed to the user. - Changed pronunciations can be saved when the same category button is clicked. It used to be only saved if a different category was clicked. Known issues: --------------------- - The cursor currently disappears after entering a phoneme, and re-appears when the mouse is moved again or when an arrow key is pressed. - The cursor behaviour can be improved further to behave like word-processing cursor.. - The Expanded Phoneme Panel sort order still needs to be alphabetised and resized, and the Word list display needs to track the currently displayed word correctly. - When editing the word list, the edited word is added instead, and the original word is not removed. - Dictionary Importing needs to be made more tolerant of faulty input files. - Sound playback can be improved so that predictions are always sounded fully without sound file stuttering, and sound does not play before the actual pronunciation is displayed. - When projects are closed the wrong log file is used for the next project opened. If Dictionarymaker is exited and restarted the log files work correctly. - Export to semi-colon delimited file currently generates an empty file and needs to be fixed. ====================================================== 2.15 beta release history: Bug fixes: ------------- - The view statistics dialogue now functions correctly. New features --------------- - Words are now marked as belonging to the following categories: Correct, Proper noun, Partial, Foreign, Invalid - Pronunciation is now captured for words that are correct, foreign and proper nouns. - Only correct words are now used to generate G2P rules. ======================================================= 2.15 alpha release history Bug fixes: --------------- - The rule extraction dialogue only appears as long as necessary, and not longer. - The phoneme mapping tool now supports the use of numbers in phonemes. Before the use of this character would result in the mapping tool failing to import the dictionary. - If an unknown phoneme is encountered, it is added into the 'New' category with 'bing.wav' as its default sound. - If phonemes are edited, the expanded phoneme panel now reflects changes in name and category made. New features: -------------------- - To reduce the number of mouse gestured needed to enter or change phonemes, the position-indicating colour-bar was changed to a cursor that responds appropriately to L and R arrows and backspace. - In the expanded phoneme panel, the context menu was eliminated; a right click now adds a phoneme at the cursor position, and a left click now plays the associated sound-file. ******************************* The DictionaryMaker Team |
|
From: Bryan Mc A. <mca...@gm...> - 2008-02-22 09:01:27
|
Dictionary Maker 2.14 has been released! The following changes have been included in the latest release: Bug fix: ------------- The phoneme mapping tool now supports the use of the back-slash character (/) in phonemes. Before the use of this character would result in the mapping tool failing to export the dictionary. New features --------------- An option is now available to export files (dicitonaries, rules, graphemes, phonemes and word lists) using different encodings (UTF-8 and default encoding) Get the latest release from https://sourceforge.net/projects/dictionarymaker |
|
From: Bryan Mc A. <mca...@gm...> - 2007-08-27 09:30:02
|
Dictionary Maker 2.13 has been relased on SourceForge. The follwing is included in the latest release: Bug fix: ------------- Word pronunciations (phonemes) containing numbers were not loaded when opening the project, this resulted in a reduced total word figure. Word pronunciations containing numbers are now supported. Download it from https://sourceforge.net/projects/dictionarymaker |
|
From: Bryan Mc A. <mca...@gm...> - 2007-08-06 08:20:23
|
Dictionary Maker 2.12 has been released.
The following is contained in the latest release:
New Features
--------------------------
Enhancements have been made to the phoneme mapping tool used when exporting
dictionaries.
The user can now create the following types of mappings:
one to many, e.g. ao; A O
many to one, e.g. a o; AO
|
|
From: Bryan Mc A. <mca...@gm...> - 2007-07-02 09:32:30
|
Dictionary Maker 2.11 has been released. The release includes the following changes: Bug fixes ----------------------- The default update mode has been changed to the auto update mode. The information written to the log file has been reduced to only contain critical information. This was done to limit the size of the log file after working on a large project. The word filter now works properly. Previously it would filter words without considering the latest character entered by the user. Saving system default settings no longer results in an false error message. The rules are now displayed in the correct order when viewing a projects statistics. Only one rule extraction is now performed after importing a dictionary into a current project. The incremental rule extraction option can no longer be selected in system preferences. The reason for this is that the incremental update mode wasn't implemented correctly. New Features -------------------------- Possible error words can now be viewed in the word status window. It is now possible to export a dictionary into HTK, Festival and semi-colon delimited formats. Phoneme mapping is now supported when exporting a dictionary. |
|
From: Bryan Mc A. <mca...@gm...> - 2007-02-26 07:45:15
|
The Dictionary Maker development team is proud to announce the release of Dictionary Maker version 2.1. DictionaryMaker is a graphical tool for creating electronic pronunciation dictionaries (for natural languages). The system allows a user to develop a pronunciation dictionary without requiring expert linguistic knowledge or programming expertise. Version 2.1 Bug fixes: ---------------------- New rules are now extracted when importing a Dictionary during project creation, or during a session via the menu option. The current batch size when in batch mode now only increments if a words pronunciation is changed. Before it would increment when a word was verified as correct with the predicted pronunciation, but no new rules would be added in this case. A rule extraction message dialog box is now shown when ever rules are extracted. When importing a dictionary during a session via the menu option, the correct words are no longer lost, but are imported. When exporting rules via the menu option, the system no longer prompts the user with the same dialog again after exporting has completed. When exporting rules the rules are now in the correct order. Audio support no longer crashes when creating a new project. Audio playback after pressing the verification buttons or play button no longer results in runaway threads that slowed performance down. Audio resources are now allocated more efficiently. System memory is no longer drained every time audio playback occurs. Before the audio playback would drain system memory to such a point that the system would crash. Audio button state (Play or Stop) is now changed using Java Events. Before a thread was used to change the status of the button. The user can no longer verify a word during audio playback. The verification buttons are now activated and deactivated according to whether playback is occurring or not. |
|
From: Bryan Mc A. <bmc...@cs...> - 2007-02-23 09:03:40
|
The DictionaryMaker development team is proud to announce the release of
Dictionary Maker version 2.1.
DictionaryMaker is a graphical tool for creating electronic
pronunciation dictionaries (for natural languages). The system allows a
user to develop a pronunciation dictionary without requiring expert
linguistic knowledge or programming expertise.
Version 2.1 Bug fixes:
----------------------
New rules are now extracted when importing a Dictionary during project
creation, or during a session via the menu option.
The current batch size when in batch mode now only increments if a words
pronunciation is changed. Before it would increment
when a word was verified as correct with the predicted pronunciation,
but no new rules would be added in this case.
A rule extraction message dialog box is now shown when ever rules are
extracted.
When importing a dictionary during a session via the menu option, the
correct words are no longer lost, but are imported.
When exporting rules via the menu option, the system no longer prompts
the user with the same dialog again after exporting has
completed.
When exporting rules the rules are now in the correct order.
Audio support no longer crashes when creating a new project.
Audio playback after pressing the verification buttons or play button no
longer results in runaway threads that slowed performance down.
Audio resources are now allocated more efficiently. System memory is no
longer drained every time audio playback occurs. Before the audio
playback would drain system memory to such a point that the system would
crash.
Audio button state (Play or Stop) is now changed using Java Events.
Before a thread was used to change the status of the button.
The user can no longer verify a word during audio playback. The
verification buttons are now activated and deactivated according to
whether playback is occurring or not.
--
This message is subject to the CSIR's copyright, terms and conditions and
e-mail legal notice. Views expressed herein do not necessarily represent the
views of the CSIR.
CSIR E-mail Legal Notice
http://mail.csir.co.za/CSIR_eMail_Legal_Notice.html
CSIR Copyright, Terms and Conditions
http://mail.csir.co.za/CSIR_Copyright.html
For electronic copies of the CSIR Copyright, Terms and Conditions and the CSIR
Legal Notice send a blank message with REQUEST LEGAL in the subject line to
Cal...@cs....
This message has been scanned for viruses and dangerous content by MailScanner,
and is believed to be clean.
|
|
From: Thomas F. <tfo...@us...> - 2006-09-19 14:49:20
|
The DictionaryMaker development team is proud to announce the release of Dictionary Maker version 2.0. DictionaryMaker is a graphical tool for creating electronic pronunciation dictionaries (for natural languages). The system allows a user to develop a pronunciation dictionary without requiring expert linguistic knowledge or programming expertise. Version 1.0 was not released on sourceforge.net, so this marks the first public release of DictionaryMaker. New features included in this release: * During project creation, the user is now given the option of importing an exiting dictionary. Previously, users were only able to import a wordlist. * Added the ability to RE-PROCESS WORDS WITH MISSING GRAPHEMES. When importing words, each grahpheme is checked to see whether it already exists in the dictionary. If it does not, the affected word list (i.e. those words with missing graphemes) is displayed. The user then has the option of adding or ignoring these words. * Quick adding of phonemes: Left-clicking on the word panel displays a menu of all phonemes, as does left-clicking on phonemes in the word panel. This allows rapid addition and editing of phonemes assigned to a word. * Word List sort options added to filter. * Rule export will now also prompt for a gnull rules export file. * "Import dictionary" option added to Project menu. * "Syncronise Project Rule-set" added to Project menu. For more information, please see http://dictionarymaker.sourceforge.net/ You can download DictionaryMaker from here https://sourceforge.net/project/showfiles.php?group_id=168774 Regards The DictionaryMaker team |
|
From: pieter v. z. <pv...@cs...> - 2006-09-18 16:41:15
|
I have two problems:
* For some reason I can't check in the manuals after changing
their version numbers to 2.0 and removing " ' "
* I decided to upload the release files with the correct names and
files, BUT I don't have permission to copy the files to
pv...@sh...:/home/groups/d/di/dictionarymaker.=20
* BUT I am trying to upload the files now through ftp to the
sourceforge incoming directory. The files should be uploaded in
40 minutes. Then if Thomas are happy we he can create a release
as I don't have the rights. Probably create release early
tomorrow morning?
Please check the README file that I have created as well.
Pieter
|
|
From: pieter v. z. <pv...@cs...> - 2006-09-13 11:24:04
|
Good day, How is testing going? Andries+Marius, how is the bug fixes coming along? Pieter |
|
From: pieter v. z. <pv...@cs...> - 2006-09-05 11:27:35
|
Good day, Bug 1549787 Wrong phone order when pronunciation edited We want to know if this wrong order is only in the logs or in the display as well? It seems to work in the display.=20 The result : [DEBUG] DMRule : 22/08/2006 09:33:25 : [p, r, o, b, e, e, r] -> [p, r, ao, b, e:, 0, r] seems fine? Also there seem to be an entry missing for adding ao at this point:(It suddenly appear at this point. No log to state it was added in the middle after uh) [DEBUG] WordDisplayPanel : 22/08/2006 09:33:23 : Display phomenes: p r uh ao b e: r [DEBUG] WordDisplayPanel : 22/08/2006 09:33:23 : Changed phomene uh with ao [DEBUG] WordDisplayPanel : 22/08/2006 09:33:23 : Remove phomene: uh [DEBUG] DMRule : 22/08/2006 09:33:25 : Added word probeer The logs are not working so well. It does not log the addition of a phoneme when you add by clicking on the bottom panel. We need to fix the logging a bit and add better log messages when editing phonemes. We really need to add a event system in DictionaryMaker (we have one in Coefficient that we could use) On Mon, 2006-08-28 at 10:02 +0200, Marelie Davel wrote: > Hi there,=20 >=20 > I had a look at the logs, and overall the process seems to be running ver= y smoothly. Unfortunately editing the pronunciation is still a big problem= : if a phone is edited the system acts unpredictably - sometimes it adds a= nother phone or moves the edited phone one phone to the left or two phones = to the right, or right to the end.=20 >=20 > See for example this snippet from the log file: >=20 > [DEBUG] WordDisplayPanel : 22/08/2006 09:31:35 : Display phomenes: p r ao= b e: r > [DEBUG] WordDisplayPanel : 22/08/2006 09:32:09 : Display phomenes: p r uh= ao b e: r > [DEBUG] WordDisplayPanel : 22/08/2006 09:32:09 : Changed phomene ao with = uh > [DEBUG] WordDisplayPanel : 22/08/2006 09:32:09 : Remove phomene: ao > [DEBUG] WordDisplayPanel : 22/08/2006 09:32:15 : Play phomenes audio: p r= uh b e: r > [DEBUG] WordDisplayPanel : 22/08/2006 09:33:14 : Display phomenes: p r uh= b e: r ao > [DEBUG] WordDisplayPanel : 22/08/2006 09:33:18 : Remove phomene: ao > [DEBUG] WordDisplayPanel : 22/08/2006 09:33:23 : Display phomenes: p r uh= ao b e: r > [DEBUG] WordDisplayPanel : 22/08/2006 09:33:23 : Changed phomene uh with = ao > [DEBUG] WordDisplayPanel : 22/08/2006 09:33:23 : Remove phomene: uh > [DEBUG] DMRule : 22/08/2006 09:33:25 : Added word probeer > [DEBUG] DMRule : 22/08/2006 09:33:25 : [p, r, o, b, e, e, r] -> [p, r, ao= , b, e:, 0, r] >=20 > According to Nadia this happens all the time. >=20 > For your info I'm attaching a graph showing how fast it's currently going= .=20 >=20 > Total completed: 4014 words > Median: 2s >=20 > Once outliers (>30s) removed: > * Total completed: 3942 > * Total time: 17267s (4 hours 47 minutes 47 secs) > * Average time: 4.38s >=20 > Once outliers (>20s) removed: > * Total completed: 3844 > * Total time: 14961s (4 hours 9 minutes 21 secs) > * Average time: 3.89s >=20 > Not bad at all! >=20 > Cheers > Marelie >=20 >=20 |
|
From: pieter v. z. <pv...@cs...> - 2006-08-21 15:12:43
|
Andries, we need to investigate this. Please help. java.awt.event.MouseEvent[MOUSE_PRESSED,(18,18),button=3D1,modifiers=3DButt= on1,extModifiers=3DButton1,clickCount=3D1] on za.org.meraka.dictionarymaker= .ui.PhonemeViewer[,97,25,44x30,alignmentX=3D0.0,alignmentY=3Dnull,border=3D= javax.swing.border.EtchedBorder@1f31652,flags=3D0,maximumSize=3D,minimumSiz= e=3D,preferredSize=3D,defaultIcon=3D,disabledIcon=3D,horizontalAlignment=3D= CENTER,horizontalTextPosition=3DTRAILING,iconTextGap=3D4,labelFor=3D,text= =3Deeu,verticalAlignment=3DCENTER,verticalTextPosition=3DCENTER] dropindex 1 java.lang.IndexOutOfBoundsException: Index: 1, Size: 0 at java.util.ArrayList.add(ArrayList.java:371) at za.org.meraka.dictionarymaker.ui.WordDisplayPanel.addPhonemeViewer(WordDisp= layPanel.java:273) at za.org.meraka.dictionarymaker.ui.WordDisplayPanel.drop(WordDisplayPanel.jav= a:212) at java.awt.dnd.DropTarget.drop(DropTarget.java:398) at sun.awt.dnd.SunDropTargetContextPeer.processDropMessage(SunDropTargetContex= tPeer.java:542) at sun.awt.dnd.SunDropTargetContextPeer.access $800(SunDropTargetContextPeer.java:52) at sun.awt.dnd.SunDropTargetContextPeer $EventDispatcher.dispatchDropEvent(SunDropTargetContextPeer.java:805) at sun.awt.dnd.SunDropTargetContextPeer $EventDispatcher.dispatchEvent(SunDropTargetContextPeer.java:743) at sun.awt.dnd.SunDropTargetEvent.dispatch(SunDropTargetEvent.java:29) at java.awt.Component.dispatchEventImpl(Component.java:3494) at java.awt.Container.dispatchEventImpl(Container.java:1627) at java.awt.Component.dispatchEvent(Component.java:3477) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:3483) at java.awt.LightweightDispatcher.processDropTargetEvent(Container.java:3269) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3123) at java.awt.Container.dispatchEventImpl(Container.java:1613) at java.awt.Window.dispatchEventImpl(Window.java:1606) at java.awt.Component.dispatchEvent(Component.java:3477) at java.awt.EventQueue.dispatchEvent(EventQueue.java:480) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.j= ava:201) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.jav= a:151) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:145) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:137) at java.awt.EventDispatchThread.run(EventDispatchThread.java:100) java.awt.event.MouseEvent[MOUSE_PRESSED,(21,16),button=3D1,modifiers=3DButt= on1,extModifiers=3DButton1,clickCount=3D1] on za.org.meraka.dictionarymaker= .ui.PhonemeViewer[,97,25,44x30,alignmentX=3D0.0,alignmentY=3Dnull,border=3D= javax.swing.border.EtchedBorder@1f31652,flags=3D0,maximumSize=3D,minimumSiz= e=3D,preferredSize=3D,defaultIcon=3D,disabledIcon=3D,horizontalAlignment=3D= CENTER,horizontalTextPosition=3DTRAILING,iconTextGap=3D4,labelFor=3D,text= =3Deeu,verticalAlignment=3DCENTER,verticalTextPosition=3DCENTER] dropindex 1java.lang.IndexOutOfBoundsException: Index: 1, Size: 0 at java.util.ArrayList.add(ArrayList.java:371) at za.org.meraka.dictionarymaker.ui.WordDisplayPanel.addPhonemeViewer(WordDisp= layPanel.java:273) at za.org.meraka.dictionarymaker.ui.WordDisplayPanel.drop(WordDisplayPanel.jav= a:212) at java.awt.dnd.DropTarget.drop(DropTarget.java:398) at sun.awt.dnd.SunDropTargetContextPeer.processDropMessage(SunDropTargetContex= tPeer.java:542) at sun.awt.dnd.SunDropTargetContextPeer.access $800(SunDropTargetContextPeer.java:52) at sun.awt.dnd.SunDropTargetContextPeer $EventDispatcher.dispatchDropEvent(SunDropTargetContextPeer.java:805) at sun.awt.dnd.SunDropTargetContextPeer $EventDispatcher.dispatchEvent(SunDropTargetContextPeer.java:743) at sun.awt.dnd.SunDropTargetEvent.dispatch(SunDropTargetEvent.java:29) at java.awt.Component.dispatchEventImpl(Component.java:3494) at java.awt.Container.dispatchEventImpl(Container.java:1627) at java.awt.Component.dispatchEvent(Component.java:3477) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:3483) at java.awt.LightweightDispatcher.processDropTargetEvent(Container.java:3269) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3123) at java.awt.Container.dispatchEventImpl(Container.java:1613) at java.awt.Window.dispatchEventImpl(Window.java:1606) at java.awt.Component.dispatchEvent(Component.java:3477) at java.awt.EventQueue.dispatchEvent(EventQueue.java:480) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.j= ava:201) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.jav= a:151) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:145) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:137) at java.awt.EventDispatchThread.run(EventDispatchThread.java:100) |
|
From: Marelie D. <md...@cs...> - 2006-08-18 11:05:27
|
Hi, You're right about both features: lost focus + missing pop-up. This needn't delay the release, but there are still other bugs before we can release, and irrespective of the release we urgently need these features for our big-dictionary-building project currently under way. For small dictionaries the system already works fairly well, except for the problems with the updating modes #1542538 and the lost gnulls #1542533. For big dictionaries there are still many issues. Will send some example data to show you what goes wrong. Cheers Marelie >>> Thomas Fogwill <tfo...@us...> 8/17/2006 5:18 PM >>> On Thu, 2006-08-17 at 07:07 -0700, SourceForge.net wrote: > Bugs item #1540540, was opened at 2006-08-15 12:55 > Message generated for change (Settings changed) made by avrensbu > >Resolution: Works For Me > ---------------------------------------------------------------------- > >Comment By: Andries Jansen van Rensburg (avrensbu) > Date: 2006-08-17 16:07 > Message: > It works for me Latest from SVN works for me as well. Something that doesn't work for me, though: clicking on a phoneme on panel below adds it to the end of the word only. The phoneme list/word doesn't keep the last "focused" position (i.e. the green bar), so phonemes cannot be added mid-word when using the panel below the word. Another thing: shouldn't left-clicking on an existing phoneme also pop up the list? Selecting a phoneme from the quick menu then replaces the current phoneme in the pronunciation. Are these 2 bits important enough to delay the release until they're resolved. Is the functionality described in the second one desired at all? Thoughts/opinions? Ciao -- Thomas Fogwill <tfo...@us...> ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Dictionarymaker-devel mailing list Dic...@li... https://lists.sourceforge.net/lists/listinfo/dictionarymaker-devel -- This message is subject to the CSIR's copyright, terms and conditions and e-mail legal notice. Views expressed herein do not necessarily represent the views of the CSIR. CSIR E-mail Legal Notice http://mail.csir.co.za/CSIR_eMail_Legal_Notice.html CSIR Copyright, Terms and Conditions http://mail.csir.co.za/CSIR_Copyright.html For electronic copies of the CSIR Copyright, Terms and Conditions and the CSIR Legal Notice send a blank message with REQUEST LEGAL in the subject line to Cal...@cs.... This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. |
|
From: Thomas F. <tfo...@us...> - 2006-08-17 15:18:19
|
On Thu, 2006-08-17 at 07:07 -0700, SourceForge.net wrote: > Bugs item #1540540, was opened at 2006-08-15 12:55 > Message generated for change (Settings changed) made by avrensbu > >Resolution: Works For Me > ---------------------------------------------------------------------- > >Comment By: Andries Jansen van Rensburg (avrensbu) > Date: 2006-08-17 16:07 > Message: > It works for me Latest from SVN works for me as well. Something that doesn't work for me, though: clicking on a phoneme on panel below adds it to the end of the word only. The phoneme list/word doesn't keep the last "focused" position (i.e. the green bar), so phonemes cannot be added mid-word when using the panel below the word. Another thing: shouldn't left-clicking on an existing phoneme also pop up the list? Selecting a phoneme from the quick menu then replaces the current phoneme in the pronunciation. Are these 2 bits important enough to delay the release until they're resolved. Is the functionality described in the second one desired at all? Thoughts/opinions? Ciao -- Thomas Fogwill <tfo...@us...> |
|
From: Thomas F. <tfo...@us...> - 2006-08-10 11:43:17
|
Hi
We are currently in a "code freeze" to prepare for a release.
The following bugs have been closed:
* #1532220: User select mode chooses CORRECT status word
* #1531774: Log Messages
* #1531769: Word list: History Tab
* #1531627: Changing word status to correct with missing
pronunciation
* #1524394: Remove phoneme does not update display
* #1524364: Deleting multiple words from list
* #1524361: Open recent loses path
* #1524357: Edit dictionary: add dictionary
* #1524356: statistics order
* #1524351: Update modes
* #1524343: view rules
* #1524341: pronunciation edit drop-down list order
* #1524337: Synchronise button
* #1523682: Update modes: Incremental settings
* #1519922: Missing functionality: extracting gnulls
* #1519919: Importing with faulty pho-files
* #1519917: Verifying import data
* #1502708: Predicting Words from the start
* #1502705: Choosing Next Word
Testing is currently underway to confirm that these issues are indeed
fixed in TRUNK. Can anyone report on the progress of this testing? I'd
like to start preparing the release files after the weekend.
4 bugs are still open:
* #1524360: Editing pronunciation slow
* #1524348: g2p back-end bugs
* #1524335: Project defaults save error
* #1519921: Missing Main functionality
Unless anyone feels very strongly to the contrary, we will probably
release with these bugs unresolved.
Regards
--
Thomas Fogwill <tfo...@us...>
|
|
From: Thomas F. <tho...@me...> - 2006-08-08 07:15:22
|
Hi Following the accidental deletion and re-addition by Marius of ChangeLog in SVN, I have recovered the older (pre-deletion) version. Please check that all ChangeLog entries you made since revision 521 are present in HEAD. Cheers -- Thomas Fogwill <tho...@me...> |
|
From: Marelie D. <md...@cs...> - 2006-08-02 08:10:10
|
Sounds good!
>>> Thomas Fogwill <tfo...@us...> 08/02/06 9:56 AM
>>>
Hi
On Wed, 2006- 08- 02 at 08:39 +0200, Marelie Davel wrote:
> I preferred Andries's approach, with the addition that 3 only
applies
> to verified words (which I sort of assumed). In general, this
process
> will be used to combine two dictionaries that may come from very
> different sources - it won't just be used to add a dictionary to a
> bootstrapped project. Also, before adding a new dictionary, I would
> encourage a user to export the current dictionary and rather create
a
> new project, which means both source dictionaries will continue to
exist
> separate from the new combined version.
>
> My suggestion (from the user's perspective):
> > 1. File browse. Pick dictionary file (verify that it is in a
*.dict
> format, whatever it is called)
> > 2. Add all words that does not already exist in dictionary (check
for
>
> > missing graphemes)
> > 3. Show list of conflict words+phonemes+status, where conflict
words
> are only those that have been verified on both sides, and conflict.
If
> both are unverified, then just add the word (the pronunciation will
be
> created through prediction based on the rule set, as usual.) If
only
> one is verified, import that verdict, whatever it is. Also import
the
> pronunciation if verdict==correct. (check for missing phonemes) Only
for
> words that have conflicting verdicts, continue to 4.
> > 4. single/multi select word+phoneme+status and select Replace or
> > ignore
ok, cool. So, to check that we agree:
given OW and NW as before,
1. if OW == null (i.e. this word is not in our first dictionary):
import NW verbatim
2. if OW != null (i.e. exists in first dict) && OW.status ==
CORRECT and NW.status == CORRECT && NW.phonemes !=
OW.phonemes:
prompt.
3. if OW != null && OW.status == UNVERIFIED && NW.status !=
UNVERIFIED: import NW verbatim
4. if OW != null && OW.status == INVALID or AMBIGUOUS &&
NW.status != OW.status: prompt
5. if OW != null && OW.status == UNCERTAIN: && NW.status is
"stronger" (i.e. CORRECT, INVALID, or AMBIGUOUS): import NW
verbatim.
6. in all other cases, keep OW
> The above implies 3 levels for word statuses:
> High: CORRECT, AMBIGUOUS, INVALID
> Medium: UNCERTAIN
> Lowest: UNVERIFIED
So, in short (using the levels defined above),
* if NW.status.level > OW.status.level, import NW
* if NW.status.level < OW.status.level, keep OW
* if NW.status.level == OW.status.level
* if NW.status == OW.status && if NW.phonemes ==
OW.phonemes, keep OW
* else prompt
The following still applies:
> Whenever we add a word that was not previously in the dict, we must
> check that all graphemes are valid (and import any new ones).
>
> We must also check the phoneme list of any new words to be added, to
> ensure that all phonemes are valid. If there are invalid phonemes,
we
> should either:
> * skip that word
> * import the phoneme (prompting for sound files, etc.)
>
> I'm not sure which approach we should follow. Thoughts?
>
> The phoneme list also needs to be checked when existing words are
> changed.
I agree that the prompting (i.e. for which word/pronunciation to
keep),
should be done in "batch" mode.
Make sense?
Cheers
--
Thomas Fogwill <tfo...@us...>
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT & business topics through brief surveys -- and earn
cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Dictionarymaker- devel mailing list
Dictionarymaker- de...@li...
https://lists.sourceforge.net/lists/listinfo/dictionarymaker- devel
--
This message is subject to the CSIR's copyright, terms and conditions and
e-mail legal notice. Views expressed herein do not necessarily represent the
views of the CSIR.
CSIR E-mail Legal Notice
http://mail.csir.co.za/CSIR_eMail_Legal_Notice.html
CSIR Copyright, Terms and Conditions
http://mail.csir.co.za/CSIR_Copyright.html
For electronic copies of the CSIR Copyright, Terms and Conditions and the CSIR
Legal Notice send a blank message with REQUEST LEGAL in the subject line to
Hel...@cs....
This message has been scanned for viruses and dangerous content by MailScanner,
and is believed to be clean.
|
|
From: Thomas F. <tfo...@us...> - 2006-08-02 07:56:14
|
Hi
On Wed, 2006-08-02 at 08:39 +0200, Marelie Davel wrote:
> I preferred Andries's approach, with the addition that 3 only applies
> to verified words (which I sort of assumed). In general, this process
> will be used to combine two dictionaries that may come from very
> different sources - it won't just be used to add a dictionary to a
> bootstrapped project. Also, before adding a new dictionary, I would
> encourage a user to export the current dictionary and rather create a
> new project, which means both source dictionaries will continue to exist
> separate from the new combined version.
>
> My suggestion (from the user's perspective):
> > 1. File browse. Pick dictionary file (verify that it is in a *.dict
> format, whatever it is called)
> > 2. Add all words that does not already exist in dictionary (check for
>
> > missing graphemes)
> > 3. Show list of conflict words+phonemes+status, where conflict words
> are only those that have been verified on both sides, and conflict. If
> both are unverified, then just add the word (the pronunciation will be
> created through prediction based on the rule set, as usual.) If only
> one is verified, import that verdict, whatever it is. Also import the
> pronunciation if verdict==correct. (check for missing phonemes) Only for
> words that have conflicting verdicts, continue to 4.
> > 4. single/multi select word+phoneme+status and select Replace or
> > ignore
ok, cool. So, to check that we agree:
given OW and NW as before,
1. if OW == null (i.e. this word is not in our first dictionary):
import NW verbatim
2. if OW != null (i.e. exists in first dict) && OW.status ==
CORRECT and NW.status == CORRECT && NW.phonemes != OW.phonemes:
prompt.
3. if OW != null && OW.status == UNVERIFIED && NW.status !=
UNVERIFIED: import NW verbatim
4. if OW != null && OW.status == INVALID or AMBIGUOUS &&
NW.status != OW.status: prompt
5. if OW != null && OW.status == UNCERTAIN: && NW.status is
"stronger" (i.e. CORRECT, INVALID, or AMBIGUOUS): import NW
verbatim.
6. in all other cases, keep OW
> The above implies 3 levels for word statuses:
> High: CORRECT, AMBIGUOUS, INVALID
> Medium: UNCERTAIN
> Lowest: UNVERIFIED
So, in short (using the levels defined above),
* if NW.status.level > OW.status.level, import NW
* if NW.status.level < OW.status.level, keep OW
* if NW.status.level == OW.status.level
* if NW.status == OW.status && if NW.phonemes ==
OW.phonemes, keep OW
* else prompt
The following still applies:
> Whenever we add a word that was not previously in the dict, we must
> check that all graphemes are valid (and import any new ones).
>
> We must also check the phoneme list of any new words to be added, to
> ensure that all phonemes are valid. If there are invalid phonemes, we
> should either:
> * skip that word
> * import the phoneme (prompting for sound files, etc.)
>
> I'm not sure which approach we should follow. Thoughts?
>
> The phoneme list also needs to be checked when existing words are
> changed.
I agree that the prompting (i.e. for which word/pronunciation to keep),
should be done in "batch" mode.
Make sense?
Cheers
--
Thomas Fogwill <tfo...@us...>
|
|
From: Marelie D. <md...@cs...> - 2006-08-02 06:39:50
|
Hi there,
I preferred Andries's approach, with the addition that 3 only applies
to verified words (which I sort of assumed). In general, this process
will be used to combine two dictionaries that may come from very
different sources - it won't just be used to add a dictionary to a
bootstrapped project. Also, before adding a new dictionary, I would
encourage a user to export the current dictionary and rather create a
new project, which means both source dictionaries will continue to exist
separate from the new combined version.
For example, after creating dictionary A through bootstrapping I find
dictionary B on the Internet, and would like to combine the two. A quick
script changes dict B into the correct format. Now I create a new
project, initialize it with dict A and select to import dictionary B (or
vice versa!) Any of the dictionaries may have mistakes in them - even
if marked valid. Whenever they disagree, I would like to make a choice.
If I'm more sure of one dictionary than the other, I can also
multiselect all words and reject or ignore en mass.
My suggestion (from the user's perspective):
> 1. File browse. Pick dictionary file (verify that it is in a *.dict
format, whatever it is called)
> 2. Add all words that does not already exist in dictionary (check for
> missing graphemes)
> 3. Show list of conflict words+phonemes+status, where conflict words
are only those that have been verified on both sides, and conflict. If
both are unverified, then just add the word (the pronunciation will be
created through prediction based on the rule set, as usual.) If only
one is verified, import that verdict, whatever it is. Also import the
pronunciation if verdict==correct. (check for missing phonemes) Only for
words that have conflicting verdicts, continue to 4.
> 4. single/multi select word+phoneme+status and select Replace or
> ignore
Cheers
Marelie
>>> Thomas Fogwill <tfo...@us...> 08/01/06 3:23 PM
>>>
> >>> avrensbu <avr...@cs...> 08/01/06 11:06 AM >>>
> I want to confirm functionality for importing dictionary into
> project.
My proposal follows. Please comment.
> 3. Show list of conflict words+phonemes+status
> 4. single/multi select word+phoneme+status and select Replace or
> ignore
This seems like a lot of work for the user. I think the system should
do
most of this work (the whole "sane default system behaviour"
philosophy). The way I see it, we always want to preserve (in our
current dictionary) any information that was explicitly provided by
the
user. This is important because the dictionary file being imported is
not altered, but the file for the current dictionary is. If we
overwrite
any information, it is thus lost.
Throughout the rest of this email, OW refers to the Old_Word (i.e. the
word in our current dictionary), and NW refers to the New_Word (i.e.
the
word in the dictionary being imported). These are the cases to
consider:
1. If OW == null (i.e. this word is not in our dictionary), we
import NW verbatim (checking graphemes and phonemes - see
below)
2. If OW != null (i.e. exists in current dict) && OW.status ==
CORRECT then skip NW completely (user marked this
pronunciation
as VALID, so we shouldn't mess with it)
3. OW != null && OW.status == UNVERIFIED: if NW.status ==
UNVERIFIED, skip NW, otherwise import NW verbatim (checking
phonemes - see below). In this case, the user provided no
info
for OW, and the only info we have for this word is (possibly)
a
list of phonemes as predicted by the system. If NW has more
info, we should use that info.
4. OW != null && OW.status == INVALID or AMBIGUOUS: the user has
specified that this word is invalid or ambiguous. We must not
lose this info, so we skip NW.
5. OW != null && OW.status == UNCERTAIN: the user said they
didn't
know what the correct pronunciation for this word was. If
NW.status is "stronger" (i.e. CORRECT, INVALID, or AMBIGUOUS)
then we import NW verbatim, otherwise we skip it.
The above implies 3 levels for word statuses:
High: CORRECT, AMBIGUOUS, INVALID
Medium: UNCERTAIN
Lowest: UNVERIFIED
Existing words are only altered when the new word has a higher status
level. When both words have the same status level, there are 3
possible
approaches:
* keep the existing word as is (my proposed approach, described
above)
* replace the existing word with the new one (I would not
recommend this)
* prompt user to make a selection (similar to what Andries
proposed; I prefer the first approach, as it is less
burdensome/tedious for the user)
Whenever we add a word that was not previously in the dict, we must
check that all graphemes are valid (and import any new ones).
We must also check the phoneme list of any new words to be added, to
ensure that all phonemes are valid. If there are invalid phonemes, we
should either:
* skip that word
* import the phoneme (prompting for sound files, etc.)
I'm not sure which approach we should follow. Thoughts?
The phoneme list also needs to be checked when existing words are
changed.
m2c
--
Thomas Fogwill <tfo...@us...>
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT & business topics through brief surveys -- and earn
cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Dictionarymaker- devel mailing list
Dictionarymaker- de...@li...
https://lists.sourceforge.net/lists/listinfo/dictionarymaker- devel
--
This message is subject to the CSIR's copyright, terms and conditions and
e-mail legal notice. Views expressed herein do not necessarily represent the
views of the CSIR.
CSIR E-mail Legal Notice
http://mail.csir.co.za/CSIR_eMail_Legal_Notice.html
CSIR Copyright, Terms and Conditions
http://mail.csir.co.za/CSIR_Copyright.html
For electronic copies of the CSIR Copyright, Terms and Conditions and the CSIR
Legal Notice send a blank message with REQUEST LEGAL in the subject line to
Hel...@cs....
This message has been scanned for viruses and dangerous content by MailScanner,
and is believed to be clean.
|
|
From: Thomas F. <tfo...@us...> - 2006-08-01 13:23:46
|
> >>> avrensbu <avr...@cs...> 08/01/06 11:06 AM >>>
> I want to confirm functionality for importing dictionary into
> project.
My proposal follows. Please comment.
> 3. Show list of conflict words+phonemes+status
> 4. single/multi select word+phoneme+status and select Replace or
> ignore
This seems like a lot of work for the user. I think the system should do
most of this work (the whole "sane default system behaviour"
philosophy). The way I see it, we always want to preserve (in our
current dictionary) any information that was explicitly provided by the
user. This is important because the dictionary file being imported is
not altered, but the file for the current dictionary is. If we overwrite
any information, it is thus lost.
Throughout the rest of this email, OW refers to the Old_Word (i.e. the
word in our current dictionary), and NW refers to the New_Word (i.e. the
word in the dictionary being imported). These are the cases to consider:
1. If OW == null (i.e. this word is not in our dictionary), we
import NW verbatim (checking graphemes and phonemes - see below)
2. If OW != null (i.e. exists in current dict) && OW.status ==
CORRECT then skip NW completely (user marked this pronunciation
as VALID, so we shouldn't mess with it)
3. OW != null && OW.status == UNVERIFIED: if NW.status ==
UNVERIFIED, skip NW, otherwise import NW verbatim (checking
phonemes - see below). In this case, the user provided no info
for OW, and the only info we have for this word is (possibly) a
list of phonemes as predicted by the system. If NW has more
info, we should use that info.
4. OW != null && OW.status == INVALID or AMBIGUOUS: the user has
specified that this word is invalid or ambiguous. We must not
lose this info, so we skip NW.
5. OW != null && OW.status == UNCERTAIN: the user said they didn't
know what the correct pronunciation for this word was. If
NW.status is "stronger" (i.e. CORRECT, INVALID, or AMBIGUOUS)
then we import NW verbatim, otherwise we skip it.
The above implies 3 levels for word statuses:
High: CORRECT, AMBIGUOUS, INVALID
Medium: UNCERTAIN
Lowest: UNVERIFIED
Existing words are only altered when the new word has a higher status
level. When both words have the same status level, there are 3 possible
approaches:
* keep the existing word as is (my proposed approach, described
above)
* replace the existing word with the new one (I would not
recommend this)
* prompt user to make a selection (similar to what Andries
proposed; I prefer the first approach, as it is less
burdensome/tedious for the user)
Whenever we add a word that was not previously in the dict, we must
check that all graphemes are valid (and import any new ones).
We must also check the phoneme list of any new words to be added, to
ensure that all phonemes are valid. If there are invalid phonemes, we
should either:
* skip that word
* import the phoneme (prompting for sound files, etc.)
I'm not sure which approach we should follow. Thoughts?
The phoneme list also needs to be checked when existing words are
changed.
m2c
--
Thomas Fogwill <tfo...@us...>
|
|
From: Thomas F. <tfo...@us...> - 2006-08-01 12:39:05
|
> >>> avrensbu <avr...@cs...> 08/01/06 11:06 AM >>>
> I whant to confirm functionality for importing dictionary into
> project.
>
>
> 1. File browse. Pick diction ary file (filtered *.dict)
> 2. Add all words that does not already exist in dictionary (check for
> missing graphemes, check for missing phonemes)
> 3. Show list of conflict words+phonemes+status
> 4. single/multi select word+phoneme+status and select Replace or
> ignore
This seems like a lot of work. The way I see it, we want to preserve (in
the current dictionary) any information provided by the user. The
dictionary file being imported is not altered, but the file for the
current dictionary is. If we overwrite any information, it is lost
forever.
Throughout the rest of this email, OW refers to the Old_Word (i.e. the
word in our current dictionary), and NW refers to the New_Word (i.e. in
the dictionary being imported). These are the cases to consider:
1. If OW == null (i.e. this word is not in our dictionary yet),
import NW verbatim (checking graphemes and phonemes - see below)
2. If OW != null (i.e. exists in current dict)
My proposal is that we use the word status to determine wh
--
Thomas Fogwill <tfo...@us...>
|
|
From: Marelie D. <md...@cs...> - 2006-08-01 10:34:42
|
Sounds good to me! >>> avrensbu <avr...@cs...> 08/01/06 11:06 AM >>> I whant to confirm functionality for importing dictionary into project. 1. File browse. Pick diction ary file (filtered *.dict) 2. Add all words that does not already exist in dictionary (check for missing graphemes, check for missing phonemes) 3. Show list of conflict words+phonemes+status 4. single/multi select word+phoneme+status and select Replace or ignore -- This message is subject to the CSIR's copyright, terms and conditions and e- mail legal notice. Views expressed herein do not necessarily represent the views of the CSIR. CSIR E- mail Legal Notice http://mail.csir.co.za/CSIR_eMail_Legal_Notice.html CSIR Copyright, Terms and Conditions http://mail.csir.co.za/CSIR_Copyright.html For electronic copies of the CSIR Copyright, Terms and Conditions and the CSIR Legal Notice send a blank message with REQUEST LEGAL in the subject line to Hel...@cs.... This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. -- This message is subject to the CSIR's copyright, terms and conditions and e-mail legal notice. Views expressed herein do not necessarily represent the views of the CSIR. CSIR E-mail Legal Notice http://mail.csir.co.za/CSIR_eMail_Legal_Notice.html CSIR Copyright, Terms and Conditions http://mail.csir.co.za/CSIR_Copyright.html For electronic copies of the CSIR Copyright, Terms and Conditions and the CSIR Legal Notice send a blank message with REQUEST LEGAL in the subject line to Hel...@cs.... This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. |
|
From: pieter v. z. <pv...@cs...> - 2006-07-31 14:24:21
|
Marelie Davel
:
Makes sense. But I still think it's clearer to dict developers to
specify the graphemes explicitly. E.g.=20
"The word "$1ith3r" contains the grapheme(s) x,y and z that are not
present in the dictionary. Adding "$1ith3r" will automatically import
these missing graphemes."=20
I see what you mean with 'Apply to all', but I think the option might be
confusing. Calling such a feature 'Automatically import all further
missing graphemes' would make more sense to me, even though I guess it's
too wordy for a UI... Can you think of a better/shorter description?
Otherwise perhaps easier just to leave the feature out, rather than
having a confusing option. I don't have a strong preference here.=20
Cheers
Marelie
=20
>>> Thomas Fogwill 07/26/06 3:39 PM >>>=20
On Wed, 2006- 07- 26 at 15:18 +0200, Marelie Davel wrote:
> This would also work! ('Apply to all' will only be valid for 'skip'.
> Adding a grapheme automatically applies to all.)=20
My idea is that the "apply all" option also makes sense for "add". We
don't show the missing graphemes, merely the word. The "action" chosen
by the user is then "Add/Skip Word", not "Add/Skip Graphemes", and
"apply to all" does then make sense for future words as well.
Something like:
The word "$1ith3r" contains grapheme(s) that are not present in the
dictionary. Adding "$1ith3r" will automatically import these missing
graphemes.
What would you like to do?
[ADD_WORD] [SKIP_WORD] [CANCEL]
[] Apply to all ...
Checking "apply to all" in this context then means "do the same thing
for any other words encountered that have missing graphemes". These
graphemes would differ from those that were invalid in $1ith3r (which
would already have been imported).
To me, this makes good UI sense (consistency, simplicity, etc), but does
it makes sense to you i.t.o. how the system will be used?=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Marelie Davel
:
This would also work! ('Apply to all' will only be valid for 'skip'.
Adding a grapheme automatically applies to all.)=20
=20
>>> Thomas Fogwill 07/26/06 3:08 PM >>>=20
Hi
On Wed, 2006- 07- 26 at 14:55 +0200, pieter van zyl wrote:
> Good day,
>=20
> I would like to discuss some of the issues of importing words:
>=20
> if there is a new grapheme in a word that does not exist in the
> Dictionary:
> [snip]
I think it should work as follows:
* encounter word with "illegal" graphemes
* Show dialog to
* ask whether to add word (and add missing graphemes), or
skip the word
* also have a checkbox for "Apply to all ...". If user
checks this, then "skip" will cause all other invalid
words to be skipped automatically (without prompting);
similarly for "add".
* take appropriate action, and loop
Cheers
--=20=20
Thomas Fogwill
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D
Hi there,=20
I can see that various options can work here. I like your first
suggestion:
* go through the list and give the user a list of graphemes at the end
that can be added or skipped
* and if the user skips the grapheme: words using that grapheme are also
skipped
Then:
* No need to double-check relationships (it's fine if @#a is removed).
* Just showing a dialog with graphemes is fine - showing words per
grapheme a nice-to-have.
* Rather not add graphemes automatically - we've already specified that
a grapheme cannot be removed unless all words using it are also removed,
rather not create a special situation here.
My 2c!=20
Cheers
marelie
>>> pieter van zyl 07/26/06 2:55 PM >>>=20
Good day,
I would like to discuss some of the issues of importing words:
if there is a new grapheme in a word that does not exist in the
Dictionary:
* do we go through the list and give the user a list of graphemes
at the end that can be added or skipped
* and if the user skips the grapheme: words using that grapheme
are also skipped
* but that means if we add grapheme # and not grapheme @ and we
have a word @#a then we skip this word because it contains @
which is not in the dictionary. Should I add checks here to
inform the user that even though he has added grapheme # this
word "@#a" will still be removed. it gets complicated with
checking all the relationships.
* And do I provide a dialog showing only the missing graphemes or
do I show <grapheme> and <lists of words that contain that
grapheme>
* OR we can check for missing graphemes and add all of the missing
graphemes and let the user later removed illegal ones. And when
they do remove the illegal graphemes later the words containing
that grapheme should also be removed?
And we don't import phonemes if there is no a sound file. Also going to
add filters to check for file/ mime types: mp3,ogg,wav,etc.
Pieter
|
|
From: pieter v. z. <pv...@cs...> - 2006-07-28 21:48:43
|
check Project.load() and ProjectSettings.setProjectDirectory when we are working with a project we store the project location of this current project. So use ProjectSettings.getProjectDirectory() to get the project location. Store the log file here.(one log file per project) On Fri, 2006-07-28 at 10:19 +0200, Marius Peche wrote: > I've got the system writing the logs to file, but where should this > life be stored? Obviously in the project folder, but where is it > defined?=20 >=20=20 > MP=20 |
|
From: Thomas F. <tfo...@us...> - 2006-07-28 21:34:25
|
Hi The website content is now stored in SVN under trunk/doc/website. See: http://svn.sourceforge.net/viewcvs.cgi/dictionarymaker/trunk/doc/website/ Please do not edit the web content directly on shell.sf.net; rather edit in SVN. The project website is automatically updated from SVN (daily via a cron job). Cheers -- Thomas Fogwill <tfo...@us...> |
