This is my argument (or rather, my
quickly hashed out rambling) as to why the community draft for the
language proposal policy should become our official policy, in place
of the current one. My argument is fairly long, but I hope that it
does not descend into irrelevance and that people will read it
through to the end.
The community draft language proposal
policy has the advantage of being, in the Wikimedia spirit, a more
collaborative work. The current language proposal policy was made by
a small group, but the community draft was, as its name suggests,
open to ideas from anyone who had any, and I think that it is a
better reflection of the feeling of Wikimedia users than the current
one.
I want to be very clear that I believe
the language proposal system we have now is far better than the one
we had before: it is fairer, quicker and more efficient. However,
although it is better than the last one, it is not as good as it
could be.
Some Wikimedia users (and I am
certainly part of this group) thought it unfair that, whilst
artificial languages such as Esperanto and Volupak were allowed by
this policy to have Wikipedias, classical languages such as Latin and
Ancient Greek were not, on the grounds that, since they have no
native speakers, they do not serve a community and are therefore at
odds with the foundation's mission statement. This seems like both a
contradiction and a questionable interpretation of the foundation's
mission statement. With this in mind, one of the requisites for
eligibility in the current policy:
“The proposal has a sufficient
number of living native speakers to form a viable community and
audience. (Wikisource wikis are allowed in languages with no native
speakers, although these should be on a wiki for the modern form of
the language if possible.)
If the proposal is for an
artificial language such as Esperanto,
it must have a reasonable degree of recognition as determined by
discussion (this requirement is being discussed by the language
subcommittee).”
Has been changed to this in the community draft:
“The proposal has a sufficient worldwide number of people able to
express themselves at a fluent level, in the written, spoken or
signed form, to form a viable community and audience.
If the proposal is for a
language without native speakers, it will need to be demonstrated
that it is well attested in written texts, and is in current use as
a special, auxiliary, engineered, classical or learned language.”
The community draft's requisite
reflects the fact that a viable community and audience does not need
native speakers, not everyone wishes to use a Wikipedia in his or
her native language, and that knowledge gained in one's second,
third or nth language
is just as good as knowledge gained in one's first language. Latin,
for example, was the Lingua Franca of Western Europe for much of the
second millennium, even though it had no native speakers (or, at
most, a negligible number); had Wikimedia, with its current language
proposal policy, existed at that time, it would not have been
eligible for a Wikipedia, despite being the language in which a
Wikipedia would be most useful. Today, the English language has a
similar role; who would bat an eyelid at an internet community that
used English despite having no native speakers of the language? If
there were no native English speakers today the English language
Wikipedia would still be a very useful project, but would be deemed
by the current policy to not have a “viable community and
audience”. I admit that these arguments may seem a little
far-fetched, but I hope they show that there is a problem with the
policy as it stands. I believe that by allowing people to share and
receive knowledge in classical languages as well as modern ones we
would better fulfil the Wikimedia Foundation's mission statement:
“The mission of the Wikimedia Foundation is to empower and
engage people around the world to collect and develop educational
content under a free
license or in the public domain, and to disseminate it
effectively and globally.”
The community draft also specifies
how much of the interface has to be translated before final approval
for both first projects in a language and projects in languages that
already have projects. By requiring the 500 most-used messages to be
translated for a first project, the policy sets a goal that is tough
but reasonable. Requiring too many messages to be translated before
the creation of the project would be likely to tire-out a smaller
community (which would, of course, grow once the project was
actually created). Not requiring any would make it easier for
languages without much real support to slip through the net (I think
that this part of the process should be used not only to make sure
that the language has an interface, but also as another part of the
test to see whether a language is suitable for the project). By
requiring 500 messages to be translated we can ensure that people
are serious about the project and have enough motivation, that the
language (if it is classical) is capable of expressing modern
concepts and that potential editors are not *too*
over-worked during what is (let's be honest) the most boring part of
the process. It is more sensible to require a grater number of
messages to be translated before the creation of another project in
a language because a language that already has at least one
Wikimedia project should have a bigger community.
Contrary to what one might infer from the length of my argument, the
community draft actually proposes very few changes from the current
policy; in fact, it is probably better thought of as a fine-tuning
of the current policy rather than a completely new one, and I hope
that other will agree with me that the few changes that the
community proposes to make to the policy will make it better.
forwarded message. As always, I'm grateful if this is *not* quoted as
"Michael Bimmler wrote", irrespective of whether I agree with the
email.
---------- Forwarded message ----------
From: RJ <nittanylions(a)psu.edu>
Date: Tue, Nov 18, 2008 at 3:41 PM
Subject: One Laptop per Child (OLPC) and wiki
To: foundation-l-owner(a)lists.wikimedia.org
http://wiki.laptop.org/go/The_OLPC_Wiki
This is an awesome program, how can we take wiki involvement to the
next level? Any chance to market on the main wiki webpage? Thanks.
--
Michael Bimmler
mbimmler(a)gmail.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I haven't seen this yet posted to the Textbook-l list or foundation-l
so I wanted to make it known that Wikibooks is winding down its logo
vote over the next couple weeks. While we're asking people not to
specify color, text, and there may be some minor tweaks to style, the
end logo will be look extremely similar to what we decide here.
Thanks.
Cary Bass
Volco
Wikimedia Foundation
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJId9LyQg4JSymDYkRAqULAKCjK7gbiVAnQUdXQ5QYtjREe4apQgCg1s+t
V8NbsHZwzI4t88umr3dmwRc=
=yS9a
-----END PGP SIGNATURE-----
Hi ya'll,
You may remember way that back in mid-2006 user:Improv started up the
List Syndication Service:
http://meta.wikimedia.org/wiki/LSS
This was an ongoing weekly summary of the mailing lists, particularly
Foundation-L. It was carried on for a good while by Improv and was
then taken on by BirgetteSB, but was dropped in early 2007 and not
picked back up.
I always thought this was a great idea that should be continued. And
so finally, I've taken a stab at recreating and rebooting LSS:
http://meta.wikimedia.org/wiki/LSS/foundation-l-archives/2008_November_2-15
This update covers from November 2-15 (two weeks, Sun. to Sat.) of
Foundation-L. I've made some changes from previous summarizers:
* summary by topic, not date; related threads grouped together
* no attempt to read and distill the content of posts -- instead
simply noting what topics were discussed. It was the heavy burden of
reading and understanding all the (quite complex) threads on the lists
that I believe led previous summarizers to burn out. For this summary,
if you want to know more, you have to read the threads yourself.
I hope that this will prove helpful in pointing out *what* was
discussed, particularly for people who don't have time to read the
whole list, even if the substance isn't there.
I make no promises, but will attempt to keep up with foundation-l for
a while. Suggestions, feedback, helpers, etc. all welcome.
best,
-- phoebe
--
* I use this address for lists; send personal messages to phoebe.ayers
<at> gmail.com *
I am making now one site (about pseudoscience) which I want to
double-license, so materials may be used in the future at Wikipedia.
As it is my site, I may make whichever, partial licensing, but I
realized that there is one very stupid problem for which I think that
answer exists, but I would like to hear your (and, especially, Mike's
opinion):
I want to import some Wikipedia materials. Usually, it would be
translations from the Wikipedia in English in Serbian. (For all other
materials I am explicitly asking for double licensing [otherwise, I
wouldn't import them], so this is not a problem.) But, if I import
Wikipedia materials *now*, I may do it only by licensing it under
GFDL. Again, this is not problem related to my site, because I may
declare that such pages are GFDL-only. However, I want to allow that
derivative works from such pages may be used on Wikipedia (in
Serbian), again.
My common sense explanation would be that I may keep such pages
temporary as GFDL-only and to allow GFDL/CC-BY-SA after Wikipedia
switch to double licensing. But, I am not a lawyer and I am wondering
is it possible to interpret the whole licensing process like that.
Gerard wrote: "Given that it is important for the editors to understand what is intended with Flagged Revisions. I would argue that localisation prior to implementation is essential."
I would like to remind Gerard that the requests for FlaggedRevs are based on the
consensus of live wiki communities that are flourishing, building education materials in
their local languages, who value localization of the software and contribute to it, and yet
do NOT necessarily agree with Gerard on localization as a prerequisite to functionality.
On the contrary, many of us believe that unlocalized messages, when viewed live and actually used for real material (not on a test wiki) are far easier to localize little by little
(wiki style) over a period of time. The Hebrew Wikisource indeed began this way: Many
basic messages were not localized initially, and the initial contributers along with building
content on the wiki also localized the messages over time. Had substantial localization
been required in advance the wiki would probably have never been created and the
localization would thus never have been done...
Gerard, you and the Language Committee have been given authority to require substantial
localization before setting up a new language wiki. For better or worse. But you have NO
authorization to prevent active communities from getting extensions implemented
that they have requested.
We at the Hebrew Wikisource intend to finish translating the interface over time, at
Betawiki, as we encounter the system messages in real contexts. We have already been
waiting for implementation for quite a long time. We ask the developers to honor our
community request and consensus. Gerard is entitled to his opinions, but not
to force his notions on active Wikimedia communities.
Dovi
> Hoi,
> I think it makes sense to have functionality like FlaggedRevs be localised
> prior to it being enabled. Given that it is important for the editors to
> understand what is intended with Flagged Revisions. I would argue that
> localisation prior to implementation is essential. I do appreciate
> discussion this.
>
People often do not complain when they think it is normal that new
functonality comes without localisation. It does not have to be this way;
you can have new functionality localised by keeping your localisation up to
date at Betawiki.
Thanks,
GeradM
Hoi,
I think it makes sense to have functionality like FlaggedRevs be localised
prior to it being enabled. Given that it is important for the editors to
understand what is intended with Flagged Revisions. I would argue that
localisation prior to implementation is essential. I do appreciate
discussion this.
The Hebrew localisation is at 23.05%, Ukranian at 65.60%, Hungarian at
89.36%, zh-classical at 5.67%, Russian at 91.13% and Alemannisch at 0%. The
German, Esperanto and French localisation are done completely. The
localisation is done for other languages as well, they have not requested it
for now.
Thanks,
GerardM
http://translatewiki.net/wiki/Translating:Group_statistics
On Mon, Nov 10, 2008 at 1:14 AM, Luiz Augusto <lugusto(a)gmail.com> wrote:
> According to
> http://noc.wikimedia.org/conf/highlight.php?file=flaggedrevs.php,
> FlaggedRevs is enabled on de.wikipedia, ru.wikipedia and en.wikinews.
>
> The extension is requested to get enabled on als.wikipedia
> (bugzilla:13968),
> de.wiktionary (13969), pt.wikinews (14254), en.wikibooks (14618),
> he.wikisource (14648), zh-classical.wikipedia (14715), eo.wikipedia
> (14728),
> ru.wikiquote (14863), ru.wikisource (15006), uk.wiktionary (15335),
> fr.wikinews (15346), hu.wikipedia (15568), pl.wikipedia (16177).
>
> Is there any special reason for not enabling on those wikis (like extension
> still needs to be fixed for security/stability issues) or it is only the
> usual backlog at shell requests? Is recommendable to make more requests at
> this time or to wait a few more months?
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
Hello,
Now, the Wikipedia Academy in Lund has ended. A big success, as the number
of participants was double the number we had anticipated. The entire
conference was covered by three bloggers, collected here:
http://wikipediaacademy.blogspot.com/ (Swedish, but translatable for example
via Google), where there also are some pictures. Soon, some of the lectures
will be uploaded there as well. More info will also be published here, as
soon as I can catch my breath a little: it has been three hectic days for me
and the rest of the team of volunteers, but the main work was carried out by
professionals from the Lund University Library who collected a splendid list
of speakers, including one who spoke on inclusionism/exclusionism, two who
spoke on source criticism, two who spoke on the legal aspects of Wikipedia,
and several others.
This was also the release of the *new* version of "Så fungerar Wikipedia"
(roughly "How Wikipedia Works", but not the book by the three
english-speaking Wikipedians, but by me), published by a real publishing
house and not Print-on-demand. A total of 46 copies were sold, including
copies to all the speakers. This means that the book from now on will be
sold through regular channels such as Swedish internet bookshops and
ordinary book shops. It is already listed in the official library catalogue.
Best wishes,
--
Lennart Guldbrandsson, chair of Wikimedia Sverige and press contact for
Swedish Wikipedia // ordförande för Wikimedia Sverige och presskontakt för
svenskspråkiga Wikipedia
Hi,
For some reasons, the banner at the top of the French wikipedia has been
switched to the english version. That's ridiculous.
Who is able to switch it back to the French version and landing to the
French speaking donation page ?
Thank you
Anthere