Do we have any Web Developers within?

[Sherif Abdelgawad]

$SUBJECT

I have noticed that we have a lot of ppl here. Some of them shy to speak. A lot
with no experience with CVS and Linux at all. Yet, they would joined the
mailing list.

I was thinking for a way to get the shy people to participate in more effective
way without trying to educate them how to use CVS, and/or educate them how to
use Linux.

So here is what I am thinking about.

CVS Mirror to match what is on Red Hat translation servers. That will give us:

- Control over our members
- Update our Keys
- Better, and faster management
- Central update process

Now to my next idea as we gonna have our own CVS, and files available to us
on filesystem where the web interface has access to it.

I was wondering if we can develop something that parse all the CVS files, give
template form that allow ppl who has no experience to just fill in a form and
submit this translation.

The point here is:

- Need PHP to parse and format the forms
- PHP submit the changes to MySQL DB, waiting for Maintainer approval
- Maintainer check the translation and click approve, hence the updates
  goes to the PO files on the file system, and trigger a CVS sync to Red Hat
  Server.

So the question is: Do we have any PHP/MySQL developer here who can try to
accomplish the above?

Thanks

Sherif

[Eng. Maha Hulwa]

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.

[Sherif Abdelgawad]

Maha,
   Good start. Here is my comments:

We can have one screen, yet what he/she can do within the screen is different.
So basically, based on user level (hence, you need to authenticate users)
you can have three access levels:

- Guest, can view browser, editing is not avilable for him.
- Contributor, he will be allowed to "edit", and "submit" changes,
  mark strings "fuzzy" or remove "fuzzy" marks" .. His entries
should 
be kept in
  different "proposed" table till a Maintainer "approve" it and move
it to
"current"
  table.

- Maintainer, he will be view current approved, and "proposed" changes, hence
  he can "approve" and "merge" or "discard" the new
"proposed" change making it
"current"
  or send it to "trash"

- System Admin Screen: Maintaince tasks, like populate DB with data 
from files,
  backup db, dump DB, restore, ..etc.

  Functionality will be allowed to him:

  a. Parse the files on server (that will be on same server your code will run
on),
     and "insert" these parsed files into the "DB". This will be
needed 
at start
     time to "take from files into DB", also will be needed if we need a fresh
     copy from the files on disk to DB in case something happened and 
we need to
     load files again.

  b. Compile or generate "PO" file again from DB and store it to file in hard
disk,
     or update the hard copy so we can later take this and sync it back to CVS.

  So basically ability per file to load from the copy on the hard, or generate
  and compose the file from the DB back to the hard.

  c. Backup DB and Restor DB from SQL files , add users, remove users, change
passwords
     for users ..etc. Create translation project, define file to maintain, and
locations.

Both Contributor and Maintainer views should be able to ask for "show all the
file", or "show me fuzzy" only or "show untranslated". Maintainer
should be
able to also show "show submited"
strings waiting for approval so he can see these strings on one place.

To do that , you will need in your table to have a flag describe the state of
each
string.

And forget about sync`ing with CVS, and CVS commands. As long as it save files
in a file
somewhere we can define. Admin can checkout files, use your JAVA to manipulate
files,
then he can check in files manualy later. Or an automated task to do 
that can be
done later.

How does that sound ? Too much, sa7 ? :)) LOL I think it would be the perfect
product that you can sell for anyone afterwords to help them translate or
contribute in open source ;-)

Sherif

[Sherif Abdelgawad]

Just occurred to me that you may already have started doing things!
If you are, just make to include the functionalities, don't redo
anything to match what I am suggesting :)

Sherif


Quoting sabdelg(a)redhat.com:

>  Maha,
>    Good start. Here is my comments:
>
>  We can have one screen, yet what he/she can do within the screen is 
>  different.
>  So basically, based on user level (hence, you need to authenticate users)
>  you can have three access levels:
>
>  - Guest, can view browser, editing is not avilable for him.
>  - Contributor, he will be allowed to "edit", and "submit" changes,
>   mark strings "fuzzy" or remove "fuzzy" marks" .. His entries
> should 
>  be kept in
>   different "proposed" table till a Maintainer "approve" it and move
> it to
>  "current"
>   table.
>
>  - Maintainer, he will be view current approved, and "proposed" changes, hence
>   he can "approve" and "merge" or "discard" the new
> "proposed" change 
>  making it
>  "current"
>   or send it to "trash"
>
>  - System Admin Screen: Maintaince tasks, like populate DB with data 
>  from files,
>   backup db, dump DB, restore, ..etc.
>
>   Functionality will be allowed to him:
>
>   a. Parse the files on server (that will be on same server your code will run
>  on),
>      and "insert" these parsed files into the "DB". This will be 
>  needed at start
>      time to "take from files into DB", also will be needed if we need a fresh
>      copy from the files on disk to DB in case something happened and 
>  we need to
>      load files again.
>
>   b. Compile or generate "PO" file again from DB and store it to file in hard
>  disk,
>      or update the hard copy so we can later take this and sync it 
>  back to CVS.
>
>   So basically ability per file to load from the copy on the hard, or generate
>   and compose the file from the DB back to the hard.
>
>   c. Backup DB and Restor DB from SQL files , add users, remove users, change
>  passwords
>      for users ..etc. Create translation project, define file to maintain, and
>  locations.
>
>  Both Contributor and Maintainer views should be able to ask for "show all the
>  file", or "show me fuzzy" only or "show untranslated".
> Maintainer should be
>  able to also show "show submited"
>  strings waiting for approval so he can see these strings on one place.
>
>  To do that , you will need in your table to have a flag describe the state of
>  each
>  string.
>
>  And forget about sync`ing with CVS, and CVS commands. As long as it 
>  save files
>  in a file
>  somewhere we can define. Admin can checkout files, use your JAVA to 
>  manipulate
>  files,
>  then he can check in files manualy later. Or an automated task to do 
>  that can be
>  done later.
>
>  How does that sound ? Too much, sa7 ? :)) LOL I think it would be the perfect
>  product that you can sell for anyone afterwords to help them translate or
>  contribute in open source ;-)
>
>  Sherif
>
>
>
>  --
>  Fedora-trans-ar mailing list
>  Fedora-trans-ar(a)redhat.com
>  http://www.redhat.com/mailman/listinfo/fedora-trans-ar
>

[Eng. Maha Hulwa]

Sherif..i really want it to reply when i have something to test or start 
with..lol...
yeah sure it's going to be a magnificent utility once we finish :)).. and 
YES yes it's too much for time being because i can't imagine i can do it.. 

Currently am working on the db..data manipulation and sql statements.. I 
find a very popular issue...arabic text in the db on mysql am using mySql 
4.1.12a..
The problem now the arabized translation not inserted properly into the 
table.. and accordingly not retrieved properly to the user.. i did alter the 
table definition to accept utf-8 on certain column.. but no use.. still 
there is a problem :)) am going to search more but anyone know about this?!

Sherif.. wow.. the features you are saying very lovely.. but i have to say 
is too much to me.. am going to do it but not sure totally about when am 
going to do it and if i can do it or not.. but I'll give a try.. 

Anyway.. i hope by the end of next week.. we could have this:
>  have screens on arabic-fedora by which you can retrieve/modify the 
translation.. for (Guest, Contributor and the maintainer users).
>  Submit your changes and apply them on the db. 
So till i find
out how i can populate the data from PO file and take it back 
from db.. you can use these screens and ur translation will be kept into db 
not on po files or we can do it manually..LOL the data canl be populated 
into db manually not by insert statement, but by load statement.. that loads 
the data from txt file into db table but according to table description; the 
column orders. Anyway..

It's looooong way.. not sure am wasting more time that we already need it or 
it will help in future.. don't know when i can finish but it' will be 
perfect if we can do it :)

Anyway sorry for the late reply :)) i should stop blaming everyone :)

Maha..



On 8/24/05, sabdelg(a)redhat.com <sabdelg(a)redhat.com&gt; wrote:
>  
>  Maha,
>  Good start. Here is my comments:
>  
>  We can have one screen, yet what he/she can do within the screen is 
>  different.
>  So basically, based on user level (hence, you need to authenticate users)
>  you can have three access levels:
>  
>  - Guest, can view browser, editing is not avilable for him.
>  - Contributor, he will be allowed to "edit", and "submit" changes,
>  mark strings "fuzzy" or remove "fuzzy" marks" .. His entries
> should
>  be kept in
>  different "proposed" table till a Maintainer "approve" it and move it
> to
>  "current"
>  table.
>  
>  - Maintainer, he will be view current approved, and "proposed" changes, 
>  hence
>  he can "approve" and "merge" or "discard" the new
> "proposed" change making 
>  it
>  "current"
>  or send it to "trash"
>  
>  - System Admin Screen: Maintaince tasks, like populate DB with data
>  from files,
>  backup db, dump DB, restore, ..etc.
>  
>  Functionality will be allowed to him:
>  
>  a. Parse the files on server (that will be on same server your code will 
>  run
>  on),
>  and "insert" these parsed files into the "DB". This will be needed
>  at start
>  time to "take from files into DB", also will be needed if we need a fresh
>  copy from the files on disk to DB in case something happened and
>  we need to
>  load files again.
>  
>  b. Compile or generate "PO" file again from DB and store it to file in 
>  hard
>  disk,
>  or update the hard copy so we can later take this and sync it back to CVS.
>  
>  So basically ability per file to load from the copy on the hard, or 
>  generate
>  and compose the file from the DB back to the hard.
>  
>  c. Backup DB and Restor DB from SQL files , add users, remove users, 
>  change
>  passwords
>  for users ..etc. Create translation project, define file to maintain, and
>  locations.
>  
>  Both Contributor and Maintainer views should be able to ask for "show all 
>  the
>  file", or "show me fuzzy" only or "show untranslated".
> Maintainer should 
>  be
>  able to also show "show submited"
>  strings waiting for approval so he can see these strings on one place.
>  
>  To do that , you will need in your table to have a flag describe the state 
>  of
>  each
>  string.
>  
>  And forget about sync`ing with CVS, and CVS commands. As long as it save 
>  files
>  in a file
>  somewhere we can define. Admin can checkout files, use your JAVA to 
>  manipulate
>  files,
>  then he can check in files manualy later. Or an automated task to do
>  that can be
>  done later.
>  
>  How does that sound ? Too much, sa7 ? :)) LOL I think it would be the 
>  perfect
>  product that you can sell for anyone afterwords to help them translate or
>  contribute in open source ;-)
>  
>  Sherif
>  
>  
>  
>

[Eng. Maha Hulwa]

Ah.. there is other issue.. i forgot to speak about it..
do we have multiple maintainers here.. let me say.. you sherif and munzir 
both of you are maintainers and me and ghoniem are translators.. if me and 
ghoniem translate a string differently that's probably could happen.. then 
munzir did accept my translation and you accept ghoniem's translation.. 
which the final one should be taken? 
Or we shouldn't consider this case right now and let's assume there is only 
one maintainer in the system!

Maha.

On 8/26/05, Maha Helwa <ms.helwa(a)gmail.com&gt; wrote:
>  
>  Sherif..i really want it to reply when i have something to test or start 
>  with..lol...
>  yeah sure it's going to be a magnificent utility once we finish :)).. and 
>  YES yes it's too much for time being because i can't imagine i can do it.. 
>  
>  Currently am working on the db..data manipulation and sql statements.. I 
>  find a very popular issue...arabic text in the db on mysql am using mySql 
>  4.1.12a..
>  The problem now the arabized translation not inserted properly into the 
>  table.. and accordingly not retrieved properly to the user.. i did alter the 
>  table definition to accept utf-8 on certain column.. but no use.. still 
>  there is a problem :)) am going to search more but anyone know about this?!
>  
>  Sherif.. wow.. the features you are saying very lovely.. but i have to say 
>  is too much to me.. am going to do it but not sure totally about when am 
>  going to do it and if i can do it or not.. but I'll give a try.. 
>  
>  Anyway.. i hope by the end of next week.. we could have this:
>  > have screens on arabic-fedora by which you can retrieve/modify the 
>  translation.. for (Guest, Contributor and the maintainer users).
>  > Submit your changes and apply them on the db.
>  So till i find out how i can populate the data from PO file and take it 
>  back from db.. you can use these screens and ur translation will be kept 
>  into db not on po files or we can do it manually..LOL the data canl be 
>  populated into db manually not by insert statement, but by load statement.. 
>  that loads the data from txt file into db table but according to table 
>  description; the column orders. Anyway..
>  
>  It's looooong way.. not sure am wasting more time that we already need it 
>  or it will help in future.. don't know when i can finish but it' will be 
>  perfect if we can do it :)
>  
>  Anyway sorry for the late reply :)) i should stop blaming everyone :)
>  
>  Maha..
>  
>  
>  
>  On 8/24/05, sabdelg(a)redhat.com <sabdelg(a)redhat.com&gt; wrote: 
>  > 
>  > Maha,
>  > Good start. Here is my comments:
>  > 
>  > We can have one screen, yet what he/she can do within the screen is 
>  > different. 
>  > So basically, based on user level (hence, you need to authenticate 
>  > users)
>  > you can have three access levels:
>  > 
>  > - Guest, can view browser, editing is not avilable for him.
>  > - Contributor, he will be allowed to "edit", and "submit"
> changes, 
>  > mark strings "fuzzy" or remove "fuzzy" marks" .. His
> entries should
>  > be kept in
>  > different "proposed" table till a Maintainer "approve" it and
> move it to
>  > "current" 
>  > table.
>  > 
>  > - Maintainer, he will be view current approved, and "proposed" changes, 
>  > hence
>  > he can "approve" and "merge" or "discard" the new
> "proposed" change 
>  > making it 
>  > "current"
>  > or send it to "trash"
>  > 
>  > - System Admin Screen: Maintaince tasks, like populate DB with data
>  > from files,
>  > backup db, dump DB, restore, ..etc.
>  > 
>  > Functionality will be allowed to him: 
>  > 
>  > a. Parse the files on server (that will be on same server your code will 
>  > run
>  > on),
>  > and "insert" these parsed files into the "DB". This will be
> needed
>  > at start
>  > time to "take from files into DB", also will be needed if we need a 
>  > fresh 
>  > copy from the files on disk to DB in case something happened and
>  > we need to
>  > load files again.
>  > 
>  > b. Compile or generate "PO" file again from DB and store it to file in 
>  > hard
>  > disk,
>  > or update the hard copy so we can later take this and sync it back to 
>  > CVS.
>  > 
>  > So basically ability per file to load from the copy on the hard, or 
>  > generate
>  > and compose the file from the DB back to the hard. 
>  > 
>  > c. Backup DB and Restor DB from SQL files , add users, remove users, 
>  > change
>  > passwords
>  > for users ..etc. Create translation project, define file to maintain, 
>  > and
>  > locations.
>  > 
>  > Both Contributor and Maintainer views should be able to ask for "show 
>  > all the 
>  > file", or "show me fuzzy" only or "show untranslated".
> Maintainer should 
>  > be
>  > able to also show "show submited"
>  > strings waiting for approval so he can see these strings on one place. 
>  > 
>  > To do that , you will need in your table to have a flag describe the 
>  > state of
>  > each
>  > string.
>  > 
>  > And forget about sync`ing with CVS, and CVS commands. As long as it save 
>  > files
>  > in a file
>  > somewhere we can define. Admin can checkout files, use your JAVA to 
>  > manipulate 
>  > files,
>  > then he can check in files manualy later. Or an automated task to do
>  > that can be
>  > done later.
>  > 
>  > How does that sound ? Too much, sa7 ? :)) LOL I think it would be the 
>  > perfect
>  > product that you can sell for anyone afterwords to help them translate 
>  > or 
>  > contribute in open source ;-)
>  > 
>  > Sherif
>  > 
>  > 
>  > 
>  > 
>

[Eng. Maha Hulwa]

well, if no one read the prev email or didn't get my point, it's okay.. 
there shouldn't be a problem aslan as i thought :))

On 8/26/05, Maha Helwa <ms.helwa(a)gmail.com&gt; wrote: 
>  
>  Ah.. there is other issue.. i forgot to speak about it..
>  do we have multiple maintainers here.. let me say.. you sherif and munzir 
>  both of you are maintainers and me and ghoniem are translators.. if me and 
>  ghoniem translate a string differently that's probably could happen.. then 
>  munzir did accept my translation and you accept ghoniem's translation.. 
>  which the final one should be taken? 
>  Or we shouldn't consider this case right now and let's assume there is 
>  only one maintainer in the system!
>  
>  Maha. 
>  
>  On 8/26/05, Maha Helwa <ms.helwa(a)gmail.com&gt; wrote: 
>  > 
>  > Sherif..i really want it to reply when i have something to test or start 
>  > with..lol...
>  > yeah sure it's going to be a magnificent utility once we finish :)).. 
>  > and YES yes it's too much for time being because i can't imagine i can do 
>  > it.. 
>  > 
>  > Currently am working on the db..data manipulation and sql statements.. I 
>  > find a very popular issue...arabic text in the db on mysql am using mySql 
>  > 4.1.12a..
>  > The problem now the arabized translation not inserted properly into the 
>  > table.. and accordingly not retrieved properly to the user.. i did alter the 
>  > table definition to accept utf-8 on certain column.. but no use.. still 
>  > there is a problem :)) am going to search more but anyone know about this?!
>  > 
>  > Sherif.. wow.. the features you are saying very lovely.. but i have to 
>  > say is too much to me.. am going to do it but not sure totally about when am 
>  > going to do it and if i can do it or not.. but I'll give a try.. 
>  > 
>  > Anyway.. i hope by the end of next week.. we could have this:
>  > > have screens on arabic-fedora by which you can retrieve/modify the 
>  > translation.. for (Guest, Contributor and the maintainer users).
>  > > Submit your changes and apply them on the db.
>  > So till i find out how i can populate the data from PO file and take it 
>  > back from db.. you can use these screens and ur translation will be kept 
>  > into db not on po files or we can do it manually..LOL the data canl be 
>  > populated into db manually not by insert statement, but by load statement.. 
>  > that loads the data from txt file into db table but according to table 
>  > description; the column orders. Anyway..
>  > 
>  > It's looooong way.. not sure am wasting more time that we already need 
>  > it or it will help in future.. don't know when i can finish but it' will be
>
>  > perfect if we can do it :)
>  > 
>  > Anyway sorry for the late reply :)) i should stop blaming everyone :)
>  > 
>  > Maha.. 
>  > 
>  > 
>  > 
>  > On 8/24/05, sabdelg(a)redhat.com < sabdelg(a)redhat.com&gt; wrote: 
>  > > 
>  > > Maha,
>  > > Good start. Here is my comments:
>  > > 
>  > > We can have one screen, yet what he/she can do within the screen is 
>  > > different. 
>  > > So basically, based on user level (hence, you need to authenticate 
>  > > users)
>  > > you can have three access levels:
>  > > 
>  > > - Guest, can view browser, editing is not avilable for him.
>  > > - Contributor, he will be allowed to "edit", and "submit"
> changes, 
>  > > mark strings "fuzzy" or remove "fuzzy" marks" .. His
> entries should
>  > > be kept in
>  > > different "proposed" table till a Maintainer "approve" it
> and move it 
>  > > to
>  > > "current" 
>  > > table.
>  > > 
>  > > - Maintainer, he will be view current approved, and "proposed" 
>  > > changes, hence
>  > > he can "approve" and "merge" or "discard" the new
> "proposed" change 
>  > > making it 
>  > > "current"
>  > > or send it to "trash"
>  > > 
>  > > - System Admin Screen: Maintaince tasks, like populate DB with data
>  > > from files,
>  > > backup db, dump DB, restore, ..etc.
>  > > 
>  > > Functionality will be allowed to him: 
>  > > 
>  > > a. Parse the files on server (that will be on same server your code 
>  > > will run
>  > > on),
>  > > and "insert" these parsed files into the "DB". This will be
> needed
>  > > at start
>  > > time to "take from files into DB", also will be needed if we need a 
>  > > fresh 
>  > > copy from the files on disk to DB in case something happened and
>  > > we need to
>  > > load files again.
>  > > 
>  > > b. Compile or generate "PO" file again from DB and store it to file
> in 
>  > > hard
>  > > disk,
>  > > or update the hard copy so we can later take this and sync it back to 
>  > > CVS.
>  > > 
>  > > So basically ability per file to load from the copy on the hard, or 
>  > > generate
>  > > and compose the file from the DB back to the hard. 
>  > > 
>  > > c. Backup DB and Restor DB from SQL files , add users, remove users, 
>  > > change
>  > > passwords
>  > > for users ..etc. Create translation project, define file to maintain, 
>  > > and
>  > > locations.
>  > > 
>  > > Both Contributor and Maintainer views should be able to ask for "show 
>  > > all the 
>  > > file", or "show me fuzzy" only or "show untranslated".
> Maintainer 
>  > > should be
>  > > able to also show "show submited"
>  > > strings waiting for approval so he can see these strings on one place. 
>  > > 
>  > > 
>  > > To do that , you will need in your table to have a flag describe the 
>  > > state of
>  > > each
>  > > string.
>  > > 
>  > > And forget about sync`ing with CVS, and CVS commands. As long as it 
>  > > save files
>  > > in a file
>  > > somewhere we can define. Admin can checkout files, use your JAVA to 
>  > > manipulate 
>  > > files,
>  > > then he can check in files manualy later. Or an automated task to do
>  > > that can be
>  > > done later.
>  > > 
>  > > How does that sound ? Too much, sa7 ? :)) LOL I think it would be the 
>  > > perfect
>  > > product that you can sell for anyone afterwords to help them translate 
>  > > or 
>  > > contribute in open source ;-)
>  > > 
>  > > Sherif
>  > > 
>  > > 
>  > > 
>  > > 
>  > 
>

[Mohammad Ghoniem]

Salâms,

Maha Helwa a écrit :

>  It's looooong way.. not sure am wasting more time that we already
> need 
>  it or it will help in future.. don't know when i can finish but it' 
>  will be perfect if we can do it :) 
By the end of the upcoming week, I hope I will get some spare time to 
help you in shâ'a Allâh. I have decent java skills (including some JDBC) 
but have not touched any jsp per se before. If you can put together some 
specs and split the work, I may help.

Salâm

Mohammad

[Eng. Maha Hulwa]

Okay.. let's see after one week what we have.. Are you using C these days or 
knowing it well ?! :))
Ghoniem.. don't u know about that Arabic issue in the db.. how to insert 
them with the right encoding and how to read them properly?

On 8/26/05, Mohammad Ghoniem <mohammad.ghoniem(a)univ-ubs.fr&gt; wrote:
>  
>  Salâms,
>  
>  Maha Helwa a écrit :
>  
>  > It's looooong way.. not sure am wasting more time that we already need
>  > it or it will help in future.. don't know when i can finish but it'
>  > will be perfect if we can do it :)
>  
>  By the end of the upcoming week, I hope I will get some spare time to
>  help you in shâ'a Allâh. I have decent java skills (including some JDBC)
>  but have not touched any jsp per se before. If you can put together some
>  specs and split the work, I may help.
>  
>  Salâm
>  
>  Mohammad
>  
>  --
>  Fedora-trans-ar mailing list
>  Fedora-trans-ar(a)redhat.com
>  http://www.redhat.com/mailman/listinfo/fedora-trans-ar
>

[Mohammad Ghoniem]

Maha Helwa wrote:

>  Ghoniem.. don't u know about that Arabic issue in the db.. how to
>
>  insert them with the right encoding and how to read them properly? 
As far as I know, the db needs to be in UTF-8 to handle Arabic 
correctly. Try creating your db in UTF-8 from the beginning i.e. do not 
alter the tables to be in UTF-8 afterwards. I will be doing some tests 
in shâ'a Allâh.

salâm

[Eng. Maha Hulwa]

YEs.. look ghoniem.. as u saying you have to define the table or specific 
column with certain encoding which is utf-8 to be able to store arabic or 
whatever.. 
the problem was i couldn't use simple sql statement.. now the other issue 
that when i display the results on browser i have to change the encoding to 
"Arabic(Windows)" to see arabic letter.. the problem now from the JSps side 
not db anymore.. although i set metadata and charset with utf-8 but 
something obvious i didn't notice till now :-))
 MAha.

 On 9/3/05, Mohammad Ghoniem <Mohammad.Ghoniem(a)univ-ubs.fr&gt; wrote: 
>  
>  Maha Helwa wrote:
>  
>  > Ghoniem.. don't u know about that Arabic issue in the db.. how to
>  > insert them with the right encoding and how to read them properly?
>  
>  As far as I know, the db needs to be in UTF-8 to handle Arabic
>  correctly. Try creating your db in UTF-8 from the beginning i.e. do not
>  alter the tables to be in UTF-8 afterwards. I will be doing some tests
>  in shâ'a Allâh.
>  
>  salâm
>  
>  --
>  Fedora-trans-ar mailing list
>  Fedora-trans-ar(a)redhat.com
>  http://www.redhat.com/mailman/listinfo/fedora-trans-ar
>

[Sherif AbdElGawad]

Sorry guys I was away for sometime .. So what is the status here both Maha & Ghoniem
?
We can discuss how the DB should be if you guys want.

Sherif


  YEs.. look ghoniem.. as u saying you have to define the table or specific column with
certain encoding which is utf-8 to be able to store arabic or whatever.. 
  the problem was i couldn't use simple sql statement.. now the other issue that when
i display the results on browser i have to change the encoding to
"Arabic(Windows)" to see arabic letter.. the problem now from the JSps side not
db anymore.. although i set metadata and charset with utf-8 but something obvious i
didn't notice till now :-)) 

  MAha.

   
  On 9/3/05, Mohammad Ghoniem <Mohammad.Ghoniem(a)univ-ubs.fr&gt; wrote: 
    Maha Helwa wrote:

>  Ghoniem.. don't u know about that Arabic issue in the db.. how
> to
>  insert them with the right encoding and how to read them properly?  
    As far as I know, the db needs to be in UTF-8 to handle Arabic
    correctly. Try creating your db in UTF-8 from the beginning i.e. do not
    alter the tables to be in UTF-8 afterwards. I will be doing some tests
    in shâ'a Allâh.

    salâm

    --
    Fedora-trans-ar mailing list
    Fedora-trans-ar(a)redhat.com
    http://www.redhat.com/mailman/listinfo/fedora-trans-ar 





------------------------------------------------------------------------------


  --
  Fedora-trans-ar mailing list
  Fedora-trans-ar(a)redhat.com
  http://www.redhat.com/mailman/listinfo/fedora-trans-ar

[Mohammad Ghoniem]

Salâms,

Sherif Abdelgawad a écrit :

>  Sorry guys I was away for sometime .. So what is the status here both
>
>  Maha & Ghoniem ?
>  We can discuss how the DB should be if you guys want.
>    

1- It would be helpful if a wiki page could gather whatever is decided 
concerning this project.
2- We should feed it with the different use cases identified so far. For 
example, do we take into account the possible insertion of new strings 
in existing po files ? (This impacts the numeric ids suggested by maha 
to track the order of strings within files...)
3- We should discuss and write down the way the DB is laid out.
4- I did not make any progress on the parser since the first draft. It 
still lacks a couple of features, e.g. not all header data are parsed.I 
have some priority issues to sort out in the next couple of days in 
shâ'a Allâh. Please bear with me.

Salâm

Mohammad

[Eng. Maha Hulwa]

On 9/7/05, Mohammad Ghoniem <mohammad.ghoniem(a)univ-ubs.fr&gt; wrote:
>  
>  Salâms,
>  
>  Sherif Abdelgawad a écrit :
>  
>  > Sorry guys I was away for sometime .. So what is the status here both
>  > Maha & Ghoniem ?
>  > We can discuss how the DB should be if you guys want.
>  >
>   
:)) isA..


>  1- It would be helpful if a wiki page could gather whatever is
> decided
>  concerning this project. 

mmmmm... :))) don't know but maybe we should in the spare time.. 

2- We should feed it with the different use cases identified so far. For
>  example, do we take into account the possible insertion of new
> strings
>  in existing po files ? (This impacts the numeric ids suggested by maha
>  to track the order of strings within files...) 

?? mesh fahmah.. what do u mean.. the strings orders will help when u 
collect the approved strings from the db and put it back in PO files.. 

3- We should discuss and write down the way the DB is laid out.


HADER... I will isA...

4- I did not make any progress on the parser since the first draft. It
>  still lacks a couple of features, e.g. not all header data are
> parsed.I
>  have some priority issues to sort out in the next couple of days in
>  shâ'a Allâh. Please bear with me. 

Don't say that because we suppose to bear each other.. if we didn't there 
won't be anything eventually.

Salâm
>  
>  Mohammad 

WS
Maha.

[Mohammad Ghoniem]

Salâms,

Maha Helwa wrote:

>      1- It would be helpful if a wiki page could gather whatever is
> decided
>      concerning this project. 
>
>
>
>  mmmmm... :))) don't know but maybe we should in the spare time.. 
Everything is done in our spare time. wallâ eih ? :)

>  2- We should feed it with the different use cases identified so far.
> For
>
>      example, do we take into account the possible insertion of new strings
>      in existing po files ? (This impacts the numeric ids suggested by maha
>      to track the order of strings within files...)
>
>
>  ?? mesh fahmah..  what do u mean.. the  strings orders will help  when 
>  u  collect the approved strings from the db and put it back in PO files.. 
I- You are the one who mentionned numeric ids, right ? :)
II- We must decide whether the order of strings is meaningful / useful 
within po files ? If this is the case, this order must be known and 
retained when we pull the data out of the database.

>  3- We should discuss and write down the way the DB is laid out.
>
>  HADER... I will isA... 
shukran ! :)

Mohammad

[Eng. Maha Hulwa]

LOL.. howa ana radi daye2ak ya ghoneim ?!
anyway.. we discuss these things later.. i'll reply when i feel much better 
than now :))

On 9/7/05, Mohammad Ghoniem <Mohammad.Ghoniem(a)univ-ubs.fr&gt; wrote:
>  
>  Salâms,
>  
>  Maha Helwa wrote:
>  
>  > 1- It would be helpful if a wiki page could gather whatever is decided
>  > concerning this project.
>  >
>  >
>  >
>  > mmmmm... :))) don't know but maybe we should in the spare time..
>  
>  Everything is done in our spare time. wallâ eih ? :) 
>  2- We should feed it with the different use cases identified so far.
> For
>  >
>  > example, do we take into account the possible insertion of new strings
>  > in existing po files ? (This impacts the numeric ids suggested by maha
>  > to track the order of strings within files...)
>  >
>  >
>  > ?? mesh fahmah.. what do u mean.. the strings orders will help when
>  > u collect the approved strings from the db and put it back in PO files..
>  
>  I- You are the one who mentionned numeric ids, right ? :)
>  II- We must decide whether the order of strings is meaningful / useful
>  within po files ? If this is the case, this order must be known and
>  retained when we pull the data out of the database.
>  
>  > 3- We should discuss and write down the way the DB is laid out.
>  >
>  > HADER... I will isA...
>  
>  shukran ! :)
>  
>  Mohammad
>  
>  
>  --
>  Fedora-trans-ar mailing list
>  Fedora-trans-ar(a)redhat.com
>  http://www.redhat.com/mailman/listinfo/fedora-trans-ar
>

[Eng. Maha Hulwa]

>  >
>  > example, do we take into account the possible insertion of new strings
>  > in existing po files ? (This impacts the numeric ids suggested by maha
>  > to track the order of strings within files...)
>  >
>  >
>  > ?? mesh fahmah.. what do u mean.. the strings orders will help when
>  > u collect the approved strings from the db and put it back in PO files..
>  
>  I- You are the one who mentionned numeric ids, right ? :)
>  II- We must decide whether the order of strings is meaningful / useful
>  within po files ? If this is the case, this order must be known and
>  retained when we pull the data out of the database. 
 Yes Ghoniem.. it has a meaning.. my point is instead of create a new file 
and collect the approved strings + unmodified string to buildup a new PO 
file.. i just pickup the approved strings and update the translation of 
these strings in the PO file.. so i need to know where are these strings 
located in the PO file.. the 5th.. 25th or 32th string or whatever..this 
number i need it when i update the PO files again from the db.. does this 
answer your question? Ghoniem?!

>  3- We should discuss and write down the way the DB is laid out.
>  >
>  > HADER... I will isA...
>  
>  shukran ! :) 
 Afwan :)) dont' worry.. i'll reply.. am not in mood :)) sorry.

[Mohammad Ghoniem]

Salâms,

Attached is a java parser that loads data from a PO file into an 
instance of POFile (an ArrayList of POMessages). For now, a POMessage 
has three strings : comments, msgid and msgstr. If necessary, we can 
easily add a unique numeric ID or a hashcode to identify each message. 
Having read the specs of PO files sent by Sherif, I realized that the 
header of each PO file is actually a POMessage, which simplified the 
previous code. The parser now takes into account all types of comments + 
multiple-line strings.

It handles Arabic strings correctly using the UTF-8 charset. Other 
charsets can be passed to the parser. Therefore all languages supported 
by java can be handled by this parser. Please test it on your side and 
give me feedback.

As far as I understand next step would deal with storing and retrieving 
data in/from a database. If so, we need to discuss this point carefully 
to cover all use cases. Here is a small list :
1- From an administrator point of view :
1a- in preparation of a new release, load all PO files into the database.
1b- build up PO files from data stored into the database to ship with an 
upcoming release.

2- From a maintainer/QA operator's point of view :
2a- browse the list of changes made by the translators
2b- validate/invalidate the changes, when a string is validated, it is 
merged with original version.
2c- assign files to translators

3- From a translator's point of view :
3a- browse the list of his/her personal assignments
3b- browse the list of unassigned PO files and take one of them.
3c- work on a given PO file including modifying msgstr strings and the 
flags (fuzzy state) of each message and adding comments
3d- notify the maintainer when his work is done.
3e- the translator's info should be appended automatically to the header 
data.
3f- the translation team should be able to discuss translations through 
some kind of forum related to each PO file. (this is not urgent nor 
mandatory)
3g- translators should have a search facility through some kind of 
glossary, if available. (this is not urgent nor mandatory)

Any other ideas or comments ? :)

Apart from that, can you Sherif enlight us about the lifecycle of a PO 
file in fedora from one release to the next ? What changes can occur ? 
How does this fit in the previous scenarios ?

Salâm

Mohammad

[Eng. Maha Hulwa]

Ghoniem.. this not a complete reply on ur email.. am not feeling well these 
days..
But u've added 3 new ideas:
1> Display the contents of assigned files.. nice one really.
2> Add to Glossary.. or find a word from Glossary.. great idea i like it :)
3> mmm.. online meeting :)) lol.. 
 As i consider them by now as optional functions.. not a core function.. so 
let's keep it into our minds in future till we finish the core function.. 
What's the core functionality..
Well IMHO :))
 System admin:
1> populate the translation strings in the DB from PO files after updating 
them from CVS.
2> updating PO files from DB (Backward.. y3ni).. that means pickup the 
approved strings only from DB
 Translator:
1> Select any module/file to view it's content; retrieve the translation 
strings.from dB
2> Save his modifications he made already made into DB
 Maintainer:
1> the same as the translator.
2> Approve/Discard translation; update the db tables either by update into 
the original table or deleting from the transaction table.
 Viewer; Unregistered User:
1> the same as the translator.
 About DB tables: I've made till now 3 tables:
1> User Details table: this table hold info about each user in the system.. 
username, password, email and his role.. don't remember if there is 
something else.. anyway his/her info.. mel akher.
 The two other tables about the translation strings:
1> Original_Data table: 
 -This table should be populated from POFiles each update made from CVS, the 
new strings& their translation should be inserted into this table. 
 - This table should tell us the status of the strings.. which is modified 
which not, which is translated which is not and which is fuzzy and which is 
not, so let's consider it as a set of ranges you pickup one of these values: 
pending, fuzzy, untranslated or approved string 
 - The data at this table won't be modified till the maintainer accept this 
change; means that the translator won't ever update any record at this 
table.
 the third table
2> Translation_Translations: As the translator can not change in the 
Original_Data table.. his modification would be at another separate table, 
which will hold all the transactions i mean any modifications (s)he made. 
sort of log file of translation strings.
 So this table will hold the following:
1> the translation, we won't repeat any details, just the translation.
2> translator username or his id.
3> the status of each string.. this time it will tells the status of the 
string.. whether or not the maintainer did accept the string& confirm it's 
translation the status will be approved, if not it will be cancelled. other 
than this it will be kept as pending translation.. frankly.. am not sure if 
this column is necessarily or not.. but I'll keep it till i get convinced 
that it should be removed and find it's a redundant data.
  Ghoniem.. something u mention.. am not sure what exactly u meant by.. the 
header is kept a header aaah.. the header if it's a user comment it' would 
be stored into the transaction table.. but the header of the file i don't 
thing there is a need to store it into db.
 Ghoniem am sorry didn't try the code yet.. give me sometime and i'll tell u 
my feedback..
currently am trying to make a very simple framework so we can change the 
pieces after that..
 sorry ppl am not in a good shape these days :)
I'll reply later.. ghoneim.
 Maha.
 On 9/8/05, Mohammad Ghoniem <Mohammad.Ghoniem(a)univ-ubs.fr&gt; wrote: 
>  
>  Salâms,
>  
>  Attached is a java parser that loads data from a PO file into an
>  instance of POFile (an ArrayList of POMessages). For now, a POMessage
>  has three strings : comments, msgid and msgstr. If necessary, we can
>  easily add a unique numeric ID or a hashcode to identify each message.
>  Having read the specs of PO files sent by Sherif, *I realized that the
>  header of each PO file is actually a POMessage*, which simplified the
>  previous code. The parser now takes into account all types of comments +
>  multiple-line strings.
>  
>  It handles Arabic strings correctly using the UTF-8 charset. Other
>  charsets can be passed to the parser. Therefore all languages supported
>  by java can be handled by this parser. Please test it on your side and
>  give me feedback.
>  
>  As far as I understand next step would deal with storing and retrieving
>  data in/from a database. If so, we need to discuss this point carefully
>  to cover all use cases. Here is a small list :
>  1- From an administrator point of view :
>  1a- in preparation of a new release, load all PO files into the database.
>  1b- build up PO files from data stored into the database to ship with an
>  upcoming release.
>  
>  2- From a maintainer/QA operator's point of view :
>  2a- browse the list of changes made by the translators
>  2b- validate/invalidate the changes, when a string is validated, it is
>  merged with original version.
>  2c- assign files to translators
>  
>  3- From a translator's point of view :
>  3a- browse the list of his/her personal assignments
>  3b- browse the list of unassigned PO files and take one of them.
>  3c- work on a given PO file including modifying msgstr strings and the
>  flags (fuzzy state) of each message and adding comments
>  3d- notify the maintainer when his work is done.
>  3e- the translator's info should be appended automatically to the header
>  data.
>  3f- the translation team should be able to discuss translations through
>  some kind of forum related to each PO file. (this is not urgent nor
>  mandatory)
>  3g- translators should have a search facility through some kind of
>  glossary, if available. (this is not urgent nor mandatory)
>  
>  Any other ideas or comments ? :)
>  
>  Apart from that, can you Sherif enlight us about the lifecycle of a PO
>  file in fedora from one release to the next ? What changes can occur ?
>  How does this fit in the previous scenarios ?
>  
>  Salâm
>  
>  Mohammad
>  
>  
>  --
>  Fedora-trans-ar mailing list
>  Fedora-trans-ar(a)redhat.com
>  http://www.redhat.com/mailman/listinfo/fedora-trans-ar
>  
>  
>

[Mohammad Ghoniem]

Maha Helwa wrote:

>  Ghoniem.. something u mention.. am not sure what exactly u meant by..
>
>  the header is kept a header aaah.. the header if it's a user comment 
>  it' would be stored into the transaction table.. but the header of the 
>  file i don't thing there is a need to store it into db. 

Actually, if you open any PO file you have, you will notice that it 
begins with :
1- comment lines holding info like the translator list, the filename etc.
2- an empty msgid string
3- a non empty msgstr with more info about the file (like character 
encoding and the application used to generate it such as kbabel or 
whatever info)

The association (comments, msgid, msgstr) is no less than a PO message. 
Therefore, PO format stores the file info in a regular PO message. There 
is no need to model this differently, parser wise.I don't believe the 
treatment of header data should be different in the database either. But 
we can decide to do that otherwise if we have a valid reason.

>   Ghoniem am sorry didn't try the code yet.. give me sometime and
> i'll 
>  tell u my feedback.. 

Don't worry. ;)

>  currently am trying to make a very simple framework so we can change
>
>  the pieces after that.. 

Besides the parser, is there anything I can do to be of help ?

>  sorry ppl am not in a good shape these days :) 
Take care, there is no rush !

Salâm

Mohammad

[Sherif AbdElGawad]

Ghoniem,
    I did not check your code yet but it really looks good. I will create 
CVS
account for you to check-in your work on arabic-fedora.com isa.
Great work so far :)

OK to the real tasks .. Shall I install tomcat and get your a test page
where you can publish your work there? I can also create Database
for you, give you access to creat tables ..etc.

>  Attached is a java parser that loads data from a PO file into an
>  instance of POFile (an ArrayList of POMessages). For now, a POMessage
>  has three strings : comments, msgid and msgstr. If necessary, we can
>  easily add a unique numeric ID or a hashcode to identify each message.
>  Having read the specs of PO files sent by Sherif, I realized that the
>  header of each PO file is actually a POMessage, which simplified the
>  previous code. The parser now takes into account all types of comments +
>  multiple-line strings. 
Sounds good.

>  It handles Arabic strings correctly using the UTF-8 charset. Other
>  charsets can be passed to the parser. Therefore all languages supported
>  by java can be handled by this parser. Please test it on your side and
>  give me feedback.
>
>  As far as I understand next step would deal with storing and retrieving
>  data in/from a database. If so, we need to discuss this point carefully
>  to cover all use cases. Here is a small list :
>  1- From an administrator point of view :
>  1a- in preparation of a new release, load all PO files into the database.
>  1b- build up PO files from data stored into the database to ship with an
>  upcoming release. 
I would say for the first try-out of the code this is the initial first 
phase
next after we try your code and finish it up.

>  2- From a maintainer/QA operator's point of view :
>  2a- browse the list of changes made by the translators
>  2b- validate/invalidate the changes, when a string is validated, it is
>  merged with original version.
>  2c- assign files to translators 
Also sounds a reasonable step after we finish the important one.

>  3- From a translator's point of view :
>  3a- browse the list of his/her personal assignments
>  3b- browse the list of unassigned PO files and take one of them.
>  3c- work on a given PO file including modifying msgstr strings and the
>  flags (fuzzy state) of each message and adding comments
>  3d- notify the maintainer when his work is done.
>  3e- the translator's info should be appended automatically to the header
>  data.
>  3f- the translation team should be able to discuss translations through
>  some kind of forum related to each PO file. (this is not urgent nor
>  mandatory)
>  3g- translators should have a search facility through some kind of
>  glossary, if available. (this is not urgent nor mandatory)
>
>  Any other ideas or comments ? :)
>  
I guess the flags needed:

- My assigned
- Untranslated strings
- Marked Fuzzy

All other tasks sounds _good_to_have_ :)


>  Apart from that, can you Sherif enlight us about the lifecycle of a
> PO
>  file in fedora from one release to the next ? What changes can occur ?
>  How does this fit in the previous scenarios ? 
Policy is not clear at least for me :) The next thing we will do once we 
have
something usable, we will put it up and go up in the chain by include Sarah
and other translation teams. This can  be a tool that everyone uses it and
can be your contribution and great application for the community.

As far as the lifecycle of a PO file , I am really need to check how things
are done. Maybe we can start a thread to discuss this on fedora-trans-list.

I will start a new broader thread to include other translation team.

Thanks

Sherif

[Munzir Taha]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

في يوم السّبت 29 رجب 1426 10:19, كتب Mohammad Ghoniem:
>  Maha Helwa wrote:
>  > Ghoniem.. don't u know about that Arabic issue in the db.. how to
>  > insert them with the right encoding and how to read them properly?
>
>  As far as I know, the db needs to be in UTF-8 to handle Arabic
>  correctly. Try creating your db in UTF-8 from the beginning i.e. do not
>  alter the tables to be in UTF-8 afterwards. I will be doing some tests
>  in shâ'a Allâh. 
Ghoneim and all, can you clarify this point please?
1. Why creating db in UTF-8 from the beginning is different than altering it 
to be UTF-8 afterwards?
2. I just imported some arabic UTF-8 database sql file to mysql and the php 
script displays them properly (with encoding cp1256). mysql status command 
shows
Server characterset:    latin1
Db     characterset:    latin1
Client characterset:    latin1
Conn.  characterset:    latin1
how come latin1 and still it works is beyond my knowledge. When should I care 
to chnage these defaults then and why? I am not experienced enough here so 
please keep it simple ;)

- -- 
Munzir Taha
Telecommunications and Electronics Engineer
Maintainer of Fedora Arabic Translation Project
https://listman.redhat.com/mailman/listinfo/fedora-trans-ar
Maintainer of the OpenBugs project page at
http://www.arabic-fedora.org/munzir/OpenBugs.html
Master CIW Designer, ICDL, MOUS, Linux+, LPI 101
New Horizons CLC, Riyadh, SA
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.0 (GNU/Linux)
>
> iD8DBQFDIbomOBlicvBnGCERAjCqAKCAyC/dL5etUmVnlchyz4PRxBlVeACfRPwY
> CJN+xwy+O5PgjIzEd4aNPKA=
> =o55V
> -----END PGP SIGNATURE-----

[Eng. Maha Hulwa]

besaraha.. ana mesh merakeza khals..bas i'll tell you what i did..
I think there is a default values for the charset.. which is the key point 
here..
when u use insert statement into a table with arabic data.. and u did not 
adjust the encoding of the table u already define.. the data will be rabish 
not save properly.. that's the problem i faced at the time i sent that 
email..
all u have to do is to define a table taking into consideration the 
charset.. bas da men nahya..
another thing.. when u display that data.. am talking from Jsp side or java 
desktop application side.. you also should take into consideration the 
charset to be UTF-8 or any other arabic encodings bas maybe it won't work 
properly on other enviroments.. 3shan keda utf-8..
 ana mesh merakeza kalas... 
 On 9/9/05, Munzir Taha <munzirtaha(a)gmail.com&gt; wrote: 
>  
>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>  
>  في يوم السّبت 29 رجب 1426 10:19, كتب Mohammad Ghoniem:
>  > Maha Helwa wrote:
>  > > Ghoniem.. don't u know about that Arabic issue in the db.. how to
>  > > insert them with the right encoding and how to read them properly?
>  >
>  > As far as I know, the db needs to be in UTF-8 to handle Arabic
>  > correctly. Try creating your db in UTF-8 from the beginning i.e. do not
>  > alter the tables to be in UTF-8 afterwards. I will be doing some tests
>  > in shâ'a Allâh.
>  
>  Ghoneim and all, can you clarify this point please?
>  1. Why creating db in UTF-8 from the beginning is different than altering 
>  it
>  to be UTF-8 afterwards?
>  2. I just imported some arabic UTF-8 database sql file to mysql and the 
>  php
>  script displays them properly (with encoding cp1256). mysql status command
>  shows
>  Server characterset: latin1
>  Db characterset: latin1
>  Client characterset: latin1
>  Conn. characterset: latin1
>  how come latin1 and still it works is beyond my knowledge. When should I 
>  care
>  to chnage these defaults then and why? I am not experienced enough here so
>  please keep it simple ;)
>  
>  - --
>  Munzir Taha
>  Telecommunications and Electronics Engineer
>  Maintainer of Fedora Arabic Translation Project
>  https://listman.redhat.com/mailman/listinfo/fedora-trans-ar
>  Maintainer of the OpenBugs project page at
>  http://www.arabic-fedora.org/munzir/OpenBugs.html
>  Master CIW Designer, ICDL, MOUS, Linux+, LPI 101
>  New Horizons CLC, Riyadh, SA
> >  -----BEGIN PGP SIGNATURE-----
> >  Version: GnuPG v1.4.0 (GNU/Linux)
> >  
> >  iD8DBQFDIbomOBlicvBnGCERAjCqAKCAyC/dL5etUmVnlchyz4PRxBlVeACfRPwY
> >  CJN+xwy+O5PgjIzEd4aNPKA=
> >  =o55V
> >  -----END PGP SIGNATURE----- 
>  
>  --
>  Fedora-trans-ar mailing list
>  Fedora-trans-ar(a)redhat.com
>  http://www.redhat.com/mailman/listinfo/fedora-trans-ar
>

[Eng. Maha Hulwa]

Ghoniem.. Sorry :)) didn't see last code version.. just run first one.. 
hmmm..
but i notice something want to ask u about it.. i did see at some headers of 
POEntities "python-format" it's not fuzzy flag.. does this kind of header 
really matter.. do we have to skip it!! it's not a user comment.. but don't 
know if we skip it does this means corrupting po file.. do get my point...
 sometime u can try it till i have sometime to talk about.. why dont' u try 
to create po file or update an already existing one.. Using POFile & 
POMessages objects.. or did u already do it :))
 Anyway about my status.. hmm am working on db i've created 4 tables till 
now.. i'll send u the description or declaration of each one later but soon. 
and working on the possible sql that we will need.. i'll explain more 
later.. m3lesh can't do it now :)
 Sherif, would u please install these, if u got a time for installation.. am 
not in hurry.. nothing yet is ready to be deployed.. bas tetsalla keda y3ni 
ay haga (Skip it ya Munzir):
 
>  SDK 1.4 
> Tomcat 4 
> MYSql:
> >Server 4.1.12a choose the recommended version not the latest one; ofcourse  
u
know.
> >Query Browser 1.1.13 
If you going to install them on window i can send u the sources.. but sure u 
won't right!

Anyway.. i prefer not to talk much these days..

[Eng. Maha Hulwa]

Ana kalami f3len mesh mafhoom.. i just read the email and i don't know if u 
understand me or not!! lol.. Munzir dont' comment :)

On 9/11/05, Maha Helwa <ms.helwa(a)gmail.com&gt; wrote: 
>  
>  Ghoniem.. Sorry :)) didn't see last code version.. just run first one.. 
>  hmmm..
>  but i notice something want to ask u about it.. i did see at some headers 
>  of POEntities "python-format" it's not fuzzy flag.. does this kind of
> header 
>  really matter.. do we have to skip it!! it's not a user comment.. but don't 
>  know if we skip it does this means corrupting po file.. do get my point... 
>   sometime u can try it till i have sometime to talk about.. why dont' u 
>  try to create po file or update an already existing one.. Using POFile & 
>  POMessages objects.. or did u already do it :))
>   Anyway about my status.. hmm am working on db i've created 4 tables till 
>  now.. i'll send u the description or declaration of each one later but soon. 
>  and working on the possible sql that we will need.. i'll explain more 
>  later.. m3lesh can't do it now :) 
>   Sherif, would u please install these, if u got a time for installation.. 
>  am not in hurry.. nothing yet is ready to be deployed.. bas tetsalla keda 
>  y3ni ay haga (Skip it ya Munzir):
>   
>  > SDK 1.4
>  
>  >Tomcat 4
>  
>  >MYSql:
>  >>Server 4.1.12a choose the recommended version not the latest one; 
>  ofcourse u know.
>  >>Query Browser 1.1.13
>  
>  If you going to install them on window i can send u the sources.. but sure 
>  u won't right!
>  
>  Anyway.. i prefer not to talk much these days.. 
>  
>

[Mohammad Ghoniem]

Maha Helwa wrote:

>  Ghoniem.. Sorry :)) didn't see last code version.. just run first
>
>  one.. hmmm.. 
hmmm :)

>  but i notice something want to ask u about it..  i did see at some 
>  headers of POEntities "python-format" it's not fuzzy flag.. 
There are several kinds of comments in PO files, according to 
http://www.gnu.org/software/gettext/manual/html_node/gettext_9.html  :
1- translator's comments
2- automatic comments
3- flags (like "fuzzy")
4- references

>  does this kind of header really matter.. do we have to skip it!!
> it's 
>  not a user comment.. but don't know if we skip it does this means 
>  corrupting po file.. do get my point... 
We should keep everything we find in PO files. Our job is translation. :-)

Therefore, all we can do is :
- add translator's comments
-modify flags

We must not modify/delete references nor flags imho.

>  why dont' u try to create po file or update an already existing
> one.. 
>  Using POFile & POMessages objects.. or did u already do it :)) 
In the demo you received, the contents of po files are printed in the 
command-line (System.out), which works the same way as any java 
OutputStream, including files.

Salâm

Mohammad

[Eng. Maha Hulwa]

>  > Ghoniem.. Sorry :)) didn't see last code version.. just run
> first
>  > one.. hmmm..
>  
>  hmmm :) 
 :)) sorry i'll do it soon isA..

>  but i notice something want to ask u about it.. i did see at some
>  > headers of POEntities "python-format" it's not fuzzy flag..
>  
>  There are several kinds of comments in PO files, according to
>  http://www.gnu.org/software/gettext/manual/html_node/gettext_9.html :
>  1- translator's comments
>  2- automatic comments
>  3- flags (like "fuzzy")
>  4- references 
 When this automated comments generated?! do we have to generate it or keep 
it's values as it is.. unchanged?!

>  does this kind of header really matter.. do we have to skip it!!
> it's
>  > not a user comment.. but don't know if we skip it does this means
>  > corrupting po file.. do get my point...
>  
>  We should keep everything we find in PO files. Our job is translation. :-)
>  
>  Therefore, all we can do is :
>  - add translator's comments
>  -modify flags
>  
>  We must not modify/delete references nor flags imho. 
 I agree with u.. i didn't clarify my point quite well.. i mean the others; 
references we will not modify them.. shall we keep them in db or left them 
in PO file?..in other words.. while modify an already existing po file.. we 
will just modify the translation itself, write the status of the string; 
fuzzy flag; whether or not the string is fuzzy or not..or add new user 
comment or modify it.. we won't touch the references.. it's static data.. 
the question is:
Which better we left such data;references and the file header in file, or we 
should store it in db like any other data; msgID & msgStr ?
Got my point ?!

>  why dont' u try to create po file or update an already existing
> one..
>  > Using POFile & POMessages objects.. or did u already do it :))
>  
>  In the demo you received, the contents of po files are printed in the
>  command-line (System.out), which works the same way as any java
>  OutputStream, including files. 
  Yes right.. but arabic letters didn't displayed correctly because u used 
console.. but propebly it will.. u adjust the encoding to be utf-8..
 Ghoneim why dont' u try to change a string in PO File.. write into PO 
file?!

Thanks
BR,
-Maha.

[Mohammad Ghoniem]

Maha Helwa wrote:

>  When this automated comments generated?! do we have to generate it or
>
>  keep it's values as it is.. unchanged?! 
It is generated during the creation of po files. We have to keep it as is.

>  I agree with u.. i didn't clarify my point quite well.. i mean
> the 
>  others; references we will not modify them.. shall we keep them in db 
>  or left them in PO file? 
I would recommend keeping things as simple as possible, that is put 
everything in the database.


>      In the demo you received, the contents of po files are printed in
> the
>      command-line (System.out), which works the same way as any java
>      OutputStream, including files.
>
>   
>   
>  Yes right.. but arabic letters didn't displayed correctly because u 
>  used console.. but propebly it will.. u adjust the encoding to be utf-8.. 
We should not miw problems... The demo works correctly (the display is 
perfect in eclipse). gnome-terminal configuration is a different issue.

>  Ghoneim why dont' u try to change a string in PO File..  write
> into PO 
>  file?! 
Sorry Maha, I am afraid I don't understand you what you are trying to 
do/say. :)

salâm

Mohammad

[Eng. Maha Hulwa]

By now, you did read from PO file and extract the important data which will 
be stored into db.. right!!.. think reversely, rebuild or modify PO files 
again to include the new changes..
I mean try to write now into Po file.. say for example "Samba server" :)) 
the translation was in po file "khadem samba" in arabic letters.. excuse me 
can't write arabic now.. 
i want to try to change this translation and change it's status---> to be 
fuzzy string
replace the old translation with new one and modify the status using UTF-8 
encoding..
 How to test it?! try to open the output file in Kbabel.. and see if it's 
okay or the file has been corrupted!!
 if u did not understand my point.. don't giveup.. let me know.. and i'll 
explain again :)) 


 On 9/11/05, Mohammad Ghoniem <Mohammad.Ghoniem(a)univ-ubs.fr&gt; wrote: 
>  
>  Maha Helwa wrote:
>  
>  > When this automated comments generated?! do we have to generate it or
>  > keep it's values as it is.. unchanged?!
>  
>  It is generated during the creation of po files. We have to keep it as is.
>  
>  > I agree with u.. i didn't clarify my point quite well.. i mean the
>  > others; references we will not modify them.. shall we keep them in db
>  > or left them in PO file?
>  
>  I would recommend keeping things as simple as possible, that is put
>  everything in the database. 
  
>  In the demo you received, the contents of po files are printed in
> the
>  > command-line (System.out), which works the same way as any java
>  > OutputStream, including files.
>  >
>  >
>  >
>  > Yes right.. but arabic letters didn't displayed correctly because u
>  > used console.. but propebly it will.. u adjust the encoding to be 
>  utf-8..
>  
>  We should not miw problems... The demo works correctly (the display is
>  perfect in eclipse). gnome-terminal configuration is a different issue.
>  
>  > Ghoneim why dont' u try to change a string in PO File.. write into PO
>  > file?!
>  
>  Sorry Maha, I am afraid I don't understand you what you are trying to
>  do/say. :)
>  
>  salâm
>  
>  Mohammad
>  
>  --
>  Fedora-trans-ar mailing list
>  Fedora-trans-ar(a)redhat.com
>  http://www.redhat.com/mailman/listinfo/fedora-trans-ar
>

[Eng. Maha Hulwa]

Ghoniem :) u still don't know what am talking about?
 Anyway.. let's go step by step..doesn't matter now..
Sherif.. do u have time to install java sdk, tomcat and mysql?! do u have 
time for this?
 I think we should write down all options we need to include so nothing be 
forgotten.. the DB tables definitions.. a diagram illustrates the 
interaction between classes.. or blocks it wouldn't be final..
what else is needed to be document it.. ghoniem u suggested to put usecase 
on wiki.. does this helps us for better communicating?! or it's luxury 
thing..lol
  What i want to do this week isA.. My To-Dos for this week.. 
> Translator Screen.. retrieval and saving..
> Filter strings list.& filter the modules list 
Ah.. by the way.. about the idea
of showing "My Assigments".. i consider it 
for now to be on file names/ modules level.. i mean there will be a filter 
on the displayed modules to show either the only assigned modules or the all 
modules.. i didn't make it on string level such that each translator take a 
range of strings to be translated at certain module.
Ahh.. Who will do this assignement the maintainer? he will assign modules to 
the existing translators!! Hahahaha....lol.. another screen ..ana ba2eet 
bakhela awi..
> if there is more time i'll put gohniem part so.. we can retrieve
> real data  
and modify them and save modification into db..
 isA..
 BR,
-Maha.

[Eng. Maha Hulwa]

sorry ppl.. maybe i cause some headaches to some of u.. 
Ghoniem which version of the sdk u are using 1.4 or 1.5(Tiger) ?
 -Maha.

[Mohammad Ghoniem]

Salâm Maha,

I use java 1.4.2

salâm

Mohammad

Maha Helwa wrote:

>  sorry ppl.. maybe i cause some headaches to some of u..
>  Ghoniem which version of the sdk u are using 1.4 or 1.5(Tiger) ?
>   
>  -Maha.
>
> ------------------------------------------------------------------------
>
> --
> Fedora-trans-ar mailing list
> Fedora-trans-ar(a)redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-trans-ar
>

[Sherif AbdElGawad]

>  Sherif.. do u have time to install java sdk, tomcat and mysql?! do u
> have time for this? 
I will insha`allah

Sherif

[Mohammad Ghoniem]

Salâms,

Maha Helwa wrote:

>  By now, you did read from PO file and extract the important data
> which 
>  will be stored into db.. right!!.. think reversely, rebuild or modify 
>  PO files again to include the new changes.. 

The attached code outputs the parsed contents to a po file called 
test.po located in the user's home directory. The original and the 
generated files match exactly according to "diff". KBabel opens the 
generated file successfully. I tested the code on an ext3 partition 
supporting UTF8 under FC4.

Can you guys test it with your configuration and let us know how things go ?

Salâm

Mohammad

[Eng. Maha Hulwa]

Hi all..
 Ghoniem you always ready :)) .. 
Well i made some work lately in translator screen and sort of framework that 
still need enhancements.. by now i can read and save arabic..hmmm.. too late
but i find a nice problem that the data is not retrieved/saved correctly.. 
it's db issue :)
Anyway.. i got a question: need somebody answers me :)
 if a translator change a translation of certain string and save this 
change, and another colleague login; a translator; .. what he supposed to 
see.. he supposed to see the other changes his colleagues made or he should 
see last approved translation of this string the maintainer did accept it!!

sorry for being not so cooperative with u ghoniem.. still need sometime to 
finish some work then i'll be ready isA soon.
 Maha.

[Eng. Maha Hulwa]

Helloooo... is anybody here?!
Ghoniem.. Munzir.. 
Did u stopped the translation ?!
 Maha.

[Mohammad Ghoniem]

Salâms,

What is the current status of this project ? Drop it or carry on ?

Mohammad

[Eng. Maha Hulwa]

Ghoneim.. sorry for being late in almost everything...
i need to add ur part at my side plus fix string retrieval..so we can have
such scenario:
 1. uploading data from PO files into one of DB tables
2. Translators login and retrieve all, untranslated, fuzzy strings << got an
issue here
3. Save the changes per file and apply these changes into db.
4. Update/Create new PO files with the new changes.
 No am not going to drop this idea.. isA.. because am still interested to do
it.. and i will isA..
but am confusing these days and not feeling well.. but i'll be fine soon
isA.
 Once i fix the retrieve issue i have.. we can have the first version of our
tool..
Sherif once u have some spare time, prepare the enviornment on arabic
fedora, i'll try to fix things on next week end.
 The Retieval Issue:
Shall i make each translator see his own changes only not the others?!
i think i need to show two thing:
>  by default: Your translation suggestion should be display when u
> choose to 
show ALL strings.
>  Another icon or button, let you see the other ppl suggestions. 
Currently am not handling this..
 Anyway.. ghoniem i'll try to do something this week i hope isA.. don't like
to talk much till i really have something to talk about.
 Hope u don't drop it too!!
And i suggest we keep translating the strings manually till we have sort of
prototype we can work on it. what you think?! Munzir ghoneim sherif
desokey.. resume the translation task.. and i'll do my best isA soon.