Date: prev next · Thread: first prev next last
2013 Archives by date, by thread · List index


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

Since there are tools like LanguageTool maybe there is a way to automatize
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 <>

Hi Andras,
Le 05/12/2013 11:42, Andras Timar a écrit :
On Thu, Dec 5, 2013 at 10:52 AM, Robinson Tryon
<> wrote:
On Thu, Dec 5, 2013 at 4:37 AM, Mateusz Zasuwik <>
2013/12/2 Sophie <>

And en-US team need glossary, surely. I see many inconsistent phrases
"*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.


To unsubscribe e-mail to:
Posting guidelines + more:
List archive:
All messages sent to this list will be publicly archived and cannot be

To unsubscribe e-mail to:
Posting guidelines + more:
List archive:
All messages sent to this list will be publicly archived and cannot be deleted


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.