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

Hi :)
My last "hare-brained" idea was blatantly flawed.  Thanks to Yury (i think)
and someone else for shooting it down quickly before it went anywhere! :)
Sorry about that!

It sounds like there is scope for a lot of automation.  There might already
be ways of doing it.

1.  Can fuzzy strings be accepted "en masse", preferably by large-scale
selection?  (I'm guessing there isn't at the moment)
2.  Is there an "undo"?
3.  Can individual strings "undo" to get single strings back to being fuzzy?

Also, is there a way of getting an extremely large selection of strings
grouped in some way so that people can see the whole group had 1 specific
change?  Even fairly small groupings might help a bit!

Regards from
Tom :)

On 14 December 2014 at 12:19, Rimas Kudelis <> wrote:


2014.12.14 13:48, Olivier Hallot wrote:
On 14/12/2014 06:59, Rimas Kudelis wrote:
It should be. You can look at it the other way around: anything that
gets in the source should consistently be en_US, not just

You're right and that is the way it has to be.

We face the issue that LibreOffice developers are mostly not English
native speakers, and they are much less often graduated in English
litterature. Mistakes and poor clarity are introduced in their strings
quite naturally and often. That is the way it is and we live with it

Which is why I'm advocating string review process, if only it is
possible. It's perfectly normal that some of us have trouble writing
concise  and typographically correct English. But isn't it similar to
writing buggy code? We do have code reviews, where someone else with the
right set of knowledge reviews code patches. So why not have a similar
process for string changes? Why not ask somebody who maybe can't code,
but knows English (including typographical stuff) well to review the
strings that are being changed or newly introduced?

Now that I think of it, if we have UX reviews (and if we don't, we
should), strings might just fall into that category.

Reviewing en-US is a good thing once in a while, even if it gives us
more work, and I expect once fixed it will not change anymore.

Reviewing en-US is a good thing for sure. I believe however, that when
we have massive changes, which can be automatically transferred to
localized resources without degrading l10n quality, we should transfer
them automatically (maybe on a per locale opt-in or opt-out basis). What
has been happening lately (and is explained in Michael's examples) is
indeed a major messup (mismanagement, if you like). Few more cases like
this, and LibO will start losing localizers. This thread is a clear

As a side note, devs don't even write help pages to explain their new
features, and this doesn't help our translation job too.

Devs don't have to write help pages. However, when others writes these
help pages, they could be the ones raising a flag about string quality


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.