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

Thu Sep 8 23:33:55 UTC 2005

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 at univ-ubs.fr> 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 at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-trans-ar
> 
> 
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/trans-ar/attachments/20050909/59fe1439/attachment.html