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