[Fedora-trans-ar] Do we have any Web Developers within?

[Maha Helwa]

We need 3 screens to be developed, each will have a set of functionalities 
that could be clear in the interface or exist behind the scenes; the 
usecases I guess…

 *1. Translator Screen:*

[Required]> Display latest approved translation. 

[Required]> Editing the translation.

[Required]> Filtering the display of strings; All, Untranslated, fuzzy 
Strings. 

[Required]> Save the modified translation into DB. 

 *2. Maintainer Screen: *

Maintainer is basically a translator so it should have the same 
functionality exists in the Translator page beside some extra functionality:

[Required]> Display all modified strings that other translator changed; the 
strings will be in pending state till maintainer approved them or discard 
them, so there will be kind of status flag describe the state of each 
modified string.

[Required]> Either Approve/Discard for each translation per String, and that 
will be reflected on the DB tables.

 *3. System Admin Screen:*

[Required]> Update PO files from CVS side; execute the command:

 "cvs -z9 update translate", and the PO will set somewhere on Arabic-Fedora 
server side.

[Required]> Synchronize DB with PO Files; it's not completely sync, that 
means just updating the DB with "new strings" that recently added to any po 
files, and this will need to go through all PO files and parsing each one of 
them, check if the current string already exists in the db table or not, if 
not then insert a new record.

[Required]> Rebuild or reconstruct PO Files again, that will need looking up 
for approved strings in the DB, and pickup each one of these final versions 
and put them with the same order into a newly PO file, the non-modified 
strings will be kept unchanged.

[Optional]> Registration form, don't know if is it applicable or not, but it 
will be nice to do such thing, the user won't have to go to 
fedora.redhat.com <http://fedora.redhat.com> anymore, create the ssh keys 
and fill the registration form and wait for a confirmation upon his/her 
request and so on.. we will block the user from doing or seeing this part, 
and in turn a form on Arabic-fedora web-site will do the rest of the job.. J.. 
Instead the system will create a random SSH key and somehow actually J don't 
know how right now.. a request has to be sent programmatically from 
arabic-fedora server to one of the redhat servers with the same listed 
parameters in their registration form. I don't know what about its 
implementation besides I think its not required... so anyway It's not in 
scope right now..

 Well.. I want to talk about the scenarios but don't know… I get tired and 
don't know am I saying something so clear or too much ambiguous.

 About the components I'll be using in the implementation:

1. Am going to use servlets and jsps. am not going to use PHP so instead 
I'll be using Jsps for the views or the interface..

2. also am going to use a framework called "struts" it's kind of MVC (Model, 
View, Controller) design pattern..it will be easier for me to process the 
coming requests to the web server and deal with the deal with db sqls and 
call the appropriate view (interface) according to current model status..lol I 
don't' know if we should speak to that level of details.. I don't mind but I 
hope u still reading up till now. Anyway I get used to use struts.. that's 
why am choosing it…lol

 About the DB tables.. I was thinking it will be just couple of table 2 
tables right now.. 

1. One to be filled up from PO files after each updation.. I called it 
"Origin_Translation" table…not so descriptive J..any better suggestions.. 
 
2. the other one holds all suggested translations for each modified string.. 
it's a transaction table.. and store who did apply this translation per 
record.."Suggested_Translation" table.


Bas keda.. had fahem haga!!
 
Maha.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/trans-ar/attachments/20050821/dd88553b/attachment.html