Hi,

Thanks for your feedback, I sorted and changed the way of doing my tasks.
Below, my Summer's planning (established from
http://socghop.appspot.com/gsoc/events/google/gsoc2011).

Due to school end of year's project, I would start on the June 10

Week1 :
More work hours are planned to make up for lost weeks.

1) Port the code for all recent php versions; By the way, finish to
familiarize with the code
        for example :
                if($_FILES["in_doc"] AND !($_FILES["in_doc"]["error"] > 0)) 
                file_put_contents
        become :
                if(isset($_FILES[“in_doc”] and !empty($_FILES[“in_doc”]) ...
                fopen, fwrite, fclose

2) Rewrite the Javascript as separate modules so that it be easy to decide
which tools to enable or disable in the interface
        -> Make a dependences tree of functions in current libraries
        -> Write more generic functions and procedure to give foundation for
modules
        -> Make an user interface to enabled/disabled modules ( List of modules,
recommended modules with description, use example )

Week2 :
More work hours are planned to make up for lost weeks.

3) Rewrite language.php file as an abstract script, and interface modules
for Apertium, Aspell and LanguageTool. 
        -> Separate the translation system and the environment management system
        -> Make the translation system as an PHP Object, which is initialised
with languages pairs
        -> Extend the environment management system to allow writing of
interfaces modules for Aspell and LanguageTool
        -> Write these modules
        
4) Provide more formatting modules; currently only ODF, OOXML, html and
text are supported. Mediawiki (using apertium-mediawiki) and others are
wanted.
        -> Add module for Rich Text Format formatting (using existing Apertium's
modules)

Week3 :
More work hours are planned to make up for lost weeks.

4)(suite) -> Add module for Mediawiki formatting (using existing
Apertium's modules)
        -> Make test for Pdf formatting, with pdf2html on a pdf set, and test 
for
the reconstruction step
        -> If they are inconclusive, write the pdf module
        -> Provide a module using cuneiform ( who is able to recognize multiple
languages and maintain a basic layout ) for Pictures. The export HTML
functionality can be used (jointly with html module ).

5) Localisation, make it possible to translate the interface into
different languages.
        -> The localisation is given by the browser, IP Address or set by the
user
        -> The choice is save ( cookies, .. )
        -> The interface texts are load from files, which contain the text for
every button, checkbox, ... in a specific order ( to make analysis faster
than an XML format )
As it was said, people who do want to write a language file should share
it with the Apertium community.


6) Improve overall design
        -> The current design is very basic ( or non-existent )
        -> The Apertium website will pass on WordPress system, so the overall
design can be taken
        -> If the website isn't yet on WordPress, make a design similar to the
Apertium current website ( in colour, simplicity, .. )


7) Fix possibly remaining bugs
           -> It's a task on the long time, but at this stage, I want to
make a
    complete test of the system
           -> It's include :
                   - Fix remaining bugs

Week4 :
More work hours are planned to make up for lost weeks.

7)(suite) 
                   - Make some test sets
                   - Optimize code
                   - Fix security issues
                   
8) Make it possible to input a TMX to help for a translation (either with
    Apertium's TMX input system, or an external tool like OmegaT)
    -> Ask Sergio Ortiz on the integration of TMX to identify and
translate segments from a translation memory
    -> Make it
    

9) Use existing server-side TMX database, so that the memory generated
after a
    translation be stored and reused automatically for next translations
in
    this language pair. (It might be wise to add some kind of validation
too,
    to make sure that people don't mess with the whole system by
submitting
    wrong translations...)
    
The main idea is to permit to the user to give or alter current
translations, export them to TMX format. At the same
time, these modifications are saved in a server-side TMX database, which
contain two kinds of dictionaries by language :
                   - Submitted and awaiting for approving translations
                   - Approved translations
           -> Add it in the user interface with simply a checkbox "Reuse
old translations to improve translation" and another one "Share translation
results" (this choice is important due to confidentiality problem with
content submitted to the engine)
           -> Perhaps we can see here a way to use the logging system, may
edit it to allow him to detect what the user change on the translation (
Like Igor Chtivelband said ).
It seems necessary to save the context too.


Week5 :

9)(continue and finish)
According to Jimmy O'Regan, it seems that it's a difficult task. Time is
needed.


Again, Fix possibly remaining bugs to have a good foundation for the
further.

Mid Evaluation : July 15
Week6 :

10) Provide a module to use the apertium.org web service instead of a
local Apertium installation 
        -> Make a bridge between apertium.org website and local Apertium
installation :
                -perhaps by parsing, with regular expression, the page 
translation
result ( simulate the entry of user on the website, and analyse the result
), but it is expensive
                -an other choice is the use of an API for the apertium.org 
web-service,
which will avoid the phase return analysis

To make my explanation easier to understand, here is an example :
To translate "Test" on the website, you have to build a web POST request
The servers return a html file, so you have to research the expression
between '>' and '</textarea><br/><label for="mark">' (perhaps a more
accurate research).

But if an API is write, it allow the script to just get back the server
response, because it will be only the translation, without html formatting.

        -> Add the possibility for the user to use this service, in the 
interface


11) Make it faster and cross-browser compatible 
        -> Give, and add to JS existing modules, libraries to adapt the system
for recent browser. We can down to IE 6.
        -> Make it faster by analysing the time critical path
        -> Make the different libraries download faster, by reducing their size 
(
like Google for jquery )

Week7 :

11)(continue and finish)
This is a long task, need time.


Week8 :
12)Improve integration with Wikipedia — it should be able to fetch pages,
translate, allow to be revised and then published. 
        -> Integrate module for recognize Wikipedia format
        -> Use WikiBhasha to fetch pages, and post them

13)Provide modules to integrate alternative tools for spell and grammar
checking (AfterTheDeadline, etc.) 
        -> Make outputs during the translation process, which can be redirected
to others tool
        -> Define the possible interaction with the software
        -> Implement these interactions


Week9 :
14) Fix new or remaining s bugs
        -> Stand back, redo 7)



Week10 :
13)(continue and finish)

August 16
Suggested 'pencils down' date. Take to scrub code, write tests, improve
documentation, etc.


End : August 26

Waiting for your valuable feedback,
Regards,
Mougey Camille

------------------------------------------------------------------------------
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
_______________________________________________
Apertium-stuff mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/apertium-stuff

Reply via email to