Hi, I agree with Sophie on this, some kind of overall check.
Since there are tools like LanguageTool maybe there is a way to automatize this: 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 <gautier.sop...@gmail.com> > Hi Andras, > Le 05/12/2013 11:42, Andras Timar a écrit : > > On Thu, Dec 5, 2013 at 10:52 AM, Robinson Tryon > > <bishop.robin...@gmail.com> wrote: > >> On Thu, Dec 5, 2013 at 4:37 AM, Mateusz Zasuwik <mzasu...@gmail.com> > wrote: > >>> 2013/12/2 Sophie <gautier.sop...@gmail.com> > >>> > >>> And en-US team need glossary, surely. I see many inconsistent phrases > like > >>> "*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. > > Cheers > Sophie > > > > -- > To unsubscribe e-mail to: l10n+unsubscr...@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+unsubscr...@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
