Re: [Tetum-translators] Fw: BlackDog-WhiteBoard

[Lev Lafayette]

OK, I like this a lot. The flowchart is following the
discussion thread and incorporating material
appropriately. I particularly like the 'optional learn
from selections' user choice.

I think there are three further elements that have to
be considered and incorporated.

1) Rather than 'words' use 'phrases'. This seems to be
the case with all machine translation literature that
I have read. Gets around problems of definite
articles, conjunctions of verbs etc.

2) Between 5 and 7 (where's 6?) there needs to be a
'grammar translation phase'. This may be one of the
hardest elements.

3) I think it is important to specify what sort of
interface or programming language we're using at each
step. Just for my own sanity before I start learning
Python, right?

Again I'd like to reiterate that this is extremely
good work. I'm quite impressed.

Regards,


Lev




--- Peter Gossner <address@hidden> wrote:
> 
> 
> Forwarded message:
> 
> Date: Fri, 12 Mar 2004 02:02:07 +1030
> From: Peter Gossner <address@hidden>
> To: Lev <address@hidden>,
> address@hidden
> <address@hidden>,
> address@hidden
> <address@hidden>
> Subject: BlackDog-WhiteBoard
> 
> 
> Hi guys.
> Attached should be a dia format whiteboard of a
> revised approach
> to the translator.
> The idea is to chew twice and pass it on ... :)
> 
> The Design Objective is to capture as many errors as
> practicable before
> processing. The main change is putting the spell
> checker in early and
> whenever the user edits the document live.
> 
> The other is to identify unknown words from the
> source language, (i.e.
> the spell checker does not know them ) and known
> words for which there
> is no translation in the target language.
> 
> This should reduce errors and hits on the logic
> engines / dictionaries
> underneath everything.
> It does mean that we need to build comprehensive
> dictionaries  and
> syntax "mappings).. but that just takes time and
> hopefully usage.
> 
> Procedurally the process goes in two major steps. 
> (which may/will/can
> loop) Step 1 contains process steps 0 -4. (enter the
> source doc to ask
> for translation)
> Step 2 may involve user interaction and essentially
> presents the user
> with a translation they may edit in the target
> language. (or perhaps
> return to the source language step .. not sure yet)
> I imagine the entire doc is initially translated
> with tagged(and/ or
> colour coded) half tone xml tags wrapped
> around"problem" words or
> phrases. I would hope to have a right button popup
> menu to select single
> words or a larger window for phrases ... not sure
> about the phrases
> bit.. 
> 
> I have posted the dia with the engine room turned
> off select "view
> => layers" to play with that.
> 
> Other news is that I think we can have our own
> database(s) without too
> much trouble..(and not lose too much speed).This
> should work for
> standalone and local system wide services. May still
> use postgres for
> Project wide stuff but more on that later.(as an
> active server thingy)
> (security, speed and such)
> 
> 
> now as for the learning environment I have only a
> conceptual scope on
> this but I can see a couple of ways of tackling it:
> 1/ is embedding W3C cwm and N3 tools
> 2/ is building our own 
> 3/ most likely; rewriting the W3C stuff to suit us.
> 
> As for an editor I had a quick look at Abiword and
> that IS possible ...
> though I will need to do some extra study as there
> is a fair bit of C++
> there. The advantages are many though. Most flexible
> choice.
> 
> Then there is Gedit. Which should be simpler to
> implement and has built
> in most things we need.
> 
> Another is to simply use the GTK2 text editor widget
> and implement our
> own interfaces to Aspell etc. (probably smallest
> footprint and just as
> functional as Gedit .. also leaves us free of update
> issues by other
> projects) I will do some more homework on this but
> the demo i looked at
> (with the developers tools) looks quite doable.
> 
> Finally at some stage I reckon this would mesh very
> well with emacs
> xemacs and the MULE stuff (at least). However this
> involves most work
> for our users. (though also eventually the most
> power.. hey of course)
> 
> By the way. Sylpheed (this mail app) has a good
> interface to spell
> checking.. I think I have the source code for it
> stashed away somewhere
> as well...
> 
> (though I hate the editor ...)
> 
> One last really important note on the editor /
> interface :
> If we do this carefully it should be possible to
> produce plugins for Abi
> and Gedit in any case.. It would probably just
> involve a separate pop up
> window.. and would also (probably) use the tabs
> capacity of gedit and
> another full editor window(view) for abiword...i.e.
> It is really
> practical to keep the logic engines away from the
> default interface.
> (a few buttons as possible in normal mode)
> 
> 
> I will start a separate thread for a development
> plan and approaches..
> and am keen to get more input. !
> 
> A "good Thing" about the version 0.0 approach is
> that it abstracts away
> the logic algorithms as well :) (so we can freely
> play with them.)
> 
> 
> Well hope this all makes some kind of sense.
> 
> Pete
> -- 
> Mesage Composed: Thu Mar 11 15:30:03 UTC 2004
> Calendar events:
> Mar 13        The Allman Brothers record their live album
> at the Fillmore
> East, 1971 
> Mar 13        "Striptease" introduced, Paris, 1894
> < http://www.gnu.org/software/tetum/ >
> < http://bigbutton.com.au/~gossner >
> < address@hidden >
> 
> 
> 
> 
> 

> ATTACHMENT part 2 application/octet-stream
name=BlackDog-WhiteBoard-0.0.dia
> _______________________________________________
> Tetum-translators mailing list
> address@hidden
>
http://mail.nongnu.org/mailman/listinfo/tetum-translators
> 


=====
Lev Lafayette
address@hidden
http://au.geocities.com/lev_lafayette

__________________________________
Do you Yahoo!?
Yahoo! Mail - More reliable, more storage, less spam
http://mail.yahoo.com