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 <[email protected]> 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: [email protected] > 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: [email protected] 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
