Hello.
On the german Wiktionary [1], we have discussed about the case
sensitivity for our Wiktionary and the purpose was voted pro.
I asked TimStarling if it would be possible to convert then the de:
Wiktionary to case-sensitivity, that means to turn the automatic
capitalisation off. He said, he wouldn't do that for only one
Wiktionary, but for all at a time.
So I went here to ask you, what you would think about an case
sensitivity for _all_ Wiktionaries. Sure, there would be a huge of
broken links, but as the Wikis are still little and only have a few
articles, it is not a big problem to repair this. Except the en:
Wiktionary, of course, as a special case, who would need long to be
converted/ to repair the broken links.
Why all this: Most of latin languages have most words with lowercase
letters (ex.: german, french, english, ....). In the Wikipedia, it is
not a big problem to have only uppercase letters. But in a dictionary,
it is very important to have a difference between upper- and lowercase
words.
What do you think about that idea? Should it be voted on all the local
Wiktionaries? Which shouldn't be converted?
Sincerly yours,
Ronny Raschkowan
[[u:Fire]]
--
[1]: http://de.wiktionary.org
To Ulrich Fuchs and Anthere:
Just to clarify - on WikiEN-l, I was introducing an idea that has been
discussed on japanese wikipedia, and that could be of an interest of en.
wikipedians.
And I wrote in the first email:
>If English Wikipedia can also introduce similar license, that would make
>things more convenient.
Regardless of the decisions made in en., ja. will make its own decision.
Your inputs are welcome, as always. I suppose the English wikipedia has the
same stance to an input from a wikipedian like me (who is primarily active
at other wikipedia.)
So, don't be disappointed about that, please. :-)
If you are interested in the idea I was talking about, I am more than happy
to inform you. The basic stuff is already posted at wikiEn-l:
http://mail.wikipedia.org/pipermail/wikien-l/2004-May/012970.htmlhttp://mail.wikipedia.org/pipermail/wikien-l/2004-May/012992.htmlhttp://mail.wikipedia.org/pipermail/wikien-l/2004-May/012993.html
Cheers,
Tomos
_________________________________________________________________
Express yourself with the new version of MSN Messenger! Download today -
it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
Well, I think many people, including I, want to see GFDL changed and/or
becoming compatible with CC-by-sa. The reason is just as you cited: We are
stuck with it.
But such a change might take a long time (it has been already taking for a
long time), while somewhat questionable practices (copying and pasting of
texts or images without preserving history) are happening day by day. And
that is where a quick temporary fix like the introduction of the PD license
can help. Probably I was not clear on this, but it is not contradictory to
the change to GFDL, (or drafting of GFCL) as I understand.
Also, if you are concerned about the importing of GFDL'd contents from
outside sources, the PD license could specify that contents in the article,
image, and media namespaces are not dual-licensed, but simply GFDL'd. But
then, again, we are doing something questionable when we translate an
article containing such a text from one language to another without
preserving its history.
Like I suggested in the other email, it seems that the American Wikipedans
are reasonably safe. Court may find, even in case a lawsuit happens for some
reasons, not preserving history here and there is not a problem. And maybe
other en. Wikipedians are as safe (or maybe not. That part is something I
really don't know). So I am not urging that en. should adopt such a license.
But like I said, the license has its own benefits, both for en. wikipedians
and potentially for others who copy contents (text or image) from en.
without preserving history.
Regards,
Tomos
>From: Daniel Mayer <maveric149(a)yahoo.com>
>To: foundation-l(a)Wikimedia.org
>CC: wiki_tomos(a)hotmail.com
>Subject: Re: [WikiEN-l] Re: w to properly use articles from an outside GFDL
>source?
>Date: Sat, 29 May 2004 12:56:27 -0700 (PDT)
>--- Tomos at Wikipedia <wiki_tomos(a)hotmail.com> wrote on WikiEN-l:
> > Mav, you are right in that the effect is limited because we cannot
> > retroactively apply the second license to past edits. But if we consider
>the
> > effect, it seems it is still better to introduce it than not, and we
>would
> > do just as Electicology suggested:
>
>Sorry, it is simply not possible to create a derivative dual licensed work
>from
>a GFDL-only licensed article. Doing so would be a violation of the
>copyright of
>everyone who submitted the GFDL-only text. Dual licensing would also make
>it
>impossible to accept any new GFDL-only text.
>
>We are stuck with the GFDL as is until the FSF makes changes to that
>license.
>Let's concentrate on improving the license we have - Jimmy has already
>stated
>that the FSF and CC people are interested in this type of thing.
>
>-- Daniel Mayer (aka mav)
_________________________________________________________________
Stop worrying about overloading your inbox - get MSN Hotmail Extra Storage!
http://join.msn.click-url.com/go/onm00200362ave/direct/01/
"Erik Moeller" <erik_moeller(a)gmx.de> schrieb:
> Anthere-
> > We are setting the foundation status. The current
> > status are indicating that ALL OF OUR CONTENTS
> > (wikimedia projects) will be distributed under the
> > gfdl license.
>
> > Should we do that or not ?
>
> No, please do not. We should have the option to decide for any new
> Wikimedia project whether to use the FDL or another license.
>
> Take the Wikinews project as an example. If successful, Wikinews will not
> only compete with CNN but also with AP and Reuters. That means that
> newspapers, magazines and websites may be interested in using our content
> instead of the expensive AP feed. But the FDL with its long license text
> and complicated terms is not very practical for that. There is even the
> question if we really want to force Wikinews users to copyleft their
> content, or if the public domain or an attribution license wouldn't be
> more practical in this instance.
Not to mention that technically _no_ Wikipedia project holds the GNU/FDL.
We never should have taken it in the first place, we certainly should not
bind us to it any more than we are by the situation of already having content
under it.
Andre Engels
"Erik Moeller" <erik_moeller(a)gmx.de> schrieb:
> Andre-
> > And finally, once more I apologize for getting so angry. Especially
> > because, as you said, in the end we want the same.
>
> No problem. We'll just have to agree to disagree on the best approach to
> get this started. As I said, if you can establish a general consensus for
> starting with a blank, basic wiki in spite of my objections I will of
> course work with you. If you don't want to campaign for this I ask you for
> just a little more patience. We *will* make this happen, one way or
> another.
Well, I guess my messages here are supposed to be some kind of campaign.
I'm just starting to get the impression that the rest of the people here
don't seem to care either way.
Andre Engels
Since we are talking about fairness in elections, I
need help.
I was notified my candidacy statement was unfair.
I, on the other hand, think that elections are unfair
to those who are not native english. It takes us a lot
of time to answer questions, and it is difficult to
write a short statement, while trying to make it sound
and clear to anyone. Thus, I would like that a real
english speaker edit my statement to make it appear
good, clear, respect editorial rules, style, spelling
and such. It also needs to be shorten (though I would
not say of how much exactly since I thought I was
below 500 caracters).
I would like to mention that we are trying to set a
Foundation to help a world wide project which will be
a real revolution, and I think fighting over a couple
of characters in a candidacy statement is not exactly
what I perceive as terribly interesting.
I would have preferred that candidates discuss with
each other on their background, on their opinions, on
their positions, on what they did not know, on what
they loved in the project. It would be more
constructive to do that, and it would have given more
opportunity for participants from all projects to get
to know the candidates better.
I also think comparisons of positions, and
consequently opportunity to have two candidates
working together as beneficial or destructive would
have been more easily perceived upon reading
discussions between candidates, than reading about
little fights upon the fairness of representativity.
Complaining over the fairness of 10 characters when
half of the candidates can not technically provide a
fully professional candidacy statement is ridiculous.
If the validity of my candidacy is impaired by the
length of my statement, and by adding a short
description of my contributions while it was written
nowhere it was forbidden, then I think I am not
interested in being a candidate anymore, and you may
strike my name Danny. I am not here to play
seek-and-hide game.
__________________________________
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/
I'm sorry about this. I made the mistake of writing email while angry
again. It's just... I don't see what the big problems are. Sure, there
is a chance that the project would start slower than it would when
everything was ready at once, but for that it would start earlier. And
the swing it will get when the features are ready anyhow.
The other problems - if the way the wiki is working really makes
development much harder, you might have to think again about how
to do this. Just like the other aspects, the software is there to
support the project, not the project to implement the software.
The other problems will be encountered whichever way is chosen.
We now realize the GNU/FDL was not the best licence to put Wikipedia
under. But we would not have found out by just waiting. We found out
by having Wikipedia under the license, and meeting its limits.
Likewise, there will undoubtedly be good and not-so-good ways of
setting up a structure for the information on WikiCommons. We will
choose one (or a few) of them, and develop those, maybe even decide
to switch. But that will happen whether we start now or later.
Wikipedia wasn't build in one day. But it was built.
And finally, once more I apologize for getting so angry. Especially
because, as you said, in the end we want the same.
We don't have a risk of making mistakes. We have a certainty of it.
But delaying our decisions will not help us make better ones. Better
to make our mistakes now, the earlier we make them, the earlier we
can correct them.
Andre Engels
"Andre Engels" <engelsAG(a)t-online.de> schrieb:
> "Erik Moeller" <erik_moeller(a)gmx.de> schrieb:
>
> > Something will be made, yes, but that something may be difficult to build
> > upon - in terms of content, functionality, structure, policies - and grow
> > into something tremendously more useful. That is the crux of my argument.
>
> And with a single login and uploading this suddenly will work? Don't be
> ridiculous.
>
> It will be easy to build upon. It's all there - content, functionality,
> structure, policies. We cann build them now, or we can build them later.
> Your proposal is to build until we have good functionality, and then start
> making some content and structure. My proposal is to get all of them at
> the same time and develop all.
>
> It's NOT easier to make content from nothing than to make it from content.
>
> We have some splendid Wiki software now, don't we? Ain't it a shame that
> we already made an encyclopedia and policies for it? With this software
> we would do a lot better, no? Why don't you go and start your own
> Wikipedia?
>
> > If you can convince the others (vote, consensus etc.) that we should set
> > up a blank wiki now and add all the other functionality later, regardless
> > of all the problems that may ensue, then I will follow along, but my
> > position remains that we should properly plan and develop a basic set of
> > features before publicly launching this project with great fanfare, to
> > make sure that we have a solid foundation to build on, and that we get the
> > greatest possible interest in the important early stage of content
> > development.
>
> I'm sick of this.
>
> andre
>
> _______________________________________________
> foundation-l mailing list
> foundation-l(a)wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/foundation-l
>
"Erik Moeller" <erik_moeller(a)gmx.de> schrieb:
> Something will be made, yes, but that something may be difficult to build
> upon - in terms of content, functionality, structure, policies - and grow
> into something tremendously more useful. That is the crux of my argument.
And with a single login and uploading this suddenly will work? Don't be
ridiculous.
It will be easy to build upon. It's all there - content, functionality,
structure, policies. We cann build them now, or we can build them later.
Your proposal is to build until we have good functionality, and then start
making some content and structure. My proposal is to get all of them at
the same time and develop all.
It's NOT easier to make content from nothing than to make it from content.
We have some splendid Wiki software now, don't we? Ain't it a shame that
we already made an encyclopedia and policies for it? With this software
we would do a lot better, no? Why don't you go and start your own
Wikipedia?
> If you can convince the others (vote, consensus etc.) that we should set
> up a blank wiki now and add all the other functionality later, regardless
> of all the problems that may ensue, then I will follow along, but my
> position remains that we should properly plan and develop a basic set of
> features before publicly launching this project with great fanfare, to
> make sure that we have a solid foundation to build on, and that we get the
> greatest possible interest in the important early stage of content
> development.
I'm sick of this.
andre
"Erik Moeller" <erik_moeller(a)gmx.de> schrieb:
> Andre-
> (regarding the commons and similar ideas)
I'll try to remain calm...
> - This is our best opportunity to get single sign-on working, a feature
> which we desperately need. Because the Commons effectively requires access
> to a shared database, this is a natural extension. But starting with a
> separate login system makes single sign-on a *separate* goal. This is not
> just a technical issue of yet another redundant user table. It's also a
> social issue of not being able to use the synergy from the launch of the
> commons to promote single sign-on (which will likely have some initial
> hurdles to overcome) and vice versa. It's difficult to generate excitement
> about small, evolutionary steps.
I think the effect will rather be opposite. By introducing many things at
once, it is likely that some will not be used that would be if presented
separately.
Also, I think we can diide the users of Wikicommons in two groups - those
directly interested, and those who are interested because it helps them
with another project. The first group can be got without extra features.
The second group will more likely be caught with content than with features.
If that idea is correct, the best way would be to start now with the first
group, and capture the second one when the direct upload and reference
from Wikipedia/Wikibooks/whatever is created, by showing them that there
is something they can actually use - a collection of pictures, already
divided into galleries.
> - The initial edits on a wiki lay the foundation of what that wiki will
> become. If just a few people get involved in this project, because it
> offers no really cool, exciting possibilities, then the project foundation
> may well not be as solid as it could be. For example, people may decide to
> create image categories and upload requirements in the first two weeks.
> This structure will then become harder and harder to change as it seeps
> in, and when we add all the new cool features which attract more people --
> a better upload form, transparent use of commons media from all wikis,
> single sign-on -- it may already be too late to quickly and effectively
> fix certain problems. Too much may have grown into the structure already.
Again, the cool, exciting features are I think not what draws people to the
project. Their own wish for a project like this, and the content of the
project are the more likely elements.
Problems like you describe will definitely happen, but I think they will
happen just as much if we wait as when we don't.
> These concerns outweigh my desire to have something usable as soon as
> possible.
I still feel it differently. Apart from having a long lasting desire to
just do this, even if there aren't any extras, I also think that having
a database and a community already in existence will help, not hinder
in getting the features working and used.
Andre Engels
The intention was for 500 characters (words in the previous response was my error) to respond to each of the two questions. As I stated earlier, we did not specify whether blank spaces between words are characters or whether links are characters. We expected that the candidates would understand that their answers to these two questions would be succinct, so that the page would be wieldly and user-friendly--nothing more and nothing less. I have asked those users who exceeded 500 characters to shorten their statements, but I do believe that _everyone_ acted within the spirit of the 500 characters, so I do not intend to chop up their statements or disqualify them.
Danny