Hi all,
last time we discussed this, I think there was consensus to switch the English Wiktionary to make it stop capitalising article titles, right?
Tim and I discussed this, and I think we should do it soon, because the longer the wait, the more we will have to fix manually after the switch.
The idea is to (1) flip the switch (so [[blah]] and [[Blah]] become separate articles) (2) run a script that renames every page to be lower-case, except for those pages that contain their own title in capitalised spelling (3) create a list of those pages that weren't moved, so we can fix them manually (for example, [[Kind]] will need to be split into two).
Ideas? Discussion?
Greetings, Timwi
Timwi wrote:
last time we discussed this, I think there was consensus to switch the English Wiktionary to make it stop capitalising article titles, right?
Guys! Please keep this on the mailing list, and don't reply to me personally. Thanks!
(Maybe the mailing list administrator should set a Reply-To header?)
Brion wrote:
This idea relies on the existence of the script for step (2). :)
The idea was that I would write it. (Where else would my involvement in this be? :-p)
Note that there may be an effect on usernames
I'll leave the usernames capitalised, I guess.
Ray Saintonge wrote:
Whatever process we choose will require some manual fix-up. The process that you suggest is as good as any.
My suggestion will require significantly less manual fix-up than moving 400,000 articles to lower-case versions manually.
How can we show capitalization when a linked word begins a sentence?
The same way as everywhere else, [[until|Until]].
Is there some way to integrate upper cased, lower cased and accented characters in generated lists?
I'm afraid I don't understand what you mean by this.
I don't remember it being a consensus at all. I seem to recall some being quite opposed to it.
Really? Can you provide links? I only remember people emphasising that they don't mind because they think the current work-around work perfectly for them. I seriously don't see how anyone can seriously be opposed to having a dictionary with correct spellings. :/
Timwi
Timwi wrote:
Guys! Please keep this on the mailing list, and don't reply to me personally. Thanks!
(Maybe the mailing list administrator should set a Reply-To header?)
I think it's fixed now...
Brion wrote:
Note that there may be an effect on usernames
I'll leave the usernames capitalised, I guess.
You'll also have to ensure that new usernames remain capitalized.
-- brion vibber (brion @ pobox.com)
Brion Vibber wrote:
I'll leave the usernames capitalised, I guess.
You'll also have to ensure that new usernames remain capitalized.
This is not already done? So it is possible to have "Brion" and "brion" be different accounts on, say, Toki Pona (where capitalisation is turned off)?
Timwi wrote:
Brion Vibber wrote:
I'll leave the usernames capitalised, I guess.
You'll also have to ensure that new usernames remain capitalized.
This is not already done? So it is possible to have "Brion" and "brion" be different accounts on, say, Toki Pona (where capitalisation is turned off)?
http://tokipona.wikipedia.org/w/wiki.phtml?title=User:brion&action=histo...
Usernames are treated as special cases of titles (with "_" replaced back to " "). While tokipona and tlh aren't exactly big deals, Wiktionary is much larger and attracts more people, so it's rather more important to make sure that usernames there are consistent if we intend to unify logins later.
-- brion vibber (brion @ pobox.com)
On Tue, 22 Jun 2004 18:07:02 +0100, Timwi timwi@gmx.net wrote:
I don't remember it being a consensus at all. I seem to recall some being quite opposed to it.
Really? Can you provide links? I only remember people emphasising that they don't mind because they think the current work-around work perfectly for them. I seriously don't see how anyone can seriously be opposed to having a dictionary with correct spellings. :/
I disagreed, http://mail.wikipedia.org/pipermail/wiktionary-l/2004-May/000018.html Polyglot said it could be done but he would vote against it also: http://mail.wikipedia.org/pipermail/wiktionary-l/2004-May/000020.html
By the way, how does search handle the existence of pages differing by capitalization? If someone searches for <greek> (v. [1]), which doesn't exist, are they sent to <Greek>, which does? ... Are users who are used to case-insensitive search, or don't know the proper capitalization of the word, sent to <greek> when it is made, when they might have wanted <Greek> better? Will every word where capitalization is semantic have to be made into a disambiguation page?
I would *much* prefer that pages, instead of being case-sensitive, be case-insensitive (even more than they are now, perhaps), with the page title in title case, and the regular capitalization indicated inline, as is now normally done.
*Muke! [1] "to fill a template with nonsense text, so that form and not content can be focused on"
Muke Tever wrote:
On Tue, 22 Jun 2004 18:07:02 +0100, Timwi timwi@gmx.net wrote:
Really? Can you provide links? I only remember people emphasising that they don't mind because they think the current work-around work perfectly for them. I seriously don't see how anyone can seriously be opposed to having a dictionary with correct spellings. :/
I disagreed, http://mail.wikipedia.org/pipermail/wiktionary-l/2004-May/000018.html Polyglot said it could be done but he would vote against it also: http://mail.wikipedia.org/pipermail/wiktionary-l/2004-May/000020.html
I'm sorry, but I can't extract any arguments against this change from either of the two e-mails, only vague fears of something going wrong, and a description of why the current ugly workaround "works". The only relevant thing I can see is your comment that "having separately-cased forms of words on different pages might overemphasize the difference between some senses of a word"; but this, too, is not an argument against the switch, only an argument against having two pages for Cynosure. Surely you can put that on one page ([[cynosure]] perhaps) and have the other be a redirect. This definitely does *not* apply to things like [[Kind]].
But anyway ... this doesn't matter. I suppose we should have a vote, then. I'll set one up on meta:
http://meta.wikipedia.org/wiki/En_Wiktionary_case-sensitivity_vote
By the way, how does search handle the existence of pages differing by capitalization? If someone searches for <greek> (v. [1]), which doesn't exist, are they sent to <Greek>, which does?
This is irrelevant here, because the same question already applies to multiple-word titles.
Are users who are used to case-insensitive search, or don't know the proper capitalization of the word, sent to <greek> when it is made, when they might have wanted <Greek> better?
Of course they are, but I sure hope that [[greek]] will contain a link to [[Greek]]. This is not an issue relating to the change I'm advocating here; this is a more general concern with the contents which is to be solved separately.
Will every word where capitalization is semantic have to be made into a disambiguation page?
Huh?
I would *much* prefer that pages, instead of being case-sensitive, be case-insensitive (even more than they are now, perhaps), with the page title in title case, and the regular capitalization indicated inline, as is now normally done.
Are you sure you're not just saying that because you're afraid of unforeseen consequences, or because you're simply used to the way it works now? I seriously don't think anyone would want to turn case-insensitivity on if we had started case-sensitively right from the start.
Timwi
--- Timwi timwi@gmx.net wrote: > Muke Tever wrote:
On Tue, 22 Jun 2004 18:07:02 +0100, Timwi timwi@gmx.net wrote:
Really? Can you provide links? I only remember people emphasising that they don't mind because they think the current work-around work perfectly for them. I seriously don't see how anyone can seriously be opposed to having a dictionary with correct spellings. :/
I disagreed,
http://mail.wikipedia.org/pipermail/wiktionary-l/2004-May/000018.html
Polyglot said it could be done but he would vote against it also:
http://mail.wikipedia.org/pipermail/wiktionary-l/2004-May/000020.html
I'm sorry, but I can't extract any arguments against this change from either of the two e-mails, only vague fears of something going wrong, and a description of why the current ugly workaround "works".
"ugly" is NPOV. Please explain what is ugly about it and what is not ugly about your proposed fix.
The only relevant thing I can see is your comment that "having separately-cased forms of words on different pages might overemphasize the difference between some senses of a word"; but this, too, is not an argument against the switch, only an argument against having two pages for Cynosure. Surely you can put that on one page ([[cynosure]] perhaps) and have the other be a redirect. This definitely does *not* apply to things like [[Kind]].
Now that would be a mess. If we had case sensitivity but no system of what went where. If we do opt for case sensitivity, we must not put uppercase definitions on lowercase pages sometimes when we feel like it.
Also, redirects are and should be far rarer on Wiktionary since there are often enough words in some language which belongs where the redirect would be.
But anyway ... this doesn't matter. I suppose we should have a vote, then. I'll set one up on meta:
http://meta.wikipedia.org/wiki/En_Wiktionary_case-sensitivity_vote
That page is NPOV, misleading, and ambiguous. Please try to fix it up. I've commented on the page.
By the way, how does search handle the existence of pages differing by capitalization? If someone searches for <greek> (v. [1]), which doesn't exist, are they sent to <Greek>, which does?
This is irrelevant here, because the same question already applies to multiple-word titles.
Currently, the built-in search is always turned off so we get Google's search heuristics by defacto... So I can't test this.
Are users who are used to case-insensitive search, or don't know the proper capitalization of the word, sent to <greek> when it is made, when they might have wanted <Greek> better?
Of course they are, but I sure hope that [[greek]] will contain a link to [[Greek]]. This is not an issue relating to the change I'm advocating here; this is a more general concern with the contents which is to be solved separately.
And what about for words which don't exist yet? Or exist in one case but not both? My feeling is the user should be directed to whichever exists if there is only one, given a choice if there is more than one, and given an opportunity to give the preferred case when making a new entry.
Will every word where capitalization is semantic have to be made into a disambiguation page?
Huh?
I would *much* prefer that pages, instead of being case-sensitive, be case-insensitive (even more than they are now, perhaps), with the page title in title case, and the regular capitalization indicated inline, as is now normally done.
I very much agree. I would go further and even suppress the page title, make it overrideable with a directive, or have it commented with "Page title: xxx" so it looks less like the headword itself.
Are you sure you're not just saying that because you're afraid of unforeseen consequences, or because you're simply used to the way it works now? I seriously don't think anyone would want to turn case-insensitivity on if we had started case-sensitively right from the start.
Umm... turn it on if it was already on?
Hippietrail.
Timwi
Wiktionary-l mailing list Wiktionary-l@Wikipedia.org
http://mail.wikipedia.org/mailman/listinfo/wiktionary-l
___________________________________________________________ALL-NEW Yahoo! Messenger - sooooo many all-new ways to express yourself http://uk.messenger.yahoo.com
Muke Tever wrote:
On Tue, 22 Jun 2004 18:07:02 +0100, Timwi timwi@gmx.net wrote:
I don't remember it being a consensus at all. I seem to recall some being quite opposed to it.
Really? Can you provide links? I only remember people emphasising that they don't mind because they think the current work-around work perfectly for them. I seriously don't see how anyone can seriously be opposed to having a dictionary with correct spellings. :/
I disagreed, http://mail.wikipedia.org/pipermail/wiktionary-l/2004-May/000018.html Polyglot said it could be done but he would vote against it also: http://mail.wikipedia.org/pipermail/wiktionary-l/2004-May/000020.html
By the way, how does search handle the existence of pages differing by capitalization? If someone searches for <greek> (v. [1]), which doesn't exist, are they sent to <Greek>, which does? ... Are users who are used to case-insensitive search, or don't know the proper capitalization of the word, sent to <greek> when it is made, when they might have wanted <Greek> better? Will every word where capitalization is semantic have to be made into a disambiguation page?
I would *much* prefer that pages, instead of being case-sensitive, be case-insensitive (even more than they are now, perhaps), with the page title in title case, and the regular capitalization indicated inline, as is now normally done.
*Muke![1] "to fill a template with nonsense text, so that form and not content can be focused on"
Muke Tever wrote:
On Tue, 22 Jun 2004 18:07:02 +0100, Timwi timwi@gmx.net wrote:
I don't remember it being a consensus at all. I seem to recall some being quite opposed to it.
Really? Can you provide links? I only remember people emphasising that they don't mind because they think the current work-around work perfectly for them. I seriously don't see how anyone can seriously be opposed to having a dictionary with correct spellings. :/
I disagreed, http://mail.wikipedia.org/pipermail/wiktionary-l/2004-May/000018.html Polyglot said it could be done but he would vote against it also: http://mail.wikipedia.org/pipermail/wiktionary-l/2004-May/000020.html
I initially opposed the idea since we had come up with a workaround. After some more thought and reading the opinion of others on Wiktionary EN, I changed my mind and now I'm convinced proper capitalisation is indeed crucial for a dictionary project. I came up with the workaround after asking a developer whether it would be possible to have proper capitalisation. The answer back then was that it wouldn't be possible, so we learned how to live and cope with it. Now that there is a willingness to change it, I think it is a blessing.
Polyglot
--- cookfire cookfire@softhome.net wrote: > Muke Tever wrote:
On Tue, 22 Jun 2004 18:07:02 +0100, Timwi
timwi@gmx.net wrote:
I don't remember it being a consensus at all. I seem to recall some being quite opposed to it.
Really? Can you provide links? I only remember people emphasising that they don't mind because they think the current work-around work perfectly for them. I seriously don't see how anyone can seriously be opposed to having a dictionary with correct spellings. :/
I disagreed,
http://mail.wikipedia.org/pipermail/wiktionary-l/2004-May/000018.html
Polyglot said it could be done but he would vote
against it also:
http://mail.wikipedia.org/pipermail/wiktionary-l/2004-May/000020.html
I initially opposed the idea since we had come up with a workaround. After some more thought and reading the opinion of others on Wiktionary EN, I changed my mind and now I'm convinced proper capitalisation is indeed crucial for a dictionary project.
I'm also convinced proper capitalisation is crucial for a dictionary project. But I'm not convinced Timwi's solution is the best way to go about it.
Hippietrail.
I came up with the workaround after asking a developer whether it would be possible to have proper capitalisation. The answer back then was that it wouldn't be possible, so we learned how to live and cope with it. Now that there is a willingness to change it, I think it is a blessing.
Polyglot _______________________________________________ Wiktionary-l mailing list Wiktionary-l@Wikipedia.org
http://mail.wikipedia.org/mailman/listinfo/wiktionary-l
___________________________________________________________ALL-NEW Yahoo! Messenger - sooooo many all-new ways to express yourself http://uk.messenger.yahoo.com
Andrew Dunbar wrote:
I'm also convinced proper capitalisation is crucial for a dictionary project. But I'm not convinced Timwi's solution is the best way to go about it.
This suggests to me that you don't understand what all of this is about. Apparently many people have misunderstood all of this, which is a real shame, because now we have loads of "no" votes from people who thought they are voting against something else.
Currently the software automatically capitalises the first letter of pages. "kind" automatically becomes "Kind", "isiZulu" automatically becomes "IsiZulu". As a consequence, we cannot have separate pages for [[kind]] (Engl. adj.) and [[Kind]] (German noun).
This is *only* about *removing that technological restriction*.
Almost all concerns raised, such as those with the search engine or with the linking etc.etc., are *irrelevant to this*. They are separate issues, and many of them *are* already issues that are neither worsened nor solved by this. This is *not* a miracle cure, and there is *no* point in opposing it just because it isn't a miracle cure.
I want separate words to be on separate pages if they are spelt differently. This is currently the case, with the arbitrary exception of first-letter capitalisation. I want to remove that. I want "Kind" and "kind" be separate pages. Examples that were given that should remain on a single page are essentially the same word (such as English "Cynosure" and German "Rot").
Removing the technological restriction of having it force capitalisation on us *DOES NOT REQUIRE* us to reparate those out into separate pages. So don't vote "no" because you don't want that, that's a different vote!
I hope I made things clearer now. Timwi
On Wed, 23 Jun 2004 15:40:52 +0100, Timwi timwi@gmx.net wrote:
This is *only* about *removing that technological restriction*.
No, this is also about:
(2) run a script that renames every page to be lower-case, except for those pages that contain their own title in capitalised spelling
Which I don't agree with.
I don't mind being _able_ to create pages with initially-lower-case titles. You want this to be the default and the standard, which is a separate issue entirely.
*Muke!
--- Timwi timwi@gmx.net wrote: > Andrew Dunbar wrote:
I'm also convinced proper capitalisation is crucial for a dictionary project. But I'm not convinced Timwi's solution is the best way to go about it.
This suggests to me that you don't understand what all of this is about.
If that's the case, it's only because you haven't made clear just what you want.
Apparently many people have misunderstood all of this, which is a real shame, because now we have loads of "no" votes from people who thought they are voting against something else.
I think it's because you have focused much more on talking about "proper spelling" - which most of us want, and not explained how. Even now you are mostly saying "technical change" - just explain what the technical change is. As I've pointed out, there are several technical changes which could give us "proper spelling". I'm sure I'm not the only one who has assumed you mean a different change, or just not known which change you have in mind.
Currently the software automatically capitalises the first letter of pages. "kind" automatically becomes "Kind", "isiZulu" automatically becomes "IsiZulu". As a consequence, we cannot have separate pages for [[kind]] (Engl. adj.) and [[Kind]] (German noun).
Which means it case-folds it. Which means that it treast an uppercase letter the same as a lowercase letter, if it's the first letter in the word. Which you haven't made clear, and I have tried to make clear.
I do want isiZulu to have the proper spelling at the place in the page where everybody will notice it.
I don't see any point in having "kind" and "Kind" on different pages. For starters, people won't see the false friend, which is now right there. This is one thing I like about Wiktionary.
This is *only* about *removing that technological restriction*.
Here you are not spelling out "restriction".
Almost all concerns raised, such as those with the search engine or with the linking etc.etc., are *irrelevant to this*. They are separate issues, and many of them *are* already issues that are neither worsened nor solved by this.
Exactly. I do not see the point in hacking the Wiki code to fix one issue at a time, in such a closely related area, when we can look at the big picture, how we really want it, think what change in this area will solve the most problems and create the fewest new ones, and then implement that one fix. Once.
This is *not* a miracle cure, and there is *no* point in opposing it just because it isn't a miracle cure.
Nobody ever mentioned miracles. I understand the technical issues very well. I know what's possible and what's miraculous. I know what's trivial and what's difficult to implement.
I want separate words to be on separate pages if they are spelt differently.
Then this is what you should say as your "vote for this change" line, instead of "I want proper spelling". They are not the same thing, as I hope I have made clear. You can have proper spelling without putting the words on separate pages.
This is currently the case, with the arbitrary exception of first-letter capitalisation.
I agree that it's arbitrary. This annoys me also.
I want to remove that. I want "Kind" and "kind" be separate pages.
This is much clearer and should be made clearer on the wiki page too.
Examples that were given that should remain on a single page are essentially the same word (such as English "Cynosure" and German "Rot").
Removing the technological restriction of having it force capitalisation on us *DOES NOT REQUIRE* us to reparate those out into separate pages.
Please say "making the first letter case sensitive" or something similar instead of the fuzzy "technological restriction".
So don't vote "no" because you don't want that, that's a different vote!
I hope I made things clearer now. Timwi
Somewhat but not totally, and perhaps not for everybody.
Hippietrail.
Wiktionary-l mailing list Wiktionary-l@Wikipedia.org
http://mail.wikipedia.org/mailman/listinfo/wiktionary-l
___________________________________________________________ALL-NEW Yahoo! Messenger - sooooo many all-new ways to express yourself http://uk.messenger.yahoo.com
--- Timwi timwi@gmx.net wrote: > Timwi wrote:
last time we discussed this, I think there was consensus to switch the English Wiktionary to make it stop capitalising article titles, right?
Guys! Please keep this on the mailing list, and don't reply to me personally. Thanks!
Sorry I'm so used to mailing lists having the Reply-To set that I didn't notice.
Brion wrote:
This idea relies on the existence of the script for step (2). :)
The idea was that I would write it. (Where else would my involvement in this be? :-p)
Note that there may be an effect on usernames
I'll leave the usernames capitalised, I guess.
Ray Saintonge wrote:
Whatever process we choose will require some manual fix-up. The process that you suggest is as good as any.
My suggestion will require significantly less manual fix-up than moving 400,000 articles to lower-case versions manually.
How can we show capitalization when a linked word begins a sentence?
The same way as everywhere else, [[until|Until]].
Is there some way to integrate upper cased, lower cased and accented characters in generated lists?
I'm afraid I don't understand what you mean by this.
I think he means that there are times when case-folding is very handy. Though I'm not sure exactly his context and he's also talking about accent-folding - which is not possible without lots of messy hacking.
I don't remember it being a consensus at all. I seem to recall some being quite opposed to it.
Really? Can you provide links? I only remember people emphasising that they don't mind because they think the current work-around work perfectly for them.
I seem to remember Polyglot being opposed, probably in the Beer Parlour. Not all of us are subscribed to this list. I stayed off because I had no space in my email account for mailing lists until a few days ago (Thanks Yahoo!).
I seriously don't see how anyone can seriously be opposed to having a dictionary with correct spellings. :/
Now this statement is pure rhetoric. I'm in favour of correct spellings and I'm sure everybody is. But there's more than one way to solve a problem and I'd like everybody to think this through and consider all possible ways to fix it before jumping in and making major changes.
The choices: 1. Case fold first letter only to uppercase. (current) 2. Case fold nothing. (Timwi) 3. Case fold all letters to lowercase. (Hippietrail) 4. A new directive to supply a prominent "Headword". (Hippietrail)
Against 1: * Headwords are prominently displayed uppercase when most should be lowercase. * Words which differ only by the case of the first letter must share a page. (common nouns vs. proper nouns) * Words which differ only by case the case of subsequent letters must be on separate pages. (abbrevations & acronyms) Against 2: * People are going to add duplicates thinking their word is not in the dictionary. * Quite a large number of entries will have to be changed back to uppercase after the script is run. * Words which differ only by case of any letter must be on separate pages. (proper nouns vs. common nouns vs. abbrevations & acronyms) Against 3: * All headwords would be prominently displayed lowercase when some should be uppercase. * Quite a large number of entries will have to be changed back to uppercase after the script is run. * Words which differ only by the case of any letter must share a page.
4. Is special. It can be implemented with or without any of the others. It will solve one issue nicely but I feel there are really two issues.
Issue 1 Prominently displayed headwords are misleading because they are also the name of the article.
Because the name of the article is currently always uppercase, all the headings generated by the Wiki software are in uppercase - which is very unprofessional for a dictionary. (This is why Polyglot started doing manual headwords below the part-of-speech section)
Issue 2 What should and should not be on the same page.
Currently we case-fold the first letter which means "bob" and "Bob" are both on a page titled "Bob" but "us" and "US" are on separate pages titled "Us" and "US"
I've read some peoples' opinions that they would prefer one entry per page but this is never going to work because of homographs anyway. Another issue is other languages. In some languages, certain diacritics (accents) are optional. Arabic, Hebrew, and Latin spring to mind. Some languages have marks which dictionaries use to show stress, which are not used elsewhere. Japanese and Russian are examples.
If we rely on the article name to be the headword, these will never fit. Using Polyglot's system they fit in perfectly. Words which differ only in case, optional diacritics, or stress marks can all be on one page.
Conclusion: I am in favour of showing correct spelling, case, and diacritical marks for all entries.
I am in favour of words which differ only in minor ways sharing a single page.
If we can break the connection between the name of the page and the headword, we won't have to see "PH" in big embarassing letters at the top of the article on "pH".
Having a directive which allows us to set the title to "pH" is one way. Having Wiktionary simply not display the page title, and instead rely on "Polyglot-style" headwords alone is another. In fact this may even possible just by changing the stylesheet.
Let the discussion proceed...
Hippietrail.
Timwi
Wiktionary-l mailing list Wiktionary-l@Wikipedia.org
http://mail.wikipedia.org/mailman/listinfo/wiktionary-l
===== http://linguaphile.sf.net/cgi-bin/translator.pl http://www.abisource.com
___________________________________________________________ALL-NEW Yahoo! Messenger - sooooo many all-new ways to express yourself http://uk.messenger.yahoo.com
Andrew Dunbar wrote:
I seriously don't see how anyone can seriously be opposed to having a dictionary with correct spellings. :/
Now this statement is pure rhetoric. I'm in favour of correct spellings and I'm sure everybody is. But there's more than one way to solve a problem and I'd like everybody to think this through and consider all possible ways to fix it before jumping in and making major changes.
You seem to be thinking of this as a much more "major change" than it really is. Again, this is only about removing an arbitrary technological restriction.
- Case fold nothing. (Timwi)
Heh, I'll focus on this one if you don't mind ;-)
Against 2:
- People are going to add duplicates thinking their word is not in the dictionary.
Are you thinking of people adding an article on, say, [[malayalam]] when the correct spelling [[Malayalam]] exists? Again, this is irrelevant to the discussion, it has nothing to do with the question at hand. People can *already* create pages at wrong spellings ([[Malaialam]], say). Yes, the switch would increase the potential, but adding redirects in the right places reduces it again, and so this is not an argument against.
- Quite a large number of entries will have to be changed back to uppercase after the script is run.
Have you read my original mail? Assuming your beloved current workaround actually works, *no* pages will need to be "changed back". Some might still need to be moved to lower-case, but only very few. You don't have to participate in this clean-up process if you don't want to.
- Words which differ only by case of any letter must be on separate pages. (proper nouns vs. common nouns vs. abbrevations & acronyms)
This is one major thing where you're going wrong. Why "must" they? They don't.
Because the name of the article is currently always uppercase, all the headings generated by the Wiki software are in uppercase - which is very unprofessional for a dictionary.
Bingo.
I've read some peoples' opinions that they would prefer one entry per page but this is never going to work because of homographs anyway.
One could always have article titles like [[kind (English)]] vs. [[kind (Dutch)]]. This makes linking extremely cumbersome, though.
Timwi
--- Timwi timwi@gmx.net wrote: > Andrew Dunbar wrote:
I seriously don't see how anyone can seriously be opposed to having a dictionary with correct spellings. :/
Now this statement is pure rhetoric. I'm in favour of correct spellings and I'm sure everybody is.
But
there's more than one way to solve a problem and I'd like everybody to think this through and consider all possible ways to fix it before jumping in and making major changes.
You seem to be thinking of this as a much more "major change" than it really is. Again, this is only about removing an arbitrary technological restriction.
Again, spell out the restriction instead of using this fuzzy language.
Sure changing an "Uppercase first letter" option is minor from the point of view of implementing it.
And splitting many many pages which are currently together is a major change. Some of the repurcussions are also major.
I'ts not "only" about flipping this switch, it's about all the long-term side-effect as well.
- Case fold nothing. (Timwi)
Heh, I'll focus on this one if you don't mind ;-)
That's what this one is. We currently case-fold the first letter. This is a major side effect of making it uppercase.
Against 2:
- People are going to add duplicates thinking
their
word is not in the dictionary.
Are you thinking of people adding an article on, say, [[malayalam]] when the correct spelling [[Malayalam]] exists?
Yes. And adding the german for "Kind" on the page for "Kind" because they don't realize it's already on the "Kind" page. Remember there are going to be hundreds or thousands of pages which will look like this after the simple switch is flicked, and people will continue to copy it.
Again, this is irrelevant to the discussion, it has nothing to do with the question at hand.
It has everything to do with it. People currently do type in words without regard to the first letter, sometimes carelessly, sometimes seeing that that's how Wikis currently work.
People can *already* create pages at wrong spellings ([[Malaialam]], say).
Surely you can't be suggesting that these are the same problem. You don't have to be a bad speller to overlook the change in handling the case of the first letter.
Yes, the switch would increase the potential, but adding redirects in the right places reduces it again, and so this is not an argument against.
Wiktionary doesn't work as well with redirects as Wikipedia. You can't put a redirect on "kind" to "Kind" because "kind" is also a word. This is a very common situation on Wiktionary.
- Quite a large number of entries will have to be changed back to uppercase after the script is
run.
Have you read my original mail? Assuming your beloved current workaround
The more you use this POV language, the closer I get to becoming annoyed. Do you mean your original mail in this current discussion or in the old discussion which you feel already settled everything? I have read what others have written. If they have the wrong impression as well as me, you probably haven't been clear enough. Can you provide a link to the mailing list archive or simply repeat the relevant part in this thread please?
actually works, *no* pages will need to be "changed back". Some might still need to be moved to lower-case, but only very few. You don't have to participate in this clean-up process if you don't want to.
If your script is dependent on my "beloved" workaround, then perhaps you are assuming that the workaround has been implemented on all pages, which it certainly has not.
- Words which differ only by case of any letter
must
be on separate pages. (proper nouns vs. common
nouns
vs. abbrevations & acronyms)
This is one major thing where you're going wrong. Why "must" they? They don't.
Because they have different case. This is exactly what your change means.
Unless you mean that we could continue to put "bill" and "Bill" on the same page. Obviously we could but it would be absurd to put "Bill" on a page other than the one titled "Bill" on a system which supported it. Or are you going to suggest putting redirects on all these pages?
Because the name of the article is currently always uppercase, all the headings generated by the Wiki software are in uppercase - which is very unprofessional for a dictionary.
Bingo.
So we agree on at least some of the symptoms, but not on the cure. Or at least not on how hastily a cure should be administered...
I've read some peoples' opinions that they would prefer one entry per page but this is never going
to
work because of homographs anyway.
One could always have article titles like [[kind (English)]] vs. [[kind (Dutch)]]. This makes linking extremely cumbersome, though.
Exactly. Hopefully this would never happen.
Hippietrail.
Timwi
Wiktionary-l mailing list Wiktionary-l@Wikipedia.org
http://mail.wikipedia.org/mailman/listinfo/wiktionary-l
___________________________________________________________ALL-NEW Yahoo! Messenger - sooooo many all-new ways to express yourself http://uk.messenger.yahoo.com
Timwi wrote:
flip the switch (so [[blah]] and [[Blah]] become separate articles)
Hi all.
It seems that I have made a number of wrong assumptions when I started all of this.
Firstly, I assumed that just about everyone would agree to want to have article titles lower-case if that is how the word is spelt. I am indescribably surprised that this is not the case, but oh well, that's wiki-democracy I guess.
Secondly, I assumed that at least a majority, if not everyone, would agree with me that engl. "kind" and German "Kind" are separate words and should hence have separate articles. (I'm sorry for bringing the same example over and over again, but I got used to it ;-).) Again, I'm surprised that this does not seem to be the case. Apparently some people actually *like* to have unrelated words on the same page, which completely mystifies me.
Thirdly, I assumed people would know what I'm talking about when I said "case-sensitivity" and "[[kind]] and [[Kind]] should be separate articles", etc. :-p
Fourthly, I fell into a pitfall that I fell into numerous times in the past (and, by implication, will probably fall into again numerous times in the future :-p). What I'm talking about here is that people emotionally attach to what they've got and what they're used to. There is a strong opposition to any kind of change, and arguments cannot change it. Just as long as the current way "somehow works", people seem to look for only the negative things (the "arguments against") in the proposal. The people who are in favour of the idea don't defend it as vehemently as the others oppose it.
Bottom line: It is futile for me to try to be of help with these kinds of things. I'm only glad I never even started writing that script; it would have been a waste of time.
Greetings, Timwi
Timwi wrote:
Timwi wrote:
flip the switch (so [[blah]] and [[Blah]] become separate articles)
Hi all.
It seems that I have made a number of wrong assumptions when I started all of this.
Firstly, I assumed that just about everyone would agree to want to have article titles lower-case if that is how the word is spelt. I am indescribably surprised that this is not the case, but oh well, that's wiki-democracy I guess.
It seems like a no-brainer to me too; it was a mess trying to do German words.
Stan
Timwi wrote:
Timwi wrote:
flip the switch (so [[blah]] and [[Blah]] become separate articles)
Hi all.
It seems that I have made a number of wrong assumptions when I started all of this.
Firstly, I assumed that just about everyone would agree to want to have article titles lower-case if that is how the word is spelt. I am indescribably surprised that this is not the case, but oh well, that's wiki-democracy I guess.
Secondly, I assumed that at least a majority, if not everyone, would agree with me that engl. "kind" and German "Kind" are separate words and should hence have separate articles. (I'm sorry for bringing the same example over and over again, but I got used to it ;-).) Again, I'm surprised that this does not seem to be the case. Apparently some people actually *like* to have unrelated words on the same page, which completely mystifies me.
Thirdly, I assumed people would know what I'm talking about when I said "case-sensitivity" and "[[kind]] and [[Kind]] should be separate articles", etc. :-p
Fourthly, I fell into a pitfall that I fell into numerous times in the past (and, by implication, will probably fall into again numerous times in the future :-p). What I'm talking about here is that people emotionally attach to what they've got and what they're used to. There is a strong opposition to any kind of change, and arguments cannot change it. Just as long as the current way "somehow works", people seem to look for only the negative things (the "arguments against") in the proposal. The people who are in favour of the idea don't defend it as vehemently as the others oppose it.
Bottom line: It is futile for me to try to be of help with these kinds of things. I'm only glad I never even started writing that script; it would have been a waste of time.
Hi Timwi,
The voting page has been moved over to the English Wiktionary by Eclecticology. It will probably be a lot more visible there. Now we have a lot of no votes from people I don't see contributing all that much on Wiktionary. Eclecticology is in favor of your proposal as well, so don't give up yet. On the talk page I tried to give an example how [[Polish]]/[[polish]] would be treated in the new situtation and I also commented that we should be glad there (finally) is a developer who wants to care of this. I agree with you that if FullCasSensitivity or NoInitialCaps would not have been on since the beginning nobody would have made an issue of it. I still remember we requested it back then, but we were supposed to use the software as it was back then. We accepted that, adapted to it, started to work around it and got used to that. It is not truly a problem that unrelated words are on the same page. The Dutch word [[kind]] (child) will still remain on the same page as the English word [[kind]]. They are separated by ----, which makes clear that they are words in different languages. Only the German [[Kind]] will move over. I guess that on the page for [[kind]] there could still be a German section referring people to [[Kind]]. That way it still remains visible that a word with almost the same spelling exists in another language. (Which is what we think of as interesting) (Even more interesting are words that are pronounced the same across different languages, but that's a totally different discussion...)
If you do write that script, I would like to check it out and comment on it before it gets run though. Maybe I have some suggestions to improve it, so less manual labor remains afterwards. What programming language do you use?
Polyglot
cookfire wrote:
The voting page has been moved over to the English Wiktionary by Eclecticology.
It seems that he *copied* it over. That's a bad idea. :-P I've replaced the page on meta with a "this has been moved" page now.
Now we have a lot of no votes from people I don't see contributing all that much on Wiktionary.
Yeah. I'm stupid. I should have started the vote on Wiktionary itself.
Timwi
Timwi wrote:
cookfire wrote:
The voting page has been moved over to the English Wiktionary by Eclecticology.
It seems that he *copied* it over. That's a bad idea. :-P I've replaced the page on meta with a "this has been moved" page now.
Now we have a lot of no votes from people I don't see contributing all that much on Wiktionary.
Yeah. I'm stupid. I should have started the vote on Wiktionary itself.
Timwi
I wouldn't call it that. In fact I'm glad you would want to help us with this issue. It's something we have been asking for since the beginning of the English Wiktionary. It wasn't possible back then because of other priorities for the developers. It's a pity there is such vocal opposition to it now and I feel bad because I started by objecting. It is true that there might be even better ways of dealing with the issues, but I'm sure that flipping a switch is going to be a lot easier to accomplish than having to add functionality to the software to do it in those better ways.
Polyglot
cookfire wrote:
Timwi wrote:
cookfire wrote:
The voting page has been moved over to the English Wiktionary by Eclecticology.
It seems that he *copied* it over. That's a bad idea. :-P I've replaced the page on meta with a "this has been moved" page now.
Now we have a lot of no votes from people I don't see contributing all that much on Wiktionary.
Yeah. I'm stupid. I should have started the vote on Wiktionary itself.
Timwi
I wouldn't call it that. In fact I'm glad you would want to help us with this issue. It's something we have been asking for since the beginning of the English Wiktionary. It wasn't possible back then because of other priorities for the developers. It's a pity there is such vocal opposition to it now and I feel bad because I started by objecting. It is true that there might be even better ways of dealing with the issues, but I'm sure that flipping a switch is going to be a lot easier to accomplish than having to add functionality to the software to do it in those better ways.
Polyglot
Beginning the vote at the wrong place is not a blameworthy act, just a strategically unsound one. I considered moving it instead of copying the page, and finally decided that moving was more socially acceptable. I was concerned about what complaints I might hear; I was glad to see that the page was replaced with the message.
How a vote is phrased can make a difference to its success. Putting three questions into one can be a recipe for failure; it gives opponents three separate issues that can be used to oppose the whole thing. The opposition was as much to the proposed script as to de-capitalizing the first letter.
I first proposed freeing up the first letter on Dec. 18, 2002, and I'm still convinced that it's the best way to go. Unfortunately the principal opponent doesn't seem to understand dictionaries.
Ec.
--- Ray Saintonge saintonge@telus.net wrote: > cookfire wrote:
Timwi wrote:
cookfire wrote:
The voting page has been moved over to the English Wiktionary by Eclecticology.
It seems that he *copied* it over. That's a bad idea. :-P I've replaced the page on meta with a "this has been moved" page now.
Now we have a lot of no votes from people I don't see contributing all that much on Wiktionary.
Yeah. I'm stupid. I should have started the vote on Wiktionary itself.
Timwi
I wouldn't call it that. In fact I'm glad you would want to help us with this issue. It's something we have been asking for since the beginning of the English Wiktionary. It wasn't possible back then because of other priorities for the developers. It's a pity there is such vocal opposition to it now and I feel bad because I started by objecting. It is true that there might be even better ways of dealing with the issues, but I'm sure that flipping a switch is going to be a lot easier to accomplish than having to add functionality to the software to do it in those better ways.
There's no need to be short-sighted and settle for quick fixes just because they are "a lot easier". I'm sure that's not the kind of thinking employed by the founders of the OED or Websters.
If Wiktionary is a good project, and I'm sure we all believe it is, then it will survive long enough for the real fixes to come along. Cleaning up after the side- effects of the quick fix and cleaning up again in the future when a solid fix comes along will be a pointless drain on the time and patience of the contributors.
Also, going with the quick fix now will reduce our chances of getting the developers to implement a solid fix later on, because they will believe they had already fixed the problem.
Polyglot
Beginning the vote at the wrong place is not a blameworthy act, just a strategically unsound one. I considered moving it instead of copying the page, and finally decided that moving was more socially acceptable. I was concerned about what complaints I might hear; I was glad to see that the page was replaced with the message.
How a vote is phrased can make a difference to its success. Putting three questions into one can be a recipe for failure; it gives opponents three separate issues that can be used to oppose the whole thing.
Or, those you label "opponents" might have actually agreed on the main point, and taken issue with what else was going to happen because of the change. Since this is what they have said I don't know why you feel the need to put it the way you have.
The opposition was as much to the proposed script as to de-capitalizing the first letter.
Or, the "opposition" was not opposed to de-capitalizing the first letter in a better way, and were much more opposed to the script, depending on which member of "the opposition", since each was an individual with a different perspective.
I first proposed freeing up the first letter on Dec. 18, 2002, and I'm still convinced that it's the best way to go. Unfortunately the principal opponent doesn't seem to understand dictionaries.
It may be even more unfortunate that some feel the need to put down others rather than improve their arguments or consider that other opinions might be valid and not just the "contrary ignoramuses" who have been depicted in the email I'm replying to now.
Hippietrail.
Ec.
Wiktionary-l mailing list Wiktionary-l@Wikipedia.org
http://mail.wikipedia.org/mailman/listinfo/wiktionary-l
___________________________________________________________ALL-NEW Yahoo! Messenger - sooooo many all-new ways to express yourself http://uk.messenger.yahoo.com
Andrew Dunbar wrote:
--- Ray Saintonge saintonge@telus.net wrote: > cookfire wrote:
Timwi wrote: I wouldn't call it that. In fact I'm glad you would want to help us with this issue. It's something we have been asking for since the beginning of the English Wiktionary. It wasn't possible back then because of other priorities for the developers. It's a pity there is such vocal opposition to it now and I feel bad because I started by objecting. It is true that there might be even better ways of dealing with the issues, but I'm sure that flipping a switch is going to be a lot easier to accomplish than having to add functionality to the software to do it in those better ways.
There's no need to be short-sighted and settle for quick fixes just because they are "a lot easier". I'm sure that's not the kind of thinking employed by the founders of the OED or Websters.
If Wiktionary is a good project, and I'm sure we all believe it is, then it will survive long enough for the real fixes to come along. Cleaning up after the side- effects of the quick fix and cleaning up again in the future when a solid fix comes along will be a pointless drain on the time and patience of the contributors.
Also, going with the quick fix now will reduce our chances of getting the developers to implement a solid fix later on, because they will believe they had already fixed the problem.
Polyglot
How a vote is phrased can make a difference to its success. Putting three questions into one can be a recipe for failure; it gives opponents three separate issues that can be used to oppose the whole thing.
Or, those you label "opponents" might have actually agreed on the main point, and taken issue with what else was going to happen because of the change. Since this is what they have said I don't know why you feel the need to put it the way you have.
It's a fact that the vote lumped three issues together. The fact becomes that they voted no on all three points.
The opposition was as much to the proposed script as to de-capitalizing the first letter.
Or, the "opposition" was not opposed to de-capitalizing the first letter in a better way, and were much more opposed to the script, depending on which member of "the opposition", since each was an individual with a different perspective.
My support is for the first letter de-capitalization. I have no attachment to the script. It looks as though it would do the job, but another method could work just as well.
I first proposed freeing up the first letter on Dec. 18, 2002, and I'm still convinced that it's the best way to go. Unfortunately the principal opponent doesn't seem to understand dictionaries.
It may be even more unfortunate that some feel the need to put down others rather than improve their arguments or consider that other opinions might be valid and not just the "contrary ignoramuses" who have been depicted in the email I'm replying to now.
"Ignoramus" is your word.
Andrew Dunbar wrote:
There's no need to be short-sighted and settle for quick fixes just because they are "a lot easier". I'm sure that's not the kind of thinking employed by the founders of the OED or Websters.
If Wiktionary is a good project, and I'm sure we all believe it is, then it will survive long enough for the real fixes to come along.
This is so typical. This argument is *always* going to brought up for *everything* that is not a complete miracle cure. Hence nothing will ever change and hence we will be stuck with the same problem forever just because people wouldn't accept at least a partial solution!
Cleaning up after the side- effects of the quick fix and cleaning up again in the future when a solid fix comes along will be a pointless drain on the time and patience of the contributors.
That is ungrounded and probably false. What you call a "quick fix" is a step in the right direction. Any "cleaning up" needed to do after the next fix (whether or not it is a miracle cure) will complement, and not override, replace, or render useless, the cleaning up needed now.
Also, going with the quick fix now will reduce our chances of getting the developers to implement a solid fix later on, because they will believe they had already fixed the problem.
You are forgetting that you *already* have no chance of getting a developer to do anything. The only reason why we can do this now is because *the feature is already there*. I don't know why it was written (maybe for Toki Pona?), but we have it now, and we can flip a switch to make it work. I (not really a "developer") have volunteered to write a script to do the moving in order to spare you from 40,000 page moves, but even without that script I am sure the Wiktionary userbase can fix all of that manually over time.
It may be even more unfortunate that some feel the need to put down others rather than improve their arguments or consider that other opinions might be valid and not just the "contrary ignoramuses" who have been depicted in the email I'm replying to now.
I do think I have considered the arguments brought forward. I have thought about them as much as I could, and almost all of them struck me as separate issues that were not arguments against this particular change.
Timwi
--- Timwi timwi@gmx.net wrote: > Andrew Dunbar wrote:
There's no need to be short-sighted and settle for quick fixes just because they are "a lot easier". I'm sure that's not the kind of thinking employed by the founders of the OED or Websters.
If Wiktionary is a good project, and I'm sure we all believe it is, then it will survive long
enough
for the real fixes to come along.
This is so typical. This argument is always going to brought up for everything that is not a complete miracle cure. Hence nothing will ever change and hence we will be stuck with the same problem forever just because people wouldn't accept at least a partial solution!
So basically you have made a prediction that nothing short of a miracle is capable of fixing the problem the proper way. Then you extend this into the future of all problems for all eternity. And this is to bolster support for your compromise solution.
From what you say in the following paragraph, it
seems that you expect these statements to be taken as grounded and probably true:
Cleaning up after the side-effects of the quick fix and cleaning up again in the future when a solid fix comes along will be a pointless drain on the time and patience of the contributors.
That is ungrounded and probably false. What you call a "quick fix" is a step in the right direction. Any "cleaning up" needed to do after the next fix (whether or not it is a miracle cure) will complement, and not override, replace, or render useless, the cleaning up needed now.
Since you have brought up "grounds" and true vs. false regarding the nature of your proposed change and its side-effects, I would call on you to please provide some grounds to support that these claims of yours:
a) that a real fix require a miracle b) that cleaning up won't be required
Also, going with the quick fix now will reduce our chances of getting the developers to implement a solid fix later on, because they will believe they had already fixed the problem.
You are forgetting that you already have no chance of getting a developer to do anything.
This is your argument, for which I am hoping you provide some grounds.
The only reason why we can do this now is because *the feature is already there*.
A feature with side-effects which, thankfully, have now Been discussed and commented on by several people.
I don't know why it was written (maybe for Toki Pona?), but we have it now, and we can flip a switch to make it work. I (not really a developer) have volunteered to write a script to do the moving in order to spare you from 40,000 page moves, but even without that script I am sure the Wiktionary userbase can fix all of that manually over time.
So you do know the switch is there. You don't know why the switch is there. You do know that a miracle is needed to make a better switch. You're not really a developer. You will write a script. Such a script does not need to be miraculous. My claims that cleanup after the script are ungrounded. You are sure we can avoid this non-developer script if we fix it ourselves over time. You are not prepared to wait time for a better fix.
It may be even more unfortunate that some feel the need to put down others rather than improve their arguments or consider that other opinions might be valid and not just the "contrary ignoramuses" who have been depicted in the email I'm replying to now.
I do think I have considered the arguments brought forward. I have thought about them as much as I could, and almost all of them struck me as separate issues that were not arguments against this particular change.
Well I hope I've clarified what hasn't been thought about Sufficiently. In the meantime I'm going to start looking at The Wiki code, and get in touch with some Wiki developers to see how feasible a good solutions would be.
Hippietrail.
___________________________________________________________ALL-NEW Yahoo! Messenger - sooooo many all-new ways to express yourself http://uk.messenger.yahoo.com
You know what, forget it. I'm sick of this.
I don't see why I should even attempt to rectify my desire to be of help. You do your own stuff, I won't try to help you again.
Bye, Timwi
wiktionary-l@lists.wikimedia.org