body:
On the other hand, if we have separate Wikipedias for each Romani
variety, they will be able to reach all literate Roma.

Mark

On 25/03/06, Alin Dosoftei <desiphral at gmail.com> wrote:
> By now the "Standard Romani" is a bit in a ideal phase, with more centers of
> developement worlwide. Already there are some differences in the way I have
> written and the way the other Romani user has written,  but this does not
> impede the mutual understanding. Personally I don't have in my mind a wiki
> confined only to some specific patterns of the Romani language picked from
> those disponible worldwide. Speakers of every dialect would be welcomed to
> contribute to rom.wiki, and if there is standing power to make wikis in
> specific dialects, let them run. But for the beginning there is standing
> power for a general Romani Wikipedia.
>
> Also, the evolution of the standardized form, is not based only on Vlax
> Romani. As I wrote in the English article abot the Romani language, Romani
> taught in schools from Romania has mostly the pronunciation and grammar
> style of the older non-Vlax dialects, considered closer to the original
> language. The language used till now for the Romani Wikipedia is not quite
> Vlax, it does not stand for a Vlax Wikipedia.
>
> Desiphral
>
> On 3/25/06, Mark Williamson <node.ue at gmail.com> wrote:
> >
> > The comparison to Kurdish isn't exactly valid -- the Kurdish Wikipedia
> > doesn't use a single "standard form", but rather has separate
> > "sections" for each dialect, beccause quite simply there is no
> > Standard Kuridsh.
> >
> > Mark
> >
> > On 25/03/06, Alin Dosoftei <desiphral at gmail.com> wrote:
> > > Have a look at the debate for the test Romani Wikipedia, at my last
> > comment:
> > >
> > >
> > http://meta.wikimedia.org/wiki/Requests_for_new_languages/Vlax_Romany/Discussion
> > >
> > > My point is that if it is will to make Wikipedias in other dialects,
> > it's
> > > OK, but I don't think this is an impediment to have one for the standard
> > > form.
> > >
> > > On 3/25/06, Mark Williamson <node.ue at gmail.com> wrote:
> > > >
> > > > As far as I know, although there is a "standard romani", it doesn't
> > > > totally bridge all Romani languages as it intends (it is apparently
> > > > based mostly on Kalderash), and is not intelligible to diverse
> > > > varieties such as Ursari, Sinte, or Baltic.
> > > >
> > > > I don't think it's right for any single language to claim to be "*the*
> > > > Romani language", I think rom.wp should be a portal.
> > > >
> > > > mark
> > > >
> > > > On 25/03/06, Alin Dosoftei <desiphral at gmail.com> wrote:
> > > > > Thank you!
> > > > >
> > > > > But the proposed code name is rom. not rmy. which is only for the
> > Vlax
> > > > > Romani dialect. Is it because I forgot to change it at the Meta page
> > for
> > > > > requests? Vlax was the first proposal but then the test changed to
> > > > Standard
> > > > > Romani and I made the changes from rmy to rom wherever I found the
> > older
> > > > > code.
> > > > >
> > > > > Also in English it is favoured the spelling Romani instead of
> > Romany,
> > > > > because this is the way the other Indo-Aryan languages are spelled:
> > > > Hindi,
> > > > > Bengali, Marathi, Kashmiri etc. The Romani dialects are spelled also
> > > > like
> > > > > this: Drindari, Erli, Jambashi etc. and even the dialects of other
> > > > languages
> > > > > spoken by Roma (with only Romani vocabulary) like Pogadi. *Romany*
> > look
> > > > > awkward together with other Indo-Aryan languages.
> > > > >
> > > > > On 3/25/06, Wikipedia Romania (Ronline) <rowikipedia at gmail.com>
> > wrote:
> > > > > >
> > > > > > Just a question - none of the Wikipedias so far seem to have a
> > > > localised
> > > > > > interface. The Romany Wikipedia (code RMY) has a nearly
> > > > fully-translated
> > > > > > localisation file at:
> > > > > >
> > > > > > http://meta.wikimedia.org/wiki/LanguageRom.php
> > > > > >
> > > > > > (This file still contains some Romanian-language fragments)
> > > > > >
> > > > > > Once this file is fully translated, how is it possible to update
> > the
> > > > > > interface?
> > > > > > Neither me nor the native Romani user, Desiphral, know how to use
> > the
> > > > CVS
> > > > > > system.
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > Ronline
> > > > > >
> > > > > > 2006/3/25, Servien Ilaino <servien at gmail.com>:
> > > > > > >
> > > > > > > YEEEAAAH!! Finaly!! :D
> > > > > > >
> > > > > > > Serv
> > > > > > >
> > > > > > >
> > > > > > > 2006/3/25, Wikipedia Romania (Ronline) < rowikipedia at gmail.com>:
> > > > > > > >
> > > > > > > > WOO HOO!!!
> > > > > > > > Thanks so much for that!
> > > > > > > >
> > > > > > > > 2006/3/25, Jens Frank < JeLuF at gmx.de>:
> > > > > > > > >
> > > > > > > > > Hello,
> > > > > > > > >
> > > > > > > > > the following wikipedias have been created:
> > > > > > > > >
> > > > > > > > > nds-nl
> > > > > > > > > rmy
> > > > > > > > > lij
> > > > > > > > > bat-smg
> > > > > > > > > map-bms
> > > > > > > > > ksh
> > > > > > > > > pdc
> > > > > > > > > vls
> > > > > > > > > nrm
> > > > > > > > > frp
> > > > > > > > > zh-yue
> > > > > > > > > tet
> > > > > > > > > xal
> > > > > > > > > pap
> > > > > > > > >
> > > > > > > > > See also
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> > http://meta.wikimedia.org/w/index.php?title=Approved_requests_for_new_languages&oldid=310831
> > > > > > > > >
> > > > > > > > > Regards,
> > > > > > > > >
> > > > > > > > > JeLuF
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Echte DSL-Flatrate dauerhaft f?r 0,- Euro*!
> > > > > > > > > "Feel free" mit GMX DSL! http://www.gmx.net/de/go/dsl
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > _______________________________________________
> > > > > > > > > Wikipedia-l mailing list
> > > > > > > > > Wikipedia-l at Wikimedia.org
> > > > > > > > > http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > Wikipedia-l mailing list
> > > > > > > > Wikipedia-l at Wikimedia.org
> > > > > > > > http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
> > > > > > > >
> > > > > > > _______________________________________________
> > > > > > > Wikipedia-l mailing list
> > > > > > > Wikipedia-l at Wikimedia.org
> > > > > > > http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
> > > > > > >
> > > > > > _______________________________________________
> > > > > > Wikipedia-l mailing list
> > > > > > Wikipedia-l at Wikimedia.org
> > > > > > http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
> > > > > >
> > > > > _______________________________________________
> > > > > Wikipedia-l mailing list
> > > > > Wikipedia-l at Wikimedia.org
> > > > > http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
> > > > >
> > > >
> > > >
> > > > --
> > > > "Take away their language, destroy their souls." -- Joseph Stalin
> > > > _______________________________________________
> > > > Wikipedia-l mailing list
> > > > Wikipedia-l at Wikimedia.org
> > > > http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
> > > >
> > > _______________________________________________
> > > Wikipedia-l mailing list
> > > Wikipedia-l at Wikimedia.org
> > > http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
> > >
> >
> >
> > --
> > "Take away their language, destroy their souls." -- Joseph Stalin
> > _______________________________________________
> > Wikipedia-l mailing list
> > Wikipedia-l at Wikimedia.org
> > http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
> >
> _______________________________________________
> Wikipedia-l mailing list
> Wikipedia-l at Wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
>

--
"Take away their language, destroy their souls." -- Joseph Stalin


list: wikipedia-l

source: pipermail-mbox

body:
the pre-1942 collection are and will remain quite nominal. They are a
drop in the bucket compared to revenues of more contemporary sound
recordings. In fact, I've heard some rumours (unsubstantiated) that
Sony BMG is *losing* money on its pre-1942 collection. But even if
this is not true, they clearly are making very little money on their
pre-1942 sound collection (it would not surprise me if Sony BMG's top
artist today probably makes many times more money for Sony BMG than
the entire pre-1942 collection does -- and Sony BMG has hundreds of
very profitable artists and thousands of more minor artists. Figure
out the math and the pre-1942 collection is a drop in the bucket. Sony
BMG may actually be happy to get rid of the collection for $50
million plus some good PR.)

Anyway, is there any harm in negotiating with Sony BMG? Until they are
asked, we really don't know what their reaction will be. Anyone coming
in with $100 million in their pocket will probably get an immediate
lunch with Sony BMG's chairman, that's for certain. <laugh/>

> For much of the stuff that they hold, copyrights may very well have
> expired, but if they have the unique copy of one of these works, they
> still have the right of possession, and will milk it for what it's worth
> to them.

NO!

Read the article I wrote. The sound recordings are NOT covered by
Federal copyright law, but by a patchwork quilt of state laws. The
recent "Capitol vs. Naxos" copyright ruling was issued by New York
State Supreme Court, which held for the plaintiff. So, in essence,
Sony BMG holds *state copyright* rights to the collection, and it
is enforceable just like Federal Copyright is enforceable. And state
copyright laws are more onerous than is Federal Copyright law.

And from the rulings, the recording companies don't have to hold the
original metal parts to maintain ownership of the recordings. They
just have to prove in court that they own them "on paper", and for
the major labels from the pre-1942 era it is very easy to demonstrate
the chain of ownership -- it is well-documented.

>> For background information on the unusual copyright status of early
>> U.S. sound recordings (which is surprising!), and whether or not Sony
>> BMG might even be interested, refer to the article I wrote about the
>> topic of freeing the older sound recordings:
>>
>>   http://www.projectgramophone.org/TeleRead-Article-01Nov2003.html
>>
>> (Especially refer to the section entitled: "A Note To The Major Media
>> Companies: Why Not Donate Your Older Sound Recording Catalogues?")

> I read your article, but I think you exagerate the legal points.
> Copyright is a federal matter, and I don't see any state copyright laws
> withstanding a constitutional challenge.  The burden of proving
> perpetual royalty rights on a very old recording falls on whoever is
> alleging that such a contract exists.  If nobody can find the old
> contract the effect would be the same as if it had never existed.  They
> are not indeterminable.

Yes, Copyright is a Federal matter. and the U.S. Congress has decided
NOT to cover pre-1972 sound recordings with Federal Copyright
protection. At present sound recordings are covered by the patchwork
quilt of state laws mentioned above and in the article I wrote. And
refer to the Capitol vs. Naxos decision. When Federal law kicks in, it
then pre-empts state law, but unless Congress acts sooner, for
pre-1972 sound recordings we won't see that happen until 2067.

The royalty issue I don't deem to be critical for what we are talking
about.

But to the recording companies, it is a big deal. For a long while
MCA, which held the Decca collection, refused to reissue any of their
older recordings because they were unsure of their royalty status. And
they denied third-party requests to reissue the Decca stuff. This led
to a period of time when NOTHING from the Decca collection was legally
reissued.

Jon Noring


body:
possible exception) have laws, either common or statutory, which can
be used to protect the "monopoly ownership" of sound recordings. They
range from copyright to "unfair competition".

So trying to bypass New York state won't really help. Capitol had
several states they could have proceeded with their lawsuit, and
simply chose New York. So long as Naxos did any business in a
particular state, a lawsuit could have been brought up there. With
the Internet, the venue gets fuzzy, but probably makes it easier to
claim doing business in any of the states of the country, even if
the "home" of the effort is done in a "safe" state (if one even
exists.)

I think the important thing is that pre-1972 U.S. sound recordings
are covered pretty much nationwide with a web of laws that in
aggregate is similar enough to Federal Copyright law to be considered
the same -- and probably worse than Federal Copyright law (e.g.,
commercial recordings from 1889 are still protected in many states
until 2067 -- that will be 178 years of copyright-like protection.)

> From a Wikimedia perspective sound recordings are still only a small
> part of the material that needs to be freed.  Any portion of the $100
> million applied to these recordings should be in proportion to the
> overall distribution of Wikimedian interests.

I agree that sound recordings are only a part of the corpus of works
that should be freed. Those who know me know I'm active in the Public
Domain community (e.g., Project Gutenberg, Distributed Proofreaders,
LibraryCity, and the proposed Top 1000 books project). I'm also very
interested in digitizing local materials.

But the older commercial sound recordings have uniquenesses that make
them particularly interesting to free:

a) Availability -- the public has little access to the wide range of
   sound recordings (simply due to the fragility of records and no
   access to playback equipment), while copyrighted books are much
   easier for the public to find (some library or bookstore has them,
   or a reissue) and read. 99% of all commercial sound recordings are
   very obscure, not having been reissued (or the reissues are
   themselves very obscure) held only by a few collectors and
   archives, and hard for anyone in the public to access, much less
   know they even exist.

   It is now possible to digitize en masse the whole corpus of sound
   recordings and make them all available to the public -- if the laws
   allow, which they don't.

b) The performances and lyrics are of great cultural significance, on
   par with any corpus of books. Sound recordings capture a unique
   look at the culture of the time that cannot be captured with books.
   I'm not saying sound recordings are superior, but they are not
   inferior, either. Different and valuable in their own right.

> While it is clear that our organizations have a common interest in
> freeing material from copyright, I would question the
> appropriateness of turning over any significant portion of these
> funds to another organization for the furtherance of its objetives.

Well, I understand what you are saying.

But I am not proposing that the funds be turned over to another
organization. Most of the funds will go towards the acquisition of
the rights of ownership to the works (here sound recordings) which
*will* be turned over to the Public Domain -- the rights will not be
owned by some other group. This means that anyone can digitize old
sound recordings they acquire and put them online or whatever -- no
single group will hold an access monopoly on the sound recordings.

And note that, regardless of the medium (books, film, sound recordings,
etc.), there has to be people to administer the acquisition, and be
involved with cataloging, storage, digitization, etc. This costs some
$$$ (how much depends upon the kind of media.) Yes, film and sound
recordings will have a higher cost of handling, storage and
digitization (we can assume with books a DP process could be used for
scanning and digitization), which has to be paid for from somewhere.
(As noted, however, there are thousands of people who will, on their
own, digitize the old sound recordings, with varying levels of
quality, so there will be no monopoly on access to the recordings.)

My prior comment was to note that there already exists a team of
experts (who've been studying this issue and are dedicated to the
freeing of the older sound recordings) pretty much ready to go to help
with the sound recordings project -- if I were the one with the $100
million, I would consider this *vitally* important.

And I know we can leverage other like-minded organizations such as
ARSC and the Internet Archive (yes, I've name dropped Brewster Kahle's
name -- he *is* very interested in getting all the old sound
recordings online) to help out with some of the needed things such as
preserving, archiving and possibly even setting up a place to store
the still-existent metal parts (the recording companies like Sony BMG
will likely not sell their old sound collections until we have a place
to store them -- Brewster has talked about a facility to hold all
kinds of media artifacts, and the masters could be stored there if
that facility comes into existence.)

Heck, with a team of people and organizations working together, we
could probably find "matching" funds somewhere and leverage the
manpower and expertise of this project to begin purchasing the rights
to other types of materials, such as various types of books. So this
records project can be a springboard to a major acquisition of rights
to all kinds of works. In fact, if I had the $100 million, I would be
figuring out how to leverage that money to acquire the rights to all
older works.

So even if this project "furthers our objectives" (where "our"
refers to me and the people who I am associated with), our objectives
are totally in synch with the goals of the $100 million -- to free
up currently encumbered works for the public to *own* and *enjoy*.

The team I'm working with will be happy to put together a detailed
proposal (like a business plan) pretty quickly if the person with
access to the $100 million formally asks us. We are ready...

Jon Noring

(p.s., I reacquainted myself with who owns what of the pre-1942 U.S.
sound recordings:

Sony BMG:  RCA Victor, Columbia/Okeh, and ARC (a bunch of minor labels)
Universal: Decca, pre-ARC Brunswick and Vocalion, and Gennett/Champion
EMI:       Capitol (founded in 1942, so mostly outside our scope, but
                    was a major label in the 1940's and 50's.)

The National Park Service (Federal gov't) owns the Edison collection,
which has, I reckon, about 80,000 to 100,000 recordings -- a lot of
them cylinders -- Edison went belly-up in late 1929. Although there
is controversy about the copyright status of the Edison collection,
most assume the recordings are free to use. There were a few minor
labels whose ownership is individual, questionable or abandoned,
notably the "Grey Gull" group (with about 5000 to 7000 recordings)
which sold records in the 1920's and very early 30's.

But by and large, I would *roughly* guess that 80-90% of all the
pre-1942 recordings ever "waxed" in the U.S. are owned by Sony BMG.
But the Universal Music Group pre-1932 Brunswick and Vocalions also
hold a pretty solid collection of material, mostly from the 1920's,
and they should also be approached. Combine that with the Edison and
likely abandoned "Grey Gull", and we would have essentially 99%
coverage. The remaining 1% we can probably use or secure the rights
to for relatively little.)


body:
Singlish had considerable support.

With several million native speakers, Singlish has its own unique
grammar and vocabulary.

On 1/12/07, Zordsdavini iz Litvy <zordsdavini at gmail.com> wrote:
> So, when these 8 wikipedies will be created?
> And second question: where can I read more about these ISO-CD-639-6.
>
> Arns Udov???
>
> 2007/1/12, Gerard Meijssen <gerard.meijssen at gmail.com>:
> >
> > Hoi,
> > People can always start on the Incubator and show that they have what it
> > takes. The notion of the Incubator is that by working on the Incubator
> > there will be something that will indicate that it is just a flash in
> > the pan.. Someone saying: "Would it not be nice" and then doing nothing.
> > We have asked Brion to include the "BetaWiki" functionality so that
> > people can start on the localisation of that language and for all
> > projects to maintain the localisation of MediaWiki on a MediaWiki server.
> >
> > Brion indicated that it can get on his "to do" list after release 1.9
> > (done) and SUL (his current priority). When the language files are
> > ALWAYS generated for new languages, we will not get the sad situation of
> > the Marathi projects where the localisation is said to be overwritten
> > with new releases. Localisation will be done at Incubator and, new
> > messages once translated there can be exported to at least all the
> > Wikimedia Foundation projects. External projects will benefit with new
> > releases.. :)
> >
> > For languages that do not have an ISO-639 code, the notion of granting a
> > project is problematic. We hope to announce within the month much of the
> > content that is in the ISO-CD-639-6 AND a procedure in which you will be
> > able to get recognition under the standard that is being worked on. NB
> > this standard will have some 25.000 linguistic entities to start off
> > with and many of them are spoken only or signed languages.
> >
> > Thanks,
> >      GerardM
> >
> >
> >
> > Zordsdavini iz Litvy schreef:
> > > But what You could suggest for approved languages? Why people have to
> > wait
> > > so much time. They will run away.
> > >
> > > Arns Udov???
> > >
> > > 2007/1/12, Gerard Meijssen <gerard.meijssen at gmail.com>:
> > >
> > >> Hoi,
> > >> Singlish was denied in the past.. I do not know why you would suggest
> > >> Singlish in the first place. It is not recognised as a language, it has
> > >> the status of "invented" language, it does not have the same notability
> > >> as Ido Interlingua Esperanto ..
> > >> Thanks,
> > >>     GerardM
> > >>
> > >>
> > >>
> >
> http://meta.wikimedia.org/wiki/Requests_for_new_languages/Wikipedia_Chinglish
> > >>
> > >> J.L.W.S. The Special One schreef:
> > >>
> > >>> I'd suggest a Singlish Wikipedia and Singlish Wiktionary.
> > >>>
> > >>> On 1/10/07, Dan Collins <en.wp.st47 at gmail.com> wrote:
> > >>>
> > >>>
> > >>>> Zordsdavini iz Litvy wrote:
> > >>>>
> > >>>>
> > >>>>> Hello,
> > >>>>> I don't understand why new wikis are nor been creating. The people
> > >>>>>
> > >> will go
> > >>
> > >>>>> out of this because some of them are waiting for the year...
> > >>>>>
> > >>>>> Arns Udov???
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>> If you wnat to make a new wiki with the WikiMedia foundation, visit
> > >>>> http://meta.wikimedia.org/wiki/Proposals_for_new_projects
> > >>>>
> > >>>> --
> > >>>> GnuPG key ID is 0x84189146 on subkeys.pgp.net
> >
> >
> > _______________________________________________
> > Wikipedia-l mailing list
> > Wikipedia-l at lists.wikimedia.org
> > http://lists.wikimedia.org/mailman/listinfo/wikipedia-l
> >
>
>
>
> --
> Ok^ ek^ besla ikv Olmok Vzauep^evk
> :)
> _______________________________________________
> Wikipedia-l mailing list
> Wikipedia-l at lists.wikimedia.org
> http://lists.wikimedia.org/mailman/listinfo/wikipedia-l
>

--
Written with passion,
J.L.W.S. The Special One


body:
partir de a "list" with no formal voting and without following any specific
guidelines or policy. On this basis, I believe that the newly adopted policy
could be used  for determining the "correctness" of wikipedias that  were
created in "obscure" ways. In any case, it  is not up to me to decide such a
usage.

As to the valid ISO 639 code.. It is valid indeed in the eyes of the ISO,
but also according to the official POV of the Party of Communists in RM (I
suspect), of the Transnistrian authorities and might have been in the eyes
of the Soviet Authorities. [On a side note: I do not understand how you
expect my arguments to be completely apolitical over an issue that is pure
politics: considering Moldovan as a linguistic entity.]

However, scholarly research - Western included - disputes this. A lot
of linguists
- if not most - do (with the notable exception of Vasile Stati; notable,
because he is the one). The regulating body of the "Moldovan language" -
with regard to the Constitution - disputes this. Less important in the eyes
of the WMF, natives dispute this (though still waiting for someone from
Transnistria here). Please follow the links  in  my  previous messages if
you are not persuaded by this paragraph.

And, probably most important  for the Board, the mo.wiki domain does  not
host content in a linguistic entity different from the Romanian one. It
simply  hosts transliterated Romanian content. I honestly believe that  it
is wrong for  the Foundation to blindly follow the ISO specifications over
this issue. It is also wrong for the Board to adopt - from the NPOV
perspective, which should be respected even if certain flexibility is
endorsed - a political POV over a linguistic/historical fact: at a given
period, in a given region, Romanian was written with a different script.

Regards,
Liviu


list: wikitech-l

body:
4.6) What is the maximum size for a row, table, database?
These are the limits:

Maximum size for a database?             unlimited (60GB databases
exist)
Maximum size for a table?                16 TB
Maximum size for a row?                  unlimited in 7.1 and later
Maximum size for a field?                1GB in 7.1 and later
Maximum number of rows in a table?       unlimited
Maximum number of columns in a table?    250-1600 depending on column
types
Maximum number of indexes on a table?    unlimited

Of course, these are not actually unlimited, but limited to available
disk
space and memory/swap space. Performance may suffer when these values
get
unusually large.
The maximum table size of 16TB does not require large file support from
the operating system. Large tables are stored as multiple 1GB files.

The maximum table size and maximum number of columns can be increased if
the default block size is increased to 32k.

Jonathan

--
                     Geek House Productions, Ltd.

  Providing Unix & Internet Contracting and Consulting,
  QA Testing, Technical Documentation, Systems Design & Implementation,
  General Programming, E-commerce, Web & Mail Services since 1998

Phone:   604-435-1205
Email:   djw at reactor-core.org
Webpage: http://reactor-core.org
Address: 2459 E 41st Ave, Vancouver, BC  V5R2W2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: not available
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20021116/9a7832b7/attachment.pgp>


body:
history, watchlist, current events), but this of course shouldn't be too hard
to implement and I suppose that it's in plan.

They are using UseMod for their wiki, and Kendra is made in Python. So I don't
think that there is much possibility for direct cooperation - surely, ideas
could be exchanged, but Kendra can't just be poured into MediaWiki. OTOH, the
Kendra site is done in PHP, so probably some of their developers know PHP.


body:
http://blogs.msdn.com/ie/archive/2005/04/22/410963.aspx

though that won't be very useful for backward-compatible software like
MediaWiki.

--
                    /L/e/k/t/u


body:
ICFAI

Dear Sir,

 We find the article titled "Economy of Sri Lanka " quite useful and thus we would like to incorporate it in our forthcoming executive reference book on "Sri Lankan Economy" Hence we request you to permit us to publish the above referred article in our journal book.

 Institute of Chartered Financial Analysts of India (ICFAI) is a non-profitable organization established to impart quality education in management and finance. Our publication wing "ICFAI Books" is publishing various digest journals/magazines and executive reference books for use of student of our institution for the purpose of academic discussion, study and research, besides application in practical functioning. It is basically a wing of our academic institution, meant for publishing to cater to the educative needs of students and staff. However journals/books are priced to recover the cost of editing, printing and distribution and not for making profits. Any money that eventually earned, if any, over and above the costs would be naturally included into the publication/academic pool for the above referred objectives only.

 Besides generating original articles and books, we are deliberately providing enough fields for accommodating plurality of views and multiplicity of ideas for the benefit of learning and free flow of different thought on a variety of topics.

 Hence, we seek your permission for publishing the above-mentioned article in our forthcoming book on "Sri Lankan Economy" and expect continued cooperation for spread of knowledge. We will acknowledge the source with due respect/as per your suggestion.

 We would be glad if you can send us an early reply as we have a fast approaching deadline.

Thanking you,

Aparna Bellur

(Member, Editorial Team)

ICFAI Books

71, Nagarjuna Hills,

Punjagutta, Hyderabad- 500082

INDIA.

Phone: 91 040 23435387/88

Fax: 91 040 23435386


body:
think of any other confederation in history or in the modern world having 20
official languages?

Welsh has been spoken in the Europarl. Sorry but I don't have a handy link
right now.

--
NSK
The Wikinerds Community Federation of Science Wikis
Owner of the Wikinerds Portal http://portal.wikinerds.org
Owner of the NerdyPC IT Wiki http://www.nerdypc.org


body:
A database query syntax error has occurred. This may indicate a bug in the
software. The last attempted database query was:
SELECT cur_id,cur_namespace,cur_title FROM `cur`,`links` WHERE cur_id=l_to AND
l_from=1387711 FOR UPDATE
 from within function "LinkCache::preFill". MySQL returned error "1213:
Deadlock found when trying to get lock; Try restarting transaction
(10.0.0.1)".

Article
Discussion
Edit this page
History
Move

--
NSK
Come to see the new wikiprojects at http://portal.wikinerds.org


body:
means is "it's hard to read the markup in a web browser's text editor,
particularly in Firefox, so sometimes people get confused and type things in the
wrong order when editing".

Unfortunately mixing markup characters, a right-to-left environment, and
left-to-right numbers and keywords often does lead to an illegible mess in the
basic text editor widgets that you'll find in a web browser.

Please note that:

1) Localized (thus right-to-left) keywords can be provided if necessary.

2) Numbers are left-to-right even in the right-to-left scripts. *You thus cannot
avoid mixed-directionality text when doing "math" stuff.*

> I take it this code is
> still very much experimental until it works properly for *all *the
> languages Wikimedia uses MediaWiki for. It would therefore be better to
> wait replacing templates until this functionality works properly.

and most importantly:

3) This is no different from the case of templates, whose syntax and markup
usage is nearly *identical* to this extension.

The argument given here thus fails on its face, as it would apply equally
against the use of existing templates.

-- brion vibber (brion @ pobox.com)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20060413/d00f791d/attachment.pgp>


body:
-- brion vibber (brion @ pobox.com)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20060315/1802ad4e/attachment.pgp>


body:
-- brion vibber (brion @ pobox.com)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20060911/81709913/attachment.pgp>


body: stick up their lavender passageway


body:
six months

One of the edit summary's was;
"Relax; these are completely harmless, and just for a day. "Yes, we're
aware of Wikipedia's criticisms, and we're still confident enough in
our project that we can joke about it"

== On topic ==

When I requested the page;
http://en.wikipedia.org/wiki/Blue_Gender

around midnight 2008-04-07  I noticed that the tagline on that page was;

"From Britannica, the encyclopaedia that is slightly more accurate
than Wikipedia according to a paper in the eminent journal
''Nature''...  "

When I logged in it was gone, back the normal one. Also when I logged
out again it was also again the normal tag line.

== My question ==

How does the caching works?

I suspect that I have seen that changed tag line on that page because
that specific page was cached just in that very short time frame the
tag line was changed to that text.  And because the page was not
edited that cached version was not renewed.

What I like to know is how long can cached version being used to show
a page when it is requested? When does it expire?

And because there are many squids; can it be that depending the squid
who serves you can get different results?

I would like to know that for use in wikizine.
--
Contact: walter AT wikizine DOT org
Wikizine.org - news for and about the Wikimedia community


body:
transforms every space in a file into a newline, then runs diff on it. This
could be simulated in PHP too.


body:
default priority and consider high priority as "This should be fixed
by next release", IMHO.

--
Best regards,
  Max Semenik ([[User:MaxSem]])


body:
(1) Telestream ScreenFlow (http://www.telestream.net/screen-flow/overview.htm)

(2) Mac OS 10.6 podcast capture (but this requires a podcast server, i.e., Mac OS 10.6 server, and I am not sure it's worth it).

(3) Matterhorn capture (http://www.opencastproject.org/matterhorn_capture)

We are leaning towards solution (1). We welcome any comments, any alternative solutions that we may explore, or any arguments for (2) and (3).

Cheers,

Panos.

On Jan 21, 2011, at 4:07 PM, Jan Paul Posma wrote:

> So a few minutes ago we've had a conversation about this. Panos will set up a public collaboration space within GRNET. A few developers will be (part-time) working on this from February for a (so far) unspecified amount of time. The consensus was that it would be good to start off with some basic usability testing, to see how well the different tools work for novice users. It'll be very basic testing, with about 10 subjects from within GRNET (so with a bit of technical bias) but only those who haven't edited before.
>
> Both Magnus' and my tools will be implemented on a clone of the Greek Wikipedia and we will set up a fabricated article that works well with both of our editors. It's only about the usability, not about technical aspects for now. Both editing tools will have to be adapted and localised, perhaps this can even be done by GRNET developers. We'll use my usability script that I used before with the Sentence-Level Editing usability research.
>
> Once this usability testing has been done, we'll decide how to distribute the efforts, and what will be done. We'll work closely with the GRNET developers to assist them in working on these projects. Once we'll have more information it will be posted to this list.
>
> Cheers,
> Jan Paul
>
> On 19-Jan-2011, at 23:34, Magnus Manske wrote:
>
>> I have added Panos to Skype; yes, we should probably exchange Skype
>> handles off-list.
>>
>> I am in Cambridge (London time), so that should work.
>>
>> Cheers,
>> Magnus
>>
>>
>> On Wed, Jan 19, 2011 at 8:34 PM, Jan Paul Posma <jp.posma at gmail.com> wrote:
>>> Skype sounds great! Also, I heard you work with Ariel, which is great because that way you have a more local person to contact with MediaWiki questions. Perhaps we can get off-list with those interested to schedule an introductory meeting? (You, me, Magnus, Ariel, others?) I am located in the Netherlands, so our hours will be similar.
>>>
>>> Cheers,
>>> Jan Paul
>>>
>>> On 19-Jan-2011, at 19:47, Panos Louridas wrote:
>>>
>>>> Thanks to both Jean Paul and Magnus for taking up the offer!
>>>>
>>>> Based on your input I will look into our developer tool for people with expertise in the following:
>>>>
>>>> * Advanced JS, preferably with experience in optimisation issues etc.
>>>>
>>>> * UI design, usability testing, etc.
>>>>
>>>> * Text processing (of sorts) for the needs of SLE
>>>>
>>>> (if you believe I am missing something, say so)
>>>>
>>>> I expect to have the people in place in February, I will let you know. I will be following the list.
>>>>
>>>> Jean Paul indicated that we might talk in more detail. I do not follow IRC because of my tight schedule; I do use Skype, however (ID: louridas). Please Jean Paul, Magnus, and others, let me know if that suits you. As I am located in Athens, my waking hours are around East European Time.
>>>>
>>>> Cheers,
>>>>
>>>> Panos.
>>>>
>>>> On Jan 19, 2011, at 3:54 PM, Jan Paul Posma wrote:
>>>>
>>>>> A very generous offer indeed!
>>>>>
>>>>> My own SLE and Magnus' WYSIFTW are indeed the most active projects, so that would be a good bet. Actually, for me the timing is just right, as I'll be working on a paper about this editor for a while, so it'd be cool to have someone(s) continue the project. If one of your researchers has a brilliant idea on how to do this right, that would obviously be really valuable too.
>>>>>
>>>>> A lot of things Magnus mentioned apply to my project too:
>>>>> * Improving detection algorithms, i.e. better sentence-level editing (perhaps using an external language recognition library), better detection of other elements. Keep in mind that the editor excludes anything it doesn't 'understand', so this is a nice fallback, you don't have to write a complex parser that detects a lot of stuff at once.
>>>>> * Cross-browser/platform/device compatibility (think mobile, touchscreens, etc.)
>>>>> * Usability testing (the more the merrier!)
>>>>> * Verifying detection coverage (Which % of the wikitext is editable) and quality (Wikitext -> Adding markers -> MediaWiki parser -> Removing markings -> Wikitext??) Checking this on a large number of pages.
>>>>> * Test suites (again, the more the merrier, but only for parts of the code and interface that are considered stable!)
>>>>> * Lots of implementation details: embedding the (current) editor toolbar in the textboxes, making sure (a fair percentage of) gadgets still work with this, and handling unusual cases like edit conflicts, etc.
>>>>>
>>>>> Perhaps it'd be good to have a (video or IRC?) conversation with you, your developers, people from the Foundation, and people from the specific projects you want to contribute to. Again, really awesome that you guys want to work on this! :-)
>>>>>
>>>>> Best regards,
>>>>> Jan Paul
>>>>>
>>>>> On 19-Jan-2011, at 9:55, Magnus Manske wrote:
>>>>>
>>>>>> On Mon, Jan 17, 2011 at 1:47 PM, Panos Louridas <louridas at grnet.gr> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> At the Greek Research and Education Network (GRNET) we look at the possibility of contributing to the development of WYSIWYG editor support in Wikipedia. We understand that considerable work has already taken place in the area, e.g.:
>>>>>>>
>>>>>>> * http://www.mediawiki.org/wiki/WYSIFTW
>>>>>>> * https://svn.wikia-code.com/wikia/trunk/extensions/wikia/RTE/
>>>>>>> * http://www.mediawiki.org/wiki/User:JanPaul123/Sentence-level_editing
>>>>>>>
>>>>>>> We therefore think that it will not be productive to reinvent the wheel over here.
>>>>>>>
>>>>>>> Our contribution can take the form of providing developers that will devote part (or all) of their time for some months in 2011. We welcome any comments and suggestions on how we could push this forward, and in particular:
>>>>>>>
>>>>>>> * Specific tasks / components that need to be designed, developed, optimized, etc., and estimates of effort and timeframe.
>>>>>>
>>>>>> Hi Panos,
>>>>>>
>>>>>> a very generous offer! One I would like to take you up on, for WYSIFTW
>>>>>> as you no doubt have guessed :-)
>>>>>>
>>>>>> WYSIFTW is approaching feature completeness, as far as wiki markup
>>>>>> parsing is concerned, and improves on usability as well. (just try the
>>>>>> new "floating context hover boxes", in lack of a better name, that I
>>>>>> added last night, wich come up when you hover over a template or a
>>>>>> references, for show/hide and rendered preview, and the new optional
>>>>>> rendering for templates as a key-value-pair table)
>>>>>>
>>>>>> For support later this year, tasks would include
>>>>>> * increase parsing performance (mostly post-parsing steps, focusing on
>>>>>> DOM lookup and manipulation)
>>>>>> * improve editing usability (cut/copy/paste, better specialised
>>>>>> dialogs for images, table/row/cell properties etc.)
>>>>>> * usability testing (I'm using up volunteers fast ;-)
>>>>>> * creating a test suite (to make sure that changes don't accidentally
>>>>>> break anything)
>>>>>> * general compatibility testing (find pages that parse/unparse
>>>>>> wrongly, and patch the code accordingly)
>>>>>>
>>>>>> I like the sentence-level editing function, but once I add
>>>>>> section-level editing to WYSIFTW, these two will start to converge.
>>>>>> I'm curious which of these will be more suited to small fixes and
>>>>>> adding single sentences/references etc.
>>>>>>
>>>>>> As for RTE, I know little about. Apparently, it is not suitable for
>>>>>> Wikipedia in its current form. From brief looks at CKeditor, it might
>>>>>> be quite some work to make it behave nicely around parsed wikitext, as
>>>>>> used on Wikipedia.
>>>>>>
>>>>>> Cheers,
>>>>>> Magnus
>>>>>>
>>>>>> _______________________________________________
>>>>>> Wikitech-l mailing list
>>>>>> Wikitech-l at lists.wikimedia.org
>>>>>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Wikitech-l mailing list
>>>>> Wikitech-l at lists.wikimedia.org
>>>>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>>>
>>>>
>>>> _______________________________________________
>>>> Wikitech-l mailing list
>>>> Wikitech-l at lists.wikimedia.org
>>>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>>
>>>
>>> _______________________________________________
>>> Wikitech-l mailing list
>>> Wikitech-l at lists.wikimedia.org
>>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>>
>>
>> _______________________________________________
>> Wikitech-l mailing list
>> Wikitech-l at lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l


body:
mysql> select count(*), up_value  from user_properties where up_property='skin' group by up_value;
+----------+-------------+
| count(*) | up_value    |
+----------+-------------+
|   150489 |             |
|       15 | amethyst    |
|      229 | chick       |
|      610 | cologneblue |
|      894 | modern      |
|    15072 | monobook    |
|      126 | myskin      |
|      140 | nostalgia   |
|      114 | simple      |
|      257 | standard    |
|     3661 | vector      |
+----------+-------------+
11 rows in set (11.64 sec)

user_touched  is unavailable on Toolserver, so can't make a more
detailed query.

--
Best regards,
  Max Semenik ([[User:MaxSem]])


body:
I should note that there do appear to be a few SMW proposals developing.  It's very unlikely they'll all be accepted.  So keep that in mind when considering your options and proposal ideas.  The GSOC page on MW.org has some other ideas people have been bouncing around you may want to look over.

Thank you,
-greg aka varnent

On Apr 2, 2012, at 9:05 AM, riadh chtara <riadh.chtara at gmail.com> wrote:

> Hello!
>
> My name is Riadh Chtara.I'm Tunisian student.Two years ago I got an
> excellence scholarship from Tunisian Government to study Engineering In
> France.
> And today, I study in Ecole Centrale de Lyon which is one prestigious
> engineering school in France.
> I love web development .
> I know many programming language but one my favorite are
> JavaScript(with jQuery) and php.
> Last year, I made for example a web application called Grimdi Animator<
> http://www.grimdi.com/animator/> (which is a powerful and amazing tool that
> allows you to create cool javascript animation for you website without any
> required programming knowledge. It is very easy and fast. With Grimdi
> Animator you can also dynamically import data and manipulate XML. You can
> use Grimdi Animator to make animations,menus, galleries...)
> This application has today more than 8000 users in Chrome WebStore.Here is
> an example of what you could do with it
> .<http://www.grimdi.com/animator/example.html> It
> is a photo gallery loaded from this XML file
> <http://www.grimdi.com/animator/gallery.xml>
> I'm interested in two idea.The first one is Improving the interplay between
> Spark and SMW and the second one is Semantic Forms Rules.
> I discussed the first idea with  Mr Jeroen De Dauw and Mr Denny Vrandecic,
> unfortunately none of them of them could be a full mentor( Mr Denny
> Vrandecic said he could be a co-mentor).So I am looking for a mentor for
> this idea.If any one want to volunteer please tell me.
> I'm also interested in Semantic Forms Rules.Like I said, I know JavaScript
> and  jquery  very well, the web application I made use basically javascript
> and jquery.I hve a few question to the mentor  jquery (Mr Stephan Gambke)
> and I would  like to ask him some questions.
>
>
> Yours sincerely
> Riadh
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l


body:
interactive states (such as display: none; ) - which, although even those could
be done as a css classes, are even more common.

> I'm not sure what else to say really... I could understand backlash if
> I was suggesting turning off inline styles on the desktop site or even
> the mobile site - but all I'm suggesting here is targeting the beta of
> mobile.

I'm not doubting your judgement. If you believe it is useful to experiment with
this in the beta. I'd say go ahead, deploy it today (its not like you need our
permission or anything :-P). But as I mentioned earlier, I'm not sure what we
would get out of such experiment, since we already seem to know what it will
break and make.

> Thanks for everyones contributions so far on this long thread! I
> really do appreciate this discussion and your patience with me :-).
>

Thanks for making the mobile site awesome!

-- Krinkle

> On Thu, Jun 28, 2012 at 9:37 AM, Brion Vibber <brion at pobox.com> wrote:
>> On Wed, Jun 27, 2012 at 6:35 PM, Krinkle <krinklemail at gmail.com> wrote:
>>
>>> So, stripping inline styles:
>>> * will not fix bad layouts made with tables (which are probably at least as
>>> common as bad layouts made with inline styles).
>>> * will break unrelated things, because inline styles are not directlty
>>> related
>>> to layout, they're used for many things.
>>>
>>> I think provided that there is the following documentation:
>>> * which layout patterns are problematic (whether with inline styles,
>>> tables or
>>> by other means),
>>> * why/how they cause problems
>>> * how to solve that (and how the solution is indeed better for everyone)
>>>
>>> ... then is is a matter of spreading links to that documentation and
>>> waiting
>>> for it to be incorporated on the 700+ wikis with the many many portal
>>> pages,
>>> and other structures that have bad layouts.
>>>
>>
>> I'm generally in agreement with Krinkle on this. But I have to warn that
>> just spreading documentation doesn't magically make things happen -- we
>> probably have to put some actual human effort into finding and fixing
>> broken layouts.
>>
>> A one-button "report bad layout on this page" thingy might well be nice for
>> that; as could an easy "preview this page for mobile" from the edit page.
>> (Though to be fair, people can switch from desktop to mobile layout with
>> one click -- worth trying out!)
>>
>> -- brion
>>
>
> --
> Jon Robson
> http://jonrobson.me.uk
> @rakugojon


body:
extensions [2] in a new tab and looking for i18n related changes.

Raimond.

[1]
https://gerrit.wikimedia.org/r/#/q/mediawiki/core+status:merged+branch:master,n,z

[2]
https://gerrit.wikimedia.org/r/#/q/mediawiki/extensions+status:merged+branch:master,n,z

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: OpenPGP digital signature
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20120521/f328c129/attachment.pgp>


body:
extension[1][2] that already implements this I we can conclude that this is
already the case, and I'll hereby vouch for continued support of such
extensibility for other pre-processors as well. However core should only
(at most) include 1.

-- Krinkle

[1] https://www.mediawiki.org/wiki/Extension:Less
[2] https://github.com/wikimedia/mediawiki-extensions-Less


body:
在 2013-12-15，17:07，Thomas Gries <mail at tgries.de> 写道：

> Am 15.12.2013 09:37, schrieb Sen:
>> hi,i had a confuse,how can i pass a value to the js content script
>>
>> for nowi,i use the way from msupload:
>>    $wgOut->addScript("<script type='text/javascript'>var clipup_vars = $clipup_vars ;</script>\n");
>> it's work but sometimes it seems not work well,the js cant get the value clipup_vars.
>> it's any nature way to doing this?
>
> A short section of the ResourceLoader guide explains this.
>
>  * https://www.mediawiki.org/wiki/ResourceLoader/Migration_guide_for_extension_developers#Configuration_variables
>
> If you used to insert javascript like:
>
> var wgFoo = "bar";
>
> You can now use resource loader to add your variable as a config
> variable. If the variable is the same for all pages and should be on all
> pages, use the ResourceLoaderGetConfigVars
> <https://www.mediawiki.org/wiki/Manual:Hooks/ResourceLoaderGetConfigVars> hook.
> Otherwise if the variable depends on the current page being viewed you
> can either use the MakeGlobalVariablesScript
> <https://www.mediawiki.org/wiki/Manual:Hooks/MakeGlobalVariablesScript>
> hook or if you have an OutputPage object, the addJsConfigVars
> <https://doc.wikimedia.org/mediawiki-core/master/php/html/classOutputPage.html#a81c86f0fc996076ed05467f63b3fb154>
> method. Variables added can be accesed in javascript using
> |mw.config.get( 'variable name' );|
>
> and look to the example in
>
>  * https://www.mediawiki.org/wiki/Manual:Hooks/ResourceLoaderGetConfigVars
>    (If the variable is the same for all pages and should be on all pages)
>  * https://doc.wikimedia.org/mediawiki-core/master/php/html/classOutputPage.html
>    (if the variable depends on the current page)
>
>
> Sometimes in my php I use a construct like
>
>        if  ( $out->getTitle()->equals( SpecialPage::getTitleFor(
> 'OpenIDConvert' ) ) {
>                $out->addHeadItem( 'openid-providerstyle',
> self::providerStyle() );
>        }
>
> to embed code (here: a style) only for certain pages, not for all.
> Perhaps you want this, too.
>
>
>
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l


body:
在 2013-12-15，18:22，Eran Rosenthal <eranroz89 at gmail.com> 写道：

> There is no conventional process for gadget publishing, but you may
> proposed it to English Wikipedia in:
> https://en.wikipedia.org/wiki/Wikipedia:Gadget/proposals
> and it is a community decision whether to adapt it or not (and please read
> first https://en.wikipedia.org/wiki/Wikipedia:Gadget)
> Other such pages exist for various projects/languages, and there are
> different policies.
>
> Another option*, if the target audience isn't Wikimedia projects but any
> MediaWiki installation is
> https://www.mediawiki.org/wiki/Extension:Gadgets/Scripts
> (*Disclaimer: I don't know if anyone actually use this list or review it...)
>
>
>
>
> On Sun, Dec 15, 2013 at 11:42 AM, Sen <kik888 at gmail.com> wrote:
>
>> i make a gadget called hotkeyedit,which i add some hotkey in the
>> wikitextbox,like control+1-6 make the title,ctrl+s switch the lish..ctrl+[
>> add a category,i think if i public it maybe some one others will like
>> it,but i know how to publish extension,but how is gadget.
>>
>>
>> Regrades
>> Sen
>>
>> From SLboat(http://see.sl088.com)
>>
>>
>> _______________________________________________
>> Wikitech-l mailing list
>> Wikitech-l at lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l


body:
-- Krinkle

PS: The public mediawiki-config.git only dates back to 24 Feb 2012. Before that date the information was in a non-public svn repository inside the wmf-production cluster.


body:
- http://arxiv.org/abs/1003.3661 - illustrates the power of the protocol to do time series analysis across versions of linked data description (in DBpedia)
- http://mementoweb.org/depot/native/dbpedia/ - the DBpedia archive that we operate and that is Memento compliant -

Greetings

Herbert

>
> Kind regards,
>
> Remco de Boer
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l


body:
> 在 2013年11月30日，下午1:28，Nathan Larson <nathanlarson3141 at gmail.com> 写道：
>
>> On Fri, Nov 29, 2013 at 11:30 PM, Brian Wolff <bawolff at gmail.com> wrote:
>>
>>> On 11/29/13, Sen <kik888 at gmail.com> wrote:
>>> i know it's depend the mediawiki language,but can i change it by my own?i
>>> use chinese mediawiki,but i wana the mediawiki signature time format use
>>> english.
>>>
>>> sorry again,if this question should not ask in this maillist,plz let me
>>> know i should send which maillist...i very know to the maillist,and my
>>> english is pretty bad too.
>>> _______________________________________________
>>> Wikitech-l mailing list
>>> Wikitech-l at lists.wikimedia.org
>>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>
>> Hi.
>>
>> This question is probably better suited to the mediawiki-l mailing
>> list then this one, but in any case here is the answer:
>>
>>
>> There's two internationalization changes in play here. First of all,
>> month names get translated. This is something that you cannot change
>> without modifying core (as far as I know).
>>
>> Second the date format changes (for example, where in the date the
>> year is put). This one you can control. Just add to the bottom of
>> LocalSettings.php:
>>
>> $wgDefaultUserOptions['date'] = 'mdy';
>>
>> and you will get something like "01:22, 11月 30, 2013 (UTC)" instead of
>> "2013年11月30日 (六) 01:26 (UTC) ". As noted the month names are still
>> shown in Chinese.
>>
>> If you do something like:
>>
>> $wgDefaultUserOptions['date'] = 'ISO 8601';
>>
>> You will get dates that are all numeric like 2013-11-30T01:28:42
>> (UTC). Other options for the date format preference include dmy, ymd.
>> By default it has the value "default" which is equivalent to the value
>> "zh" in the chinese internationalization.
>>
>> --Bawolff
>>
>> _______________________________________________
>> Wikitech-l mailing list
>> Wikitech-l at lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>
>
> To implement what he is asking for, I hacked Parser::pstPass2() in
> includes/parser/Parser.php as follows:
>
> Change:
>     $key = 'timezone-' . strtolower( trim( $tzMsg ) );
> to:
>     $key = 'signature-timezone-' . strtolower( trim( $tzMsg ) );
>
> Change:
>     $d = $wgContLang->timeanddate( $ts, false, false ) . " ($tzMsg)";
> to:
>     $en = Language::factory ( 'en' );
>     $d = $en->timeanddate( $ts, false, false ) . " ($tzMsg)";
>
> Next, write the following PHP script and run it:
>
> <?php
> $abbreviations = array_keys ( DateTimeZone::listAbbreviations() );
> foreach ( $abbreviations as $abbreviation ) {
>        echo "MediaWiki:Signature-timezone-$abbreviation\n";
> }
>
> This will give you the list of MediaWiki: namespace pages you need to
> create, e.g. MediaWiki:Signature-timezone-utc,
> MediaWiki:Signature-timezone-est, etc. There's probably an easier way,
> though.
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l


body:
在 2013年11月30日，下午1:54，Brian Wolff <bawolff at gmail.com> 写道：

>>
>>
>> To implement what he is asking for, I hacked Parser::pstPass2() in
>> includes/parser/Parser.php as follows:
>>
>> Change:
>>     $key = 'timezone-' . strtolower( trim( $tzMsg ) );
>> to:
>>     $key = 'signature-timezone-' . strtolower( trim( $tzMsg ) );
>>
>> Change:
>>     $d = $wgContLang->timeanddate( $ts, false, false ) . " ($tzMsg)";
>> to:
>>     $en = Language::factory ( 'en' );
>>     $d = $en->timeanddate( $ts, false, false ) . " ($tzMsg)";
>>
>> Next, write the following PHP script and run it:
>>
>> <?php
>> $abbreviations = array_keys ( DateTimeZone::listAbbreviations() );
>> foreach ( $abbreviations as $abbreviation ) {
>>        echo "MediaWiki:Signature-timezone-$abbreviation\n";
>> }
>>
>> This will give you the list of MediaWiki: namespace pages you need to
>> create, e.g. MediaWiki:Signature-timezone-utc,
>> MediaWiki:Signature-timezone-est, etc. There's probably an easier way,
>> though.
>> _______________________________________________
>> Wikitech-l mailing list
>> Wikitech-l at lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
> [Standard disclaimer about we do not reccomend making hacks to core
> mediawiki, and such hacks are unsupported, yadda]
>
> The timezone messages generally aren't translated (fun fact: the timezone
> UTC had its name chosen because it makes sense in no language, so no
> language was favoured), so he probably wouldn't need to touch that at all.
> But if that was a concern, the easier way would be to add ->inLanguage (
> 'en' ) to the wfMessage function chain (replacing ->inContentLanguage () ).
>
> -bawolff
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l


body:
在 2013年11月30日，下午2:09，Brian Wolff <bawolff at gmail.com> 写道：

>>
>> There's two internationalization changes in play here. First of all,
>> month names get translated. This is something that you cannot change
>> without modifying core (as far as I know).
>
> Actually what am I talking about. The obvious solution to this is to just
> create the page MediaWiki:January on your wiki (and the other months),
> editing the month names to whatever you want.
>
> MediaWiki will use whatever is on the page MediaWiki:January as the word
> for January, which allows you to modify the output without editing
> mediawiki source code.
>
> -bawolff
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l


body:
> 在 2013年11月30日，下午2:15，Nathan Larson <nathanlarson3141 at gmail.com> 写道：
>
> On Sat, Nov 30, 2013 at 1:09 AM, Brian Wolff <bawolff at gmail.com> wrote:
>
>>>
>>> There's two internationalization changes in play here. First of all,
>>> month names get translated. This is something that you cannot change
>>> without modifying core (as far as I know).
>>>
>>
>> Actually what am I talking about. The obvious solution to this is to just
>> create the page MediaWiki:January on your wiki (and the other months),
>> editing the month names to whatever you want.
>>
>> MediaWiki will use whatever is on the page MediaWiki:January as the word
>> for January, which allows you to modify the output without editing
>> mediawiki source code.
>
>
> I was going to do it that way but he said that he only wanted the signature
> timestamps to be in English and the rest of the site in Chinese, and I was
> concerned that maybe MediaWiki:January might be used for other purposes as
> well.
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l


body:
With the proper legal structures in place, I see no reason why an “Engineer in Residence” program at WMF could not succeed. Having such a program would not only provide an influx of engineering talent (without adding more WMF employees), it might also allow us to positively influence the culture of several corporate entities, which would seem to be a good thing.

Joel

On Aug 10, 2014, at 2:32 PM, C. Scott Ananian <cananian at wikimedia.org> wrote:

> On Sun, Aug 10, 2014 at 9:27 AM, svetlana <svetlana at fastmail.com.au> wrote:
>> I feel that having development carried out by "employees" hinders programming the same software as a hobby: for instance, they work in a single language, and don't need localised documentation
>
> Good localized software is a commitment of the
> project/community/coders, irrespective of coder's employment statuses.
>
> I have certainly worked on software which was localized *only because*
> a company paid people to do the localization.  And, of course, I'm
> sure the converse occurs as well.
>
> As a software engineer who enjoys his work, I'm rather put off by the
> idea that it is somehow wrong for me to make a living using my skills
> to further a cause I believe in.  Are all employees of non-profits
> somehow polluting the non-profit's ideals?
>
> I contributed code to mediawiki as a volunteer before I became an
> employee.  I did not have any problems doing so.  It is true that some
> "community" projects have trouble accepting contributions from
> non-employees, but this is not the case for WMF in my experience.  But
> again, this is due to the values and commitment of the
> community/organization, not who is (or is not) being paid.
>  --scott
>
> --
> (http://cscott.net)
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l


body:
-- Krinkle

[1] Different ideas around an "aside"-accessible table of contents:
* http://underscorejs.org/
* Wikipedia iOS App: http://i.imgur.com/Sg0pqsg.jpg
* User manual: http://asciidoctor.org/docs/user-manual/


body:
   "Hi Mark! Nice to meet you. I see you just wrote this nice new director for consistent URL hashing to backends in Varnish. Let me help you get that upstreamed!"

I believe in that same week he fixed some bugs in our nginx setup and solved our scalability issues with Puppet's external (Nagios) resources, amongst other things.

Ever since, Faidon has taken on many projects, large and small, and completed them in ways going far beyond his duties. He has spent enormous amounts of time reviewing other people's patch sets, discussing their ideas, and mentoring them in their work. He's instrumental in coordinating efforts across multiple groups and making sure everyone arrives at the best possible solution. In discussions he's noticed for being analytical and methodical, and calmly working towards a common goal. This is reflected in his architecting work too, where he contributes with sensible ideas and a great knowledge of the open source software and solutions landscape.

Outside of Wikimedia, Faidon has been active in Debian and other open source projects since 2004. He cares deeply about our use of open source solutions and helping our software extensions get upstreamed and made available to others.

I think it's only appropriate that we recognize his role with this promotion.

The biggest problem we may have with him is that he works too much and is involved with almost everything. Fortunately that is a good fit for his new role. :)

Please join me in congratulating Faidon.

—
Mark Bergsma <mark at wikimedia.org>
Lead Operations Architect
Acting Director of Technical Operations
Wikimedia Foundation


body:
experience is considered acceptable, tested against, and we're committed to
keeping it that way (which may mean moving a browser or mediawiki feature from
one Grade to another). Don't forget that there's a lot more to our platform
than javascript execution!

Supporting users of browsers we provide a javascript-less experience still
requires a lot of things to work; such as:

* Content delivery. (Can't require HTTP features that don't work, e.g. some
sites require every user to be in a session with an ID and for new visitors
they respond with an empty page that sets session cookies based and refreshes
to display the real page, we couldn't do that if we want to support browsers
without cookies or with cookies disabled.)
* Enough styles for the page to be usable. (Let's say background-image were
new in CSS3, then we couldn't exclusively have a design with white text on a
background image without a fallback colour to ensure the text is readable
without that image.)
* HTML implementation. (Say a supported browser doesn't allow relative urls in
a <form> action attribute, we'd have to make it an absolute url.)
* Character encoding. (If certain unicode literals aren't interpreted
properly, we may have to explicitly encode them.)
* We'd commit to doing our best to keep their stuff secure (e.g. while we may
patch against a browser-specific CSRF exploit for an unsupported browser out
of the goodness of our hearts, we pretty much have to if it affects a
supported browser).

All these areas and more do in fact have problems we account for, but I think
we've been at it long enough that we've got these bases covered in MediaWiki
and in our web servers and caching proxies. However as we keep introducing new
backend code and iterate our infrastructure, we need to ensure we don't miss
anything.

-- Timo

On 27 Jul 2014, at 18:42, Jon Robson <jdlrobson at gmail.com> wrote:

> A few quick notes:
>
> * we should be killing jQuery ui. not upgrading it :)
> * progressive enhancement != supporting IE6. We should be doing this
> anywhere. Personally I would be fine with giving IE6,7, even 8 and maybe 9
> no JavaScript whatsoever and supporting them simply from simply a css
> perspective. People can edit and read without JavaScript.
> * I think we should be careful when we say support. Does support meaning
> any new features we write in JavaScript have to work on these platforms or
> does in mean they need to be usable? I'd say the latter. It sounds like the
> discussion is around supporting JS..
> On 24 Jul 2014 13:49, "Sumana Harihareswara" <sumanah at wikimedia.org> wrote:
>
>> Replying with a subject line. :) Good luck Thomas.
>>
>> Sumana Harihareswara
>> Senior Technical Writer
>> Wikimedia Foundation
>>
>>
>> On Thu, Jul 24, 2014 at 4:24 PM, Thomas Mulhall <
>> thomasmulhall410 at yahoo.com>
>> wrote:
>>
>>> Hi should we upgrade jquery ui to version 1.10.4. even though we recently
>>> upgraded to version 1.9.2 we could upgrade to 1.10.4 in Mediawiki 1.25.
>> The
>>> main difference is it removes internet explorer 6 support which as long
>> as
>>> internet explorer 6 users can edit and view the page it wont matter to
>>> them. here is the changelog jqueryui.com/changelog/1.10.0/
>>> _______________________________________________
>>> Wikitech-l mailing list
>>> Wikitech-l at lists.wikimedia.org
>>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>> _______________________________________________
>> Wikitech-l mailing list
>> Wikitech-l at lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l


body:
Zürich, 24 are requesting travel and/or accommodation sponsorship (a few
of them apparently by mistake)

https://www.mediawiki.org/wiki/Z%C3%BCrich_Hackathon_2014/Scholarships

The deadline for scholarship application is March 16th. Our goal is to
notify applicants by March 17th. Don't miss the deadline!

Five organizations are contributing sponsorship funds and, to be honest,
I still don't know exactly how these five entities will match the budget
available with a common list of accepted participants. Still, it is good
to see more Wikimedia organizations stepping in to support independent
developers, and I have no doubt that we will sort out the process in the
next days.

In order to help sharing common standards between organizations and also
between events, I have started a draft with principles and guidelines at

https://www.mediawiki.org/wiki/Volunteer_coordination_and_outreach/Travel_sponsorship

Your help is welcome, regardless of how selfish or altruistic your
motivations are. A good idea is always a good idea, especially when it
comes as an edit to a wiki page.

--
Quim Gil
Technical Contributor Coordinator @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20140304/f71980a1/attachment.pgp>


body:
For standalone front-end projects it actually was this simple. OOjs and VisualEditor have been enjoying this new stack since July 2014. This helped refine the stack and the underlying technologies over the past months. More about what this new stack provides in a minute.

== Journey ==

=== Export from Special:JavaScriptTest ===

For MediaWiki core and extensions, one must install MediaWiki before running QUnit. [2][3] That in itself isn't too complicated (set up DB and run install; we have standard macros for that). But, the test doesn't just communicate with MediaWiki. The test suite is actually served *by* MediaWiki. Karma enforces the principle that unit tests run in pure javascript (blank page with sockets, load source files, load QUnit, run test suite).

Back in MediaWiki 1.19 our test suite abided by these best practices. The test suite was a static HTML file that loaded relevant scripts directly. [4] This file was later migrated to Special:JavaScriptTest, which opened the door for undeclared dependencies.

1. Source code is registered to ResourceLoader.
2. Extensions register tests via hooks in PHP.
3. OutputPage and Skin provide config vars and HTML that tests could depend on.

Point 3 was easily resolved by adding the appropriate mw.config or DOM fixture to the few tests that were missing it.

Though Point 2 and 1 weren't going anywhere. We needed to, once again, access our tests suite as a pure JavaScript payload, with no HTML or script tags loading relevant resources.

Hence, the introduction of Special:JavaScriptTest/qunit/export in https://gerrit.wikimedia.org/r/178551.

=== Migrate all the things ===

Objective: Karma [5] on Chromium. Easy to run locally for developers.

To be re-usable, the logic must be generic and use composer/npm. In 2013, most jobs ran on Wikimedia  production servers. In order to use npm we had to migrate to Wikimedia Labs first.

Back then, production had only just begun using Ubuntu Trusty.

The relevant modules require Node.js v0.10. Ubuntu Precise has Node.js v0.8. Precise is also stuck with Chromium 37 (EOL). [7] To get auto-updating latest stable Chromium and Node v0.10, we needed to migrate our infrastructure to Ubuntu Trusty first.

Much of the process to install MediaWiki on a Jenkins slave also wasn't puppetised.

=== SQLite  ===

This is its own story. See https://phabricator.wikimedia.org/T89180 for details.

The short of it is, we also migrated everything to MySQL. Which we wanted to do anyway.

== New stack ==

1. Chromium

PhantomJS is a great application for many purposes. It was good for us while it lasted. But for JavaScript unit testing, PhantomJS just isn't meant to be. It's too distant from a "real" browser. When we introduced PhantomJS, it was a big step forward toward testing cross-browser. It "uses WebKit" which meant we were kind of covering Chrome and Safari (in 2012).

Safari has had several major releases since PhantomJS v1.9 came out. Chrome had even more releases (and since dropped WebKit in favour of Blink). And, in truth, PhantomJS wasn't that much like Safari and mainstream WebKit to begin with. [8]

Chromium is an actual browser. A browser we actually support. A browser that represents real users of our software. It's only one browser for now, but it's a start.

2. Karma

With Karma as a solid foundation, it's truly simple to add more browsers in the future. OOjs has already added Firefox alongside Chromium in Jenkins. Karma uses Web Driver, a standardised protocol to operate browsers (locally and remotely alike). It has an official plugin hooking it up to SauceLabs, which opens the door to any other browser and platform we want. It's as simple as adding 1 line to the config. [5][6]

We haven't done this yet as there are scalability, performance and security considerations. Having said that, OOjs is currently using an experimental pipeline to test in six different browsers from Jenkins via SauceLabs. Including IE 6 and IE 11 on Windows, and Safari 5 on Mac! [9]

3. Code coverage

One of the advantages of having a pure stack is the ability to run pre-processors on the code using Karma built-ins. [10] The first one I'm looking at is code coverage.

4. Local development and Jenkins equally

It runs the full QUnit test suite in a real browser (multiple even) by simply running "npm test". [11]

Aside from Node.js, it requires no pre-installed software and is as easy as "npm install" to set up.

— Krinkle

[1] https://phabricator.wikimedia.org/T74063 [epic] Adopt Karma with Chromium (tracking).

[2] https://phabricator.wikimedia.org/T89433 Make QUnit tests run without installing MediaWiki.
[3] https://phabricator.wikimedia.org/T89432 Make PHPUnit tests run without installing MediaWiki.
[4] https://github.com/wikimedia/mediawiki/blob/REL1_19/tests/qunit/index.html

[5] https://karma-runner.github.io/
[6] https://karma-runner.github.io/0.12/config/browsers.html

[7] http://packages.ubuntu.com/precise/chromium-browser
[8] http://codepen.io/Krinkle/blog/phantomjs-anno-2014

[9]
https://github.com/wikimedia/oojs/blob/v1.1.6/Gruntfile.js#L76-L107
https://integration.wikimedia.org/ci/job/npm/1680/console

[11]
https://karma-runner.github.io/0.12/config/preprocessors.html
https://github.com/karma-runner/karma-coverage

[12] https://www.mediawiki.org/wiki/Manual:JavaScript_unit_testing


body:
especially for recent versions. Would it be a good idea to change them
all to InnoDB?

Thanks,
Aran


from_name: Larry Sanger

subject: [Wikipedia-l] Wikipedia rocks!

body:
Welcome, o ye five initial members of wikipedia-l, to wikipedia-l!

Actually, the point of this post is to put something in the archives.

On the assumption that all wikipedia articles have the letter "e" in
them, there are now 184 Wikipedia articles.  I added a "best of" page
you might be interested in:

http://www.wikipedia.com/wiki.cgi?BrilliantProse

Wikipedia does rock.  By the count on the "brilliant prose" page, there
are 14 not-bad articles so far, and that's great.

Larry


subject: [Wikipedia-l] Wikipedia--pootified

body:
http://www.pootpoot.com/poot/pootify?URL=http%3A%2F%2Fwww.wikipedia.com&
options=none


from_name: Jason Richey

subject: [Wikipedia-l] test, please disregard

body:
This is only a test, please disregard this message.

--
"Jason C. Richey" <jasonr at bomis.com>


from_name: Bryce Harrington

subject: [Wikipedia-l] A few comments about Wikipedia

body:
On Sat, 27 Jan 2001, Timothy Shell wrote:

>
> I was playing with Wikipedia this evening and became aware of the
> following issues:
>
> 1.  If Wikipedia is to be an encyclopedia, then it probably is not
> appropriate to have threaded discussions on a subject page.  See for
> example AlTruism, where one person gives a flame bait description of the
> concept, and numerous people then argue back about that description.  If a
> discussion is approptiate, perhaps there should be a standard discussion
> page, as AltruismDiscussion or AltruismDebate, that is linked to from the
> subject page.

I disagree; in fact I think it is healthy that there is discussion on
subject pages, and a normal thing that will arise naturally when a
subject is written with inappropriate amounts of bias.  Once the
discussion has achieved concensus (this can take a non-trivial amount of
time), someone will be compelled to go back and summarize up the
discussion.  The resulting subject, IMHO, will be much the stronger for
the discussion, because it will account for multiple viewpoints.

If it helps, imagine a bunch of old professors sitting around a library
table discussing one of the esteemed fella's submissions to the
encyclopedia.  If you've ever heard professors discuss their areas of
passion with one another, you'll know that it can be anything but
gentlemanly at times.  ;-)

Anyway, I believe it will be self-correcting.  This is part of the
reason wiki's work so well.  I don't think any rules need to be made.
If you think too much discussion has gone on, perhaps consider appending
a note exhorting the participants to wrap it up and summarize?  Or if
you feel ambitious go ahead and summarize it for them.

> 2.  Often the wiki links for noun and adjective forms of a word should
> point to the same subject page.  For example, SkI and SkiinG are
> essentially overlapping concepts.  We could say, on the SkI page, "To
> engage in SkiinG".  This is not elegant, but it works, I suppose.  I see
> on the WhichWikiShouldWeUse page that there are different versions of wiki
> that might allow for different ways of linking.  Do one of these
> alternative ways offer a solution to this problem, allowing for different
> links to point to the same subject page?

I've had similar concerns wrt ist and ism.  E.g., Communist and
Communism.  I don't have a good solution for within this particular
wiki.

And yes, other wiki's have capabilities that help here, but there's
usually a trade-off in the form of having to construct the links a tad
more deliberately than you'd like...  I would wager there is in fact
some way to kludge around it in this one...

Bryce


from_name: Timothy Shell

body:
I was playing with Wikipedia this evening and became aware of the
following issues:

1.  If Wikipedia is to be an encyclopedia, then it probably is not
appropriate to have threaded discussions on a subject page.  See for
example AlTruism, where one person gives a flame bait description of the
concept, and numerous people then argue back about that description.  If a
discussion is approptiate, perhaps there should be a standard discussion
page, as AltruismDiscussion or AltruismDebate, that is linked to from the
subject page.

2.  Often the wiki links for noun and adjective forms of a word should
point to the same subject page.  For example, SkI and SkiinG are
essentially overlapping concepts.  We could say, on the SkI page, "To
engage in SkiinG".  This is not elegant, but it works, I suppose.  I see
on the WhichWikiShouldWeUse page that there are different versions of wiki
that might allow for different ways of linking.  Do one of these
alternative ways offer a solution to this problem, allowing for different
links to point to the same subject page?

Tim


body:
From: "Jimmy Wales" <jwales at aristotle.bomis.com>
> Timothy Shell wrote:
> > 1.  If Wikipedia is to be an encyclopedia, then it probably is not
> > appropriate to have threaded discussions on a subject page.  See for
> > example AlTruism, where one person gives a flame bait description of
the
> > concept, and numerous people then argue back about that description.
If a
> > discussion is approptiate, perhaps there should be a standard
discussion
> > page, as AltruismDiscussion or AltruismDebate, that is linked to
from the
> > subject page.
>
> There is already a cultural tradition in the wiki world called
> "refactoring".  The idea is that there is a "discussion mode" and
> a "document mode".  In discussion mode, people have a threaded
discussion,
> with many different issues being raised.
>
> Then, some WikiMaster comes through after the discussion has died
> down, and "refactors" the page.  This involves editing/rewriting/
> rearranging, so that all points of view are presented fairly.

Well, I'm not sure that the history of wiki is relevant here, because we
are, after all, making an attempt at creating an encyclopedia, and
therefore we're making some attempt at being unbiased in our entries.
This is especially crucial in that this is a collaborative endeavor.
How can a collaborative endeavor *not* have a nonbias policy?

To respect this policy, I think people should feel free to edit main
articles, such as the controversial GeorgeWBush article, but also add to
corresponding discussion pages--linked from the bottom of the page.
That's what I did for GeorgeWBush; I made BushTalk and moved the
discussion there.  As issues get resolved, or positions harden, in
BushTalk, the controversy can be described (not engaged, but described)
on GeorgeWBush.

So I agree with Tim, as you can see.

Larry


from_name: Jimmy Wales

in_reply_to: <Pine.BSF.4.21.0101270200100.3052-100000@aristotle.bomis.com>; from tshell@aristotle.bomis.com on Sat, Jan 27, 2001 at 02:09:50AM -0600

body:
Timothy Shell wrote:
> 1.  If Wikipedia is to be an encyclopedia, then it probably is not
> appropriate to have threaded discussions on a subject page.  See for
> example AlTruism, where one person gives a flame bait description of the
> concept, and numerous people then argue back about that description.  If a
> discussion is approptiate, perhaps there should be a standard discussion
> page, as AltruismDiscussion or AltruismDebate, that is linked to from the
> subject page.

There is already a cultural tradition in the wiki world called
"refactoring".  The idea is that there is a "discussion mode" and
a "document mode".  In discussion mode, people have a threaded discussion,
with many different issues being raised.

Then, some WikiMaster comes through after the discussion has died
down, and "refactors" the page.  This involves editing/rewriting/
rearranging, so that all points of view are presented fairly.

> 2.  Often the wiki links for noun and adjective forms of a word should
> point to the same subject page.  For example, SkI and SkiinG are
> essentially overlapping concepts.  We could say, on the SkI page, "To
> engage in SkiinG".  This is not elegant, but it works, I suppose.  I see
> on the WhichWikiShouldWeUse page that there are different versions of wiki
> that might allow for different ways of linking.  Do one of these
> alternative ways offer a solution to this problem, allowing for different
> links to point to the same subject page?

I don't think there is any automated solution to this and similar
problems.

--
*************************************************
*            http://www.nupedia.com/            *
*      The Ever Expanding Free Encyclopedia     *
*************************************************


subject: [Wikipedia-l] Hello, "FreeLinks" work, and redirected pages.

body:
Hi Cliff,

Wow!  Thanks for doing all this for us.  The changes you're making are
very groovy.

This will handily remove name ambiguities due to differing placements of
the second capital letter.  We'll still have to deal with the problem of
different names for closely-related concepts (e.g., "communism" and
"communist"), but the redirection feature seems to take care of that
pretty well...

A great feature would be something that would instantaneously,
automatically, rename both a page and all the links to it.

Larry


from_name: Clifford Adams

body:
    Hello to all of my fellow WikiPedia fanatics! :-)

    I'm the author of the UseModWiki software currently running the WikiPedia.
While I was skeptical at first, I think the wiki approach could work very well
for a collaborative encyclopedia.  I've decided to focus most of my near-term
efforts on new features and supporting tools for WikiPedia (most of which will
also help the other UseModWiki sites).

    If any of the readers of this list have any questions about the wiki
software, I'd be glad to try to answer them.  My "permanent" email address is
caadams at usemod.com, but this frontiernet.net address should work for awhile
(I'm not planning on moving).

-----

    I've done a lot of thinking about WikiLinking recently, and I'm not sure
that the WikiName (capital letters) convention is a good fit for the
encyclopedia.  The AccidentalLinking is a nice feature, but it has a price in
harder-to-read links and confusing conventions.

    For instance, when I recently wanted to link to "democracy", I first did a
search to see if someone else had linked the name (I thought someone might
have already used "DemoCracy").  I found that nobody else had linked that
name, so I made the link "DemocracY" (to follow the new convention of
last-letter-capitalized).  In short, it took me far more time to make that
link than it would have to just type [[democracy]].  Someone unfamiliar with
the local wiki conventions might guess otherwise on another page and link to a
separate "DemoCracy" or even "DeMocracy".  Ick.

    To make a longish story short, I added code (about 150 new lines of Perl)
to my development copy to allow (site-optional) "Free" linking within [[double
brackets]].  You can use spaces, numbers, commas, dashes, and the period
character in these kinds of links.  Valid link names include [[George W.
Bush]], [[China-Soviet Relations]], [[Physics]], [[music]], and [[Year 2000
bug]].  User names can also use these new links.  Internally and within URLs
the spaces are replaced with _ (underline) characters, which are translated
back to spaces for display purposes.

    Visit http://www.usemod.com/cgi-bin/um9.pl?FreeLinks to see these links in
a live wiki, and feel free to edit pages to try it out. (Note that this is a
test/development wiki, and is sometimes unavailable when I'm developing.  I
will soon (a few days at most) make a more stable version available to the
public.)

    Tomorrow I will start working on a semi-automatic conversion tool which
should allow the entire WikiPedia to be converted in a couple hours.

----

> > [SkI vs. SkIing, etc.]  Do one of these
> > alternative ways offer a solution to this problem, allowing for different
> > links to point to the same subject page?
>
> I've had similar concerns wrt ist and ism.  E.g., Communist and
> Communism.  I don't have a good solution for within this particular
> wiki.
>
> And yes, other wiki's have capabilities that help here, but there's
> usually a trade-off in the form of having to construct the links a tad
> more deliberately than you'd like...  I would wager there is in fact
> some way to kludge around it in this one...

    That would be a good wager--there is already a "redirect" feature made for
this circumstance.  To use the page-redirect feature, simply type

#REDIRECT NewPageName

...at the beginning of the page you want to redirect. (The command must start
at the first character of the first line of the page. REDIRECT must be in FULL
CAPS.)   For example, to make "CommunIst" redirect to "CommunIsm", you would
edit the CommunIst page and add:

#REDIRECT CommunIsm

to the top of the page.  You can see this feature in action at
http://www.usemod.com/cgi-bin/um9.pl?CommunIst  (you will be redirected to the
CommunIsm page).

    You can use this feature right now on the current WikiPedia site.  Yes,
I'm aware of the SubOptimal state of the current wiki DocumentatioN.  :-)

            --Cliff


body:
On Sat, 27 Jan 2001, Clifford Adams wrote:

>     Hello to all of my fellow WikiPedia fanatics! :-)
>
>     I'm the author of the UseModWiki software currently running the WikiPedia.
> While I was skeptical at first, I think the wiki approach could work very well
> for a collaborative encyclopedia.  I've decided to focus most of my near-term
> efforts on new features and supporting tools for WikiPedia (most of which will
> also help the other UseModWiki sites).
>
>     If any of the readers of this list have any questions about the wiki
> software, I'd be glad to try to answer them.  My "permanent" email address is
> caadams at usemod.com, but this frontiernet.net address should work for awhile
> (I'm not planning on moving).

Well, since we've got the ear of a this wiki's maintainer, I'll withdraw
my suggestion to change to TWiki.  Instead, I'll describe some things I
liked about other wiki's I've used...

* In other wiki's, I've seen *bold* and _italic_ done that way, rather
than using multiple single-quotes.  I dare say I prefer it that way, but
it appears that this and this seem to work, so that's ok.

* We definitely need some way to distinguish headers.  I've been making
them bold, but that's not really enough to distinguish between different
levels of headers.

* We really need an upload functionality, so that we can easily submit
images for the site.  So far, I've just been including src links
pointing to places on another server.

* We may wish to consider allowing having multiple "zones" for wiki
material.  I.e., separate the wiki-related material from the
encyclopedia-related material.  It might also make sense to set up
special areas focused to a particular topic that is going to have a LOT
of entries.  For instance, under PopMusic, it appears we're going to
have entries for all the pop musicians, which suggests having a
sub-encyclopedia just for music artists might be warranted.  I'm unsure
on this one though, so take it as a loose suggestion.

* If I have a document that is in HTML already, is there a simpler way
to put it into the site, than to have to manually strip out the HTML and
put the wiki tags in it?  For instance, the topic on the Photo Electric
effect had so much HTML in it that I didn't know where to start to clean
it up; it looks like a mess right now...

* Another note is that the Photo Electric effect article is in German.
How do we feel about multilingualism?  What is the policy - to accept
alternate languages / translations, or to only accept english articles?
I know this opens a can of worms, but...

Btw, with all of these suggestions, I wouldn't be surprised if they
already exist - if so, then change the suggestions into "would be nice
to add mention-of to the website".


subject: [Wikipedia-l] Requested articles

body:
http://www.wikipedia.com/wiki.cgi?RequestedArticles

--a way to get other people to write about stuff we want to know about?
I guess we'll see!

Larry


subject: [Wikipedia-l] What's this list for?

body:
I supported the creation of this list, but it occurs to me
that quite possibly discussions which take place here ought
to be taking place on wikipedia itself.

It's just a thought.  :-)

--
*************************************************
*            http://www.nupedia.com/            *
*      The Ever Expanding Free Encyclopedia     *
*************************************************


from_name: rose.parks at att.net

subject: [Wikipedia-l] What's this list for? (fwd)

body:
--

----------------------  Forwarded Message:  ---------------------
From:    rose.parks at att.net
To:      Jimmy Wales <jwales at aristotle.bomis.com>
Subject: Re: [Wikipedia-l] What's this list for?
Date:    Sun, 28 Jan 2001 23:49:43 +0000

Dear Jimmy and Wikipedians,

     I am not sure how many people working Wikipedia are
list members. I think you should leave it and see what
happens for the time being.

     Jusy my opinion...:-).

         As Ever,

           Ruth Ifcher

--

> I supported the creation of this list, but it occurs to me
> that quite possibly discussions which take place here ought
> to be taking place on wikipedia itself.
>
> It's just a thought.  :-)
>
> --
> *************************************************
> *            http://www.nupedia.com/            *
> *      The Ever Expanding Free Encyclopedia     *
> *************************************************
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l


subject: [Wikipedia-l] wikipedia traffic

body:
I count 224 unique IPs and 4871 hits to wiki.cgi in today's access log
(after 23 hours).

Anyone's guess how many unique humans 224 IP addresses implies.

I was going to suggest we embed each page with a sophisticated counter
system so we could track hits to various parts of the wikipedia, but I
guess it would be simple enough just to do analysis on the access logs.

Tim


subject: [Wikipedia-l] [Info-gnupedia]New Article (fwd)

body:
The article mentioned below is covered by the GNU FDL and so could be
put on wikipedia, I believe.

Bryce

---------- Forwarded message ----------
Date: Tue, 30 Jan 2001 21:31:58 +0100
From: Sonic <sonic at arcormail.de>
To: info-gnupedia at gnu.org
Subject: [Info-gnupedia]New Article

Hi!

Some years ago, I wrote a research paper about Ernest Hemingway, and I
thought maybe I could contribute it to Gnupedia. It is pretty long
(about 20 printed pages), and still needs some work, but I'm not sure
what and how much I should leave out. If you want to, you can have a
look at it at http://people.freenet.de/sonics_homepage/hemtext.html and
send me your comments afterwards (sonic at arcormail.de)

Bye,

Sonic


subject: [Wikipedia-l] Inquiry

body:
I notice that Bryce wikified two articles by Oleg Izyumenko,
and that Bryce later removed them, at Oleg's request.

What's that all about?  I hope he wasn't angry.

On a side note, I am really enjoying the discussion under
the UnitedStatesHistory thread.  I'll post some remarks there
later.  :-)

--
*************************************************
*            http://www.nupedia.com/            *
*      The Ever Expanding Free Encyclopedia     *
*************************************************


subject: [Wikipedia-l] Inquiry

body:
On Tue, 30 Jan 2001, Jimmy Wales wrote:

> I notice that Bryce wikified two articles by Oleg Izyumenko,
> and that Bryce later removed them, at Oleg's request.
>
> What's that all about?  I hope he wasn't angry.

He (Oleg) was *extremely* angry.  I feel pretty bad about it.

I've deleted his email but his points were essentially that he had
submitted the article to GNUPedia ONLY and demanded it be removed
immediately.  I asked if he hadn't intended his article to be released
under the GNU Free Documentation License, and mentioned that GnuPedia
had been renamed GNE.

He replied rather vehemently that I had *ruined* his article, that yes
he did intend for it to be licensed to GNUPedia, but "GNU" did not mean
"Free", and that I was clearly lying about GnuPedia changing to GNE
since it still said GnuPedia on the gnu.org website.

Yeah, I know what you're thinking, but I didn't see a point to arguing
(I usually don't) so just got rid of it.  Twern't my wish to exacerbate
the already tenuous relationship between these projects, and my
apologies if it causes longer term issues.

He also publically castigated someone who voluntarily created a
translation of the page today, because they hadn't asked first.

> On a side note, I am really enjoying the discussion under
> the UnitedStatesHistory thread.  I'll post some remarks there
> later.  :-)

Erk, not me.  :-\

Bryce


subject: [Wikipedia-l] Inquiry

body:
Other articles have been appearing on info-gnupedia, some of which are
being specifically released under the GNU FDL, which I believe makes
them candidates for inclusion in wikipedia.  I've unsubscribed from that
list and am not going to attempt to copy any further articles over, but
someone else might want to consider doing this.

Bryce

On Tue, 30 Jan 2001, Jimmy Wales wrote:

> Geez, well, I was afraid of that.  You didn't do any harm,
> and I agree totally with the decision to remove it.  I certainly
> don't want there to be any fights between the two groups, at least
> not if we can avoid it!


subject: [Wikipedia-l] Inquiry

body:
Geez, well, I was afraid of that.  You didn't do any harm,
and I agree totally with the decision to remove it.  I certainly
don't want there to be any fights between the two groups, at least
not if we can avoid it!

Bryce Harrington wrote:

> On Tue, 30 Jan 2001, Jimmy Wales wrote:
>
> > I notice that Bryce wikified two articles by Oleg Izyumenko,
> > and that Bryce later removed them, at Oleg's request.
> >
> > What's that all about?  I hope he wasn't angry.
>
> He (Oleg) was *extremely* angry.  I feel pretty bad about it.
>
> I've deleted his email but his points were essentially that he had
> submitted the article to GNUPedia ONLY and demanded it be removed
> immediately.  I asked if he hadn't intended his article to be released
> under the GNU Free Documentation License, and mentioned that GnuPedia
> had been renamed GNE.
>
> He replied rather vehemently that I had *ruined* his article, that yes
> he did intend for it to be licensed to GNUPedia, but "GNU" did not mean
> "Free", and that I was clearly lying about GnuPedia changing to GNE
> since it still said GnuPedia on the gnu.org website.
>
> Yeah, I know what you're thinking, but I didn't see a point to arguing
> (I usually don't) so just got rid of it.  Twern't my wish to exacerbate
> the already tenuous relationship between these projects, and my
> apologies if it causes longer term issues.
>
> He also publically castigated someone who voluntarily created a
> translation of the page today, because they hadn't asked first.
>
> > On a side note, I am really enjoying the discussion under
> > the UnitedStatesHistory thread.  I'll post some remarks there
> > later.  :-)
>
> Erk, not me.  :-\
>
> Bryce
>
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l

--
*************************************************
*            http://www.nupedia.com/            *
*      The Ever Expanding Free Encyclopedia     *
*************************************************


subject: [Wikipedia-l] Publicizing wikipedia

body:
How can we publicize Wikipedia unobnoxiously?

Larry


subject: [Wikipedia-l] Copyright problem

body:
Someone had posted a copyrighted article into the 'wolf' category.
I deleted it, please see the discussion at 'WolF'.

For now, I just deleted it by removing all the text, but of course
the copyrighted material is still on our server in the revision history.
That will go away after 14 days, as I understand it, but I will also
try to figure out how to make it go away sooner.

I'm not too worried about this for the future.  Legally, it isn't likely
to be a huge problem.  We just need to instill a very strong social norm
on the wikipedia that copyright violations will not be tolerated.

--
*************************************************
*            http://www.nupedia.com/            *
*      The Ever Expanding Free Encyclopedia     *
*************************************************