Re: [libreoffice-l10n] Cosmetic changes?

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