Re: [libreoffice-l10n] Quality in l10n

Hi,

I agree with Sophie on this, some kind of overall check.

Since there are tools like LanguageTool maybe there is a way to automatize
this:
1) set a local LT server
2) serve all LO strings with identifiers for later reference without the
XML and other tags to LT server and log all errors reported (including
spell-checking ones)
3) manually go through errors reported and extract only reported errors
that represent a true error
4) native speakers suggest changes
5) if necessary, the proposed changes are checked by a team of non-techie
native speakers
6) fix the errors as proposed in 4) and as confirmed in 5)
I see this a process that could be finished in a release cycle, i.e. for
the next release (be it 4.3 or whatever).

I am not sure but - maybe this is feasible - can we automize the LT-check
via its server of any strings changed in the code when checking it in (at
least that found errors are part of the log of check-in, so it can be later
parsed and checked en-masse by native speakers)? This way all string
check-ins/changes after the full cleanup (steps 1-6) would be monitored.

Probably this is science fiction.

Lp, m.


2013/12/5 Sophie <gautier.sophie@gmail.com>

> Hi Andras,
> Le 05/12/2013 11:42, Andras Timar a écrit :
> > On Thu, Dec 5, 2013 at 10:52 AM, Robinson Tryon
> > <bishop.robinson@gmail.com> wrote:
> > > On Thu, Dec 5, 2013 at 4:37 AM, Mateusz Zasuwik <mzasuwik@gmail.com>
> wrote:
> > > > 2013/12/2 Sophie <gautier.sophie@gmail.com>
> > > >
> > > > And en-US team need glossary, surely. I see many inconsistent phrases
> like
> > > > "*Please consider restart LibreOffice* to set new features".
> > >
> > > Soooo..what's the best way for me to identify and squash bugs in
> > > strings like this?  Should I just keep an eye on core.git?  Perhaps
> > > look at the compiled list of strings?
> >
> > During alpha and beta testing, and during translation process dozens
> > of people read en-US strings. Some people report typo bugs either in
> > Bugzilla, or in e-mail, and those bugs are fixed within hours. I don't
> > think we need to set up processes, e.g. formal review, UI committee,
> > approval, etc -- we had these in old OOo era -- , just we need to
> > exercise the "many eyeballs" principle better. It is better to report
> > a typo multiple times, than never.
>
> I agree about no need for formal review, processes etc.
> However there is a need for a check of the quality of the en_US version,
> per the original request from Olivier.
> And it is really time consuming and error prone for localizers to not
> rely on a clear and understandable explanation or when several strings
> are used for the same dialog, button, action, etc.
> Of course, for the typo etc, during the translation time, no problem to
> rely on the l10n team to correct them (and thank you for fixing so
> fast), but that does not solve the problem of the overall quality of the
> en_US version.
> And I know that I don't propose any satisfying solution for developers
> or localizers :) /me still thinking about it.
>
> Cheers
> Sophie
>
>
>
> --
> To unsubscribe e-mail to: l10n+unsubscribe@global.libreoffice.org
> Problems?
> http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
> Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
> List archive: http://listarchives.libreoffice.org/global/l10n/
> All messages sent to this list will be publicly archived and cannot be
> deleted

-- 
To unsubscribe e-mail to: l10n+unsubscribe@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/l10n/
All messages sent to this list will be publicly archived and cannot be deleted