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.
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.
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:
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")
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).
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.
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
(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.
Please check all this and let me know what you think.
Thanks a lot
Santiago Seminario
Project Manager
------------------------
Phone:+34 934 451 205
Fax: +34 934 921 181
[EMAIL PROTECTED]
------------------------
ALPHA CRC Ltd
Consell de Cent, 334
08009 Barcelona
Spain
-----Original Message-----
From: Rafaella Braconi [mailto:[EMAIL PROTECTED]
Sent: Monday, December 19, 2005 11:21 AM
To: [email protected]
Subject: Re: [loc] Nauwelijks vertaalde help pagina's
Hi Bert and All,
let's see what Santiago and Nicole suggest on their side as well ... in
the end we are all hier to work together and it is very important that
we find a way which is suitable for all of us :-) .
BTW: it was NOT my intention to suggest to review less ... I was only
pointing out that we might be confronted with a larger volume of review
feedback because you are thouroughly reviewing the Help. If this is what
you think it needs to be done, I will respect this decision and I am
more than happy to support you in this :-) .
Kind Regards,
Rafaella
Bert Meersma wrote On 12/18/05 13:46,:
> Hi Jigal,
>
> Jigal van Hemert wrote:
>
>> Hi Bert, Rafaella, Santiago and all others,
>>
>> From: "Bert Meersma"
>>
>>
>>
>>> 1. All reviewers stop with reviewing and attach their files to issue
>>>
>>
>> 59216.
>>
>>
>>> 2. Alpha has a look at the comments in the review files and looks which
>>> type of comment is repeated often.
>>> 3. Alpha changes the help by using the comments found in step 2. This
>>> will result in a lot less comments in the remaining reviews.
>>>
>>
>>
>> Do you mean that only the frequently found errors (FFE) will be
>> fixed? It
>> will certainly not mean that these FFE will be fixed in all places as it
>> turned out that Alpha didn't receive the complete help (parts were
>> ported
>> directly from 1.1.x).
>>
>
> That's a good point. At least the FFE should be fixed in all the help
> files.
>
>>
>>
>>> 4. Then a new set of help files is build.
>>> 5. The reviewers start reviewing the new set of help files.
>>>
>>
>>
>> This means to me:
>> 5. The reviewers start reviewing the new set of help files all over
>> again.
>> Why?
>> a) It is not certain that the entire help text was available for
>> Alpha, so
>> errors (even FFE) may appear in the help text
>> b) Only FFE were fixed and the review files are probably not modified
>> accordingly
>>
>
> It's not desired that everybody starts all over again. So in order to
> prevent this, all the FFE's should be fixed in ALL the help files and
> all the "unique errors" that are already in the review sheets should
> be fixed also. This way, nobody has to start all over again, but it
> will make the list with errors in the future review sheets a lot
> shorter. It would also speed up the reviewing process since the FFE's
> are already out.
>
>> For me it's not a big problem as I started reviewing recently after
>> being
>> ill for a few weeks, but I don't think that those who already reviewed
>> substantial parts of the help will fancy the idea of starting all over
>> again.
>>
>
> see my comments above.
>
>> It seems a good idea at first, but I'm not sure if it speeds up the
>> entire
>> process in the end. It really depends on the number of isues that
>> will be
>> fixed, the question whether Alpha will have the entire help text and how
>> long it will take before the new help files will be available.
>>
>
> I think this is partially true. But when you see at the time spent by
> the reviewers, the ideas described here would certainly shorten this
> time, since the FFE's do not exist anymore. Besides that, I think it
> would also be better for moral if all the FFE's are out. The reviewers
> do not face a pile of issues every time they open a help file.
>
> Thanks for pointing this out!
>
> Regards,
>
> Bert
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
