Sorry for the delay. I've waited a few days for comments, and this took a while to write.
-- I'll start by addressing the comments I received from Jonathon and Peter. From your responses, I got a better idea of the motivation for some of the rules. Specifically, Jonathon mentioned that the numbers for sentence and paragraph length correspond to a 6th grade reading level, and Peter mentioned and that non-native speakers do indeed struggle with contractions. Jonathon mentioned that the issue with translating contractions is not ease of understanding for translators, but has to do with translating grammatical structure. This still makes no sense. There is no difference in the structure or meaning of contracted and un-contracted pairs of words, so the translation is the same in either case. The only exception I can think of is subject-auxiliary inversion. For example, the question "Couldn't you do such-and-such", has a different word order from "Could you not do such-and-such". I suspect that such language (contracted or not) would already fall afoul of several other guidelines having nothing to do with ease of translation. Finally, I can infer from Peter's comments on "never" that the limits on sentence and paragraph length are meant to be hard limits. Peter, you have stated repeatedly that these rules worked well in your professional experience. But this is exactly the problem. Without knowing the context of these companies and projects, there is no way for anyone else to evaluate how they compare with this project. Hence my request for a concrete discussion. -- Overall, my primary concerns remain unaddressed. I will restate them now. 1. To what extent ought we to prioritize non-native readers and translation, respectively? More specifically, when should we adopt rules that risk making material *less* readable for ordinary English speakers? The current style guide consists mostly (entirely?) of rules that benefit all readers. Again, I must apologize because I wasn't following the mailing list for a while, but to my knowledge there is no precedent here. 2. Are rigid rules appropriate? The current style guide leans toward "guidelines". I am still opposed to hard limits on sentence and paragraph length, as a matter of principle. Less is better even when you are under the limit, 7 short sentences might be better than 3 long sentences, etc. The bans on contractions and Latin abbreviations would probably have to be strict for the sake of consistency, so I am not counting them here. Finally, 3. What are the implications of rule (3), the ban on possessives? What constructions must be replaced, and with what? I don't think it's possible to decide on this one without this information. Thanks for bearing with me, --Kenneth On Sat, Mar 28, 2020 at 11:28 AM Peter Schofield <[email protected]> wrote: > Hello Kenneth > > Having worked internationally as a Technical Writer, I understand what is > required to get the message. I have had personal experience of non-English > people not understanding apostrophes and word contractions. LO has no > control over who uses our software and writing in Simplified English avoids > any questions being asked on what does this mean. > To the best of my knowledge, Simplified English including my suggestions > was originally created by Caterpillar who have a huge international > clientele. It works for Caterpillar and also Airbus, so why not LO. > Regards > Peter Schofield > Sent from my iPad Mini > > > On 27 Mar 2020, at 20:19, Kenneth Hanson <[email protected]> wrote: > > > > Hello, > > > > Sorry to butt in after being absent so long, but I'm worried about these > > proposed rules. > > > > I agree with rules to keep sentences and paragraphs short, breaking up > long > > sentences and paragraphs when possible. On the other hand, I'm uneasy > about > > rules like Peter's (1) and (2) stipulating maximum numbers of words or > > sentences. If the numbers are intended as rules of thumb, they should be > > rewritten to reflect this. If they are meant to be hard limits, it's easy > > to imagine situations where following such a rule could make the result > > harder to understand. > > > > Second, I struggle to see how rules (3-5) would make translation easier, > or > > whether this is a good reason to implement them. > > > > Regarding (4), if a translator's command of English is so poor that they > > cannot understand common contractions, it seems doubtful that using > > one-to-one replacements would make all the difference. > > > > Regarding (5), if anything I think Latin abbreviations should be avoided > > for the sake of readers of the English version, for maximum > accessibility. > > It appears from the wiki history that this provision was already in the > > style guide. > > > > Finally, regarding (3), genitive possessives are such a basic component > of > > English grammar that I worry that circumlocutions would harm readability > to > > an unacceptable degree, even if this improves ease of translation. No > > examples are given, so I don't know what is intended. There are examples > of > > cases to avoid possessive pronouns already in the style guide, but these > > are not contexts in which a full noun (phrase) would be used. > > > > I think I understand the background that Peter is coming from, but I > think > > this issue requires more discussion. > > > > --Kenneth > > > > > >> On Fri, Mar 27, 2020 at 6:59 AM Peter Schofield <[email protected]> > wrote: > >> > >> Hello Olivier > >> > >> Definitely no objections from me. Hopefully, we will then get a standard > >> English appearing across all the guides. > >> > >> Regards > >> Peter Schofield > >> [email protected] > >> > >> > >> > >>> On 27 Mar 2020, at 12:32, Olivier Hallot < > [email protected]> > >> wrote: > >>> > >>> Hello All > >>> > >>> If no objection rises, I'll merge the suggestions in the wiki page. > >>> > >>> Kind regards > >>> Olivier > >>> > >>> Em 27/03/2020 07:28, Peter Schofield escreveu: > >>>> Hello Ilmari > >>>> > >>>> The Style Guide does not cover all my suggestions, mainly use of > >> apostrophe and word contractions. These two items do cause problems when > >> translating English. > >>>> My ideas about paragraphs and sentences are similar to the Style > Guide, > >> but I have put a number in the requirement. This does help if writers > >> follow the suggestion. > >>>> Regards > >>>> Peter Schofield > >>>> [email protected] > >>>> > >>>> > >>>> > >>>>> On 27 Mar 2020, at 10:11, Ilmari Lauhakangas < > >> [email protected]> wrote: > >>>>> > >>>>> Peter Schofield kirjoitti 27.3.2020 klo 10.23: > >>>>>> After going through the meeting notes (which I could not attend), I > >> though that it maybe a good idea to air my views about writing > standards. > >>>>>> The following ideas come from my experience in working within > >> Simplified English rules when I worked for Airbus and Ericcson. > >>>>>> 1. Paragraphs no more the six sentences long. > >>>>>> 2. Sentences should only contain a maximum of 20 words, with the > >> occasional sentence allowed to be 25 words. > >>>>>> 3. Never use the possessive apostrophe (for example Peter’s). > Rewrite > >> the sentence to remove the need for a possessive apostrophe. > >>>>>> 4. Never use contractions of words (for example: don’t becomes do > >> not; won’t becomes will not, and so on) > >>>>>> 5. Never use Latin abbreviations (for example: etc becomes and so > on; > >> e.g. becomes for example; i.e. becomes that is). > >>>>>> There are many more rules, but the above basic rules are a good > >> start. They are designed to make English text easier to translate into > >> other languages and that is why it is called Simplified English. > >>>>>> Please let me know your opinion. > >>>>> > >>>>> There is a style guide in the wiki: > >> > https://wiki.documentfoundation.org/Documentation/DocumentationTeamInfo/StyleGuide > >>>>> > >>>>> Ilmari > >>>>> > >>>>> -- > >>>>> To unsubscribe e-mail to: > >> [email protected] > >>>>> Problems? > >> https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ > >>>>> Posting guidelines + more: > >> https://wiki.documentfoundation.org/Netiquette > >>>>> List archive: > >> https://listarchives.libreoffice.org/global/documentation/ > >>>>> Privacy Policy: https://www.documentfoundation.org/privacy > >>>> > >>>> > >>> > >>> -- > >>> Olivier Hallot > >>> LibreOffice Documentation Coordinator > >>> Comunidade LibreOffice > >>> Rio de Janeiro - Brasil - Local Time: UTC-03:00 > >>> http://tdf.io/joinus > >>> > >>> -- > >>> To unsubscribe e-mail to: > >> [email protected] > >>> Problems? > >> https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ > >>> Posting guidelines + more: > >> https://wiki.documentfoundation.org/Netiquette > >>> List archive: > https://listarchives.libreoffice.org/global/documentation/ > >>> Privacy Policy: https://www.documentfoundation.org/privacy > >> > >> > >> -- > >> To unsubscribe e-mail to: > [email protected] > >> Problems? > >> https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ > >> Posting guidelines + more: > https://wiki.documentfoundation.org/Netiquette > >> List archive: > https://listarchives.libreoffice.org/global/documentation/ > >> Privacy Policy: https://www.documentfoundation.org/privacy > >> > > > > -- > > To unsubscribe e-mail to: > [email protected] > > Problems? > https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ > > Posting guidelines + more: > https://wiki.documentfoundation.org/Netiquette > > List archive: https://listarchives.libreoffice.org/global/documentation/ > > Privacy Policy: https://www.documentfoundation.org/privacy > -- To unsubscribe e-mail to: [email protected] Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.libreoffice.org/global/documentation/ Privacy Policy: https://www.documentfoundation.org/privacy
