Hello Bert et all,

Please let me answer to your questions.

- Well, setting up a calendar with dates and time is pretty difficult I'm 
afraid.....But I think we could put 
some structure in this, as long as all the reviewers agree of course.

Santiago: the reason why I ask for a calendar or similar, is that because there 
are always other translation projects going on, we need to have someone ready 
for amending the OLH at a certain moment and for a certain amount of time. So 
the more we know in advance the better the preparation.

- Perhaps it's a good idea to collect those [issues that Alpha could not get 
fixed] in an empty spreadsheet, so they can be found more easily.

Santiago: in principle no problem, although in my opinion using a new column to 
signal those items that haven't been fixed could be also very clear. 
Particularly for the community reviewers who would be able to see immediately 
and in one go what has been amended and what hasn't. Also, many times one item 
might be related to the one above or the one after, and if we isolate it, it 
might lose some of its message. Anyway, this is not a big issue.


- can you tell me what you think of the comments you've seen so far in the 
review sheets? Do they make sense to you?

Well, unfortunately it does not make sense to me, but because I don't 
understand a word.
I remember some problems when we checked the QA reports that were hanged for 
Calc some time ago in a nother issue number, before Natalie came in. I hope 
that most of the problems we saw there have gone away after being filtered by 
Natalie. We will know when Nicole can have a look at the QA reports.


- I'm not sure I understand what you mean with this one. Are you talking 
about full paragraphs or something?

More or less. Actually what I mean is that if there are many mismatching 
strings, or if we detect a long chunk of a gsi file where source and target 
don't match, it is preferable to select those strings and translate them anew 
using SunTrans (now OLT Open Language Tools), or Trados. This makes things 
easier for us. But I think it won't be the case now. If you want to know what I 
mean by mismatching, I think I detected a few examples of "mismatching" that 
were reported by your reviewer:

        º see for instance rows 103, 106, 114, 115 in 
NL_Help_MacrosandProgramming_GeneralInfo-Digro-nat.ods.  The difference in 
length between the source text, the old translation and the proposed 
translation is huge, and I presume that the old translation does not match the 
source, right?
        º or rows 104, 105 in the same QA report, where the source segment 
contains tags, the old translation doesn't and the proposed translation puts 
the tags in.
        
This is all for the moment. Let me know if any questions.

cheers  



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: Bert Meersma [mailto:[EMAIL PROTECTED]
Sent: Monday, December 19, 2005 5:37 PM
To: [email protected]
Cc: [EMAIL PROTECTED]
Subject: Re: [loc] Nauwelijks vertaalde help pagina's


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]


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

Antwoord per e-mail aan