Nothing I said is intended to imply that contractions should be avoided.
They are, in any event, a linguistic fact that should be recorded
accurately in Wikidata. So, I have:
1. Added forms -F3 ('ll) and -F4 ('d) to L1891 *shall*. (I've left *will* for
the time being.)
2. Added form -F3 (we shall) to L269709. I don't believe this is correct,
but it parallels the existing -F2, so we can get rid of them both later. I
added -F3 with the feature "contraction". This is even less correct, but it
might help focus future debate.
3. Changed L269709 from a phrase to a contraction.
4. Added a "combines" (P5238) statement to L26909. I tried to add two, but
the second merged itself with the first. I've left it as
*we*+*shall*+*will* for
the time being and
5. Created the discussion page for L269709 explaining the problem. Jura has
responded "I think it would be better to have separate entities"...
Those weeds keep growing... let's think of them as green manure!
Al.
On Sunday, 30 August 2020, Thad Guidry <thadguidry(a)gmail.com> wrote:
Hi Al.
Contractions that are avoidable would be advantageous in certain cases.
For example:
For Simple English rendering, we might have a rule that says *no
contractions* would be allowed. This would help others learning a
language or simply having smart auto-completion as you type on a Wikipedia
page for instance to replace "we'll" with "we will" as an
example. Or a
reverse rendering for those that might have their Wikipedia Babel native
language for English set to en-N, then you might *want contractions* in
order to avoid verbosity for those that could quickly read and understand
English sentences that have them.
In general, there are tons of use cases for renderers that I have thought
of and this is only 1 of them, but they all rely on constructors,
functions, and lexicographical data stored well and in some standardized
fashion somewhere. Which is why I am always asking about best practices
within Wikidata's Lexeme namespace. I find that I often look for some of
the most complex issues to deal with which helps make it easier for me to
understand where the gaps will likely be in any system. Then we can begin
conversations on how we'll tackle them.
Looking forward to others' opinions!
Thad
https://www.linkedin.com/in/thadguidry/