2009/5/18 Jürgen Spitzmüller <sp...@lyx.org>:
>> > Usually, Acronyms are language-specific as well (cf. IPA [International
>> > Phonetic Association] vs. API [Association Phonétique Internationale]).
>>
>> This still wouldn't help me, because I don't have any French language
>> documents. I'd be pasting from a French language website, if I was
>> very lucky I might be pasting from an English language document where
>> I had explicitly set that text to French; in which case copying over
>> the tags might make sense.
>
> But is difficult, since the web page does not supply any language data.
I'm just noting that I have never personally found a case where the
automatic addition of language tags is useful.
>> Admittedly, Leaving it as UK might be useful if it was a direct quote,
>> and had proper quotation marks around it. (And yes I realize that
>> detecting quotations in every possible language could be difficult,
>> even for languages that actually have quotation marks. However I use
>> citations rather than quotes, so again this isn't something that makes
>> a difference)
>
> I don't see why quotes make a difference, in general (although I see people
> usually mark quotes more often). In any case, trying to fiddle with this is
> bound to fail.
Some programs have "paste as quotation" in addition to plain "paste"
However mixing UK and US English is almost never correct. I don't
think you've mentioned any case where mixing UK and US English is
correct. I am mostly trying to understand why you think that the very
common requirement that a document be formatted consistently with
either US or UK English but not both is fundamentally incorrect.
Maybe you believe this requirement is incorrect because the following
should be considered acceptable?
a) I went to Colour Press and got some color prints done.
b) I think that Blue is a nice colour, but Bob wrote "Blue is an ugly color".
Out of
1) Blue a nice colour, but green is an ugly colour.
2) Blue a nice color, but green is an ugly color.
3) Blue a nice colour, but green is an ugly color.
I consider only 1 and 2 correct. I don't consider 3 to be correct,
anymore than I consider the eletelephony* poem to be proper English. I
do not consider
4) Blue a nice colour, but green is an ugly \foreignlanguage{american}{color}.
to be correct either. At best we've replaced a spelling mistake with a
different form of mistake.
Would you consider it correct if my Grammar Checker flagged/removed
the \foreignlanguage{american} in (4) above, leaving only the forms in
(a) and (b)?
Another possible solution for this annoyance: if LyX-GrammarChecker
was improved and integrated to the point where it could quickly and
easily remove inappropriate language tags in English texts. Currently
LyX-GC is an unashamedly English only tool, but it could easily be
extended to any language supported by lanuagetool (or by perl regex's
for that matter). In any case, a LyX-GC cannot be expected to be
lanuage agnostic; so I can see no objections to cramming English
specific rules on quoting into LyX-GC.
>> >> In principle I may be submitting a document to an organization that
>> >> requires that all text be in Language X (and only language X), in
>> >> which case any LyX document I submit that contains language markup is
>> >> wrong, just as if I had included a Chapter in an article.
>> >
>> > But not if you use different languages (if this organization is not
>> > completely crazy, that is).
>>
>> If I use a Chapter is a journal article, then it clearly should be
>> formatted as a Chapter, rather than e.g. standard?
>
> I'm talking about language markup, not chapter markup.
I don't see what the difference is. In the case of pasting a chapter
into an article LyX removes the chapter because it would be incorrect
in an article. The result isn't "correct", you can't turn a book into
a proper article by removing all chapter tags, but at least it puts
into the right format. LyX leaves it up to the user to fix this up.
In the case of pasting UK text into a US document, LyX actively adds
the foreignlanguage tags. These tags are almost never appropriate. The
user manually removes the tags, then fixes any spelling mistakes.
I don't see why the following is any more incorrect than LyX's current
chapter example: The user pastes some text into a journal format where
only UK English articles are accepted. LyX automatically strips all
the invalid \foreignlanguage{american} tags. The text may not be
correct (it may well be). Again the user is responsible for fixing
this up, a simple spell check suffices.
>> Well I am not advocating hardcoding, never-the-less it would
>> presumably correct according to one of the two acceptable definitions
>> of correct. (at least if you spell words according to the hard-coded
>> language).
>
> As I have argued, I still think it would _never_ be correct, except for cases
> where a word has the same word form in two languages, or (more often), two
> varieties of a language, which both is not predictable (and thus must be
> decided by explicit user action).
>
> [...]
I am not sure why it would not be correct. If we hardcode English (UK)
and write English (UK) text, then the output will be correct?
>> > excuse me, it strikes me rather monolingual-English centric, while LyX
>> > aims at being truly multilingual.
>>
>> Presumably, not all monolingual users speak English; I would imagine
>> that French users may have similar issues with regard to French/French
>> Canadian.
>
> Dunno about French. However, when writing German, I welcome very much that the
> information about texts being old German spelling, new German spelling or
> Swiss German is not lost during copying.
I don't see how this would assist you. Is it normal in German to mix
spellings in a single document, or does the meaning of a word depend
on the dialect, or ...?
>> In any case I don't see why this is an objection to this feature (I
>> can certainly see why you wouldn't want to work on it yourself).
>> I don't see any reason for LyX to not have features that only help
>> monolingual users, or rather users that only prepare monolingual
>> documents in LyX. I've studied other languages, and I could write a a
>
> Monolingual users do not need such a feature. If they are hit by language
> markup, they are in fact not monolingual users anymore (in a broad sense of
> multilingualism, including 'inner multilingualism', i.e. language varieties).
>
> [...]
>> The main advantage that the lack this feature has for such users is
>> that the aggravation it causes them, might induce them to better
>> understand the difference between UK and US English. However if you
>> fix all the bugs wrt. ERT etc., and then most of them will probably
>> think the blue overline is just form of screen corruption (it doesn't
>> appear in the PDF after all). If nothing else, the
>> monomodal/mulitiligual dialog might clue them into what the blue line
>> actually means.
>
> If they ignore the blue underlining, at least the output will be correct. If
> we remove the markup and people ignore that, the output will in many cases not
> be correct.
AFAICT, In English, at least, it is almost never considered correct to
mix sub-languages, while most US and UK words have the same spelling.
Also if people don't even spellcheck (or proofread) the document
before submitting it they may as well use Wordpad or IRC. I don't see
any point aiming LyX at this use case.
Since LyX doesn't have an English (Australian) option presumably all
my documents are incorrect anyway. Might as well be consistently
incorrect.
>> Also if this dialog popups up immediately when you attempt to paste
>> the text in, it would be obvious to you which source document had the
>> wrong (sub) language.
>
> Such a dialog would be much more annoying than the language markup.
LyX 1.6.2 gives me 5 warnings that various LyX files have a different
textclass to lyxmacros.lyx each time I do a "View PDF" on my paper.
I think I can handle a dialog that occurs at most once in a documents
lifetime :)
--
John C. McCabe-Dansted
* "Once there was an elephant,
Who tried to use the telephant-
No! No! I mean an elephone
Who tried to use the telephone ..."
