Re: [libreoffice-l10n] Cosmetic changes?

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 <rq@akl.lt> wrote:
> hi,
>
> 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
> > > whatever_lingo_the_developer_had_in_mind.
> > >
> > > Rimas
> > 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
> > since OpenOffice.org.
>
> 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
> warning.
>
> > 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
> issues.
>
> Rimas
>
>
> --
> 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