Hi Santiago,

Thanks for your comments. Please find mine below.

Santiago Seminario wrote:
Hi Rafaella et all,

Unfortunately Nicole is OOO this week, so she cannot participate in this 
discussion, but she will probably have some ideas to add next week.

If we are to integrate the feedbacks from the community, let me make some 
comments:

1.- we need to receive all the OLH files in gsi format. I guess that is not a 
problem for Sun since this has been done in other languages.
I think they can easily be taken from the source, but I'll leave that up to Sun.
2.- I suggest to concentrate on a by module work. For example, when all the 
Basic module has been reviewed, we implement it, then go on to Writer, Calc, 
etc. So I wonder if the community could establish a calendar, telling which 
module will be finished first, second, third, etc.
Well, setting up a calendar with dates and time is pretty difficult I'm afraid. But by looking at how things are going at the moment my guess would be that Calc is finished first, Writer second and Macro's and programming third. Is it difficult to work on different modules at the same time? Right now, all the reviewers pick a topic that they like best, so there's no telling what will be next. But I think we could put some structure in this, as long as all the reviewers agree ofcourse.

3.- I think that once the QA reports for a certain module have been received, 
we should implement all of it and not only the FFE. Here we need to make some 
comments:
I think we have an agreement on that one.
        a) when we had to implement the review from the community in the UI we noticed 
that there were some inconsistencies in the QA reports, one reviewer saying one thing 
here and another saying something different or opposite in a different report. That makes 
implementing the errors a difficult task. However I think that since Natalie is now in 
charge of reviewing the reviews of other members of the community, this inconsistency 
problem should have disappeared by the time we get the final QA reports (the ones from 
"xbraze")
I fully agree. That's exactly why Natalie is reviewing all the reviews now.
        
b) assuming the QA reports are consistent, then Alpha should implement all of the issues reported (the ones that are FFE and can be fixed by search and replace, and the specific ones, those which happens once, in a specific place).
And another agreement ;-)
        
c) There will surely be some issues in the QA reports that Alpha won't be able to fix, and in these cases I propose that Alpha notifies it by writing a note in the QA sheet, under a column named for example "Note to Community" and explains why cannot be fixed. The Community and Sun will know exactly what are the issues that need attention.
Perhaps it's a good idea to collect those in an empty spreadsheet, so they can be found more easily.
        
        d) The reasons for no fixing an issue could be many, for example:
- errors reported because the source and the translation don't match - errors that Alpha cannot fix (for example a missing image)
        - errors reported that Alpha might not consider to be an error
        - etc
Seems reasonable to me.
Can you tell me what you think of the commenst you've seen so far in the review sheets? Do they make sense to you?
(In the cases where there exists a mismatch between source and translation, if the community provides a translation for it and Alpha agrees with it, it can be integrated directly into the gsi files. But if there are too many of them, the best would be to extract all the mismatching strings and translate them anew. Then Sun integrates them into the OLH and a new build.
I'm not sure I understand what you mean with this one. Are you talking about full paragraphs or something?

Regards,

Bert

--
__________________________________________________
Broxtor on irc.freenode.net (#nl.openoffice.org)

Meepraten op IRC? Download een korte handleiding vanaf:
http://home.wanadoo.nl/rijmeer/handleiding_IRC.pdf


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Antwoord per e-mail aan