Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Wikipedia: Wikitech

HTMLMultiSelectField as <select multiple="multiple"/>

 

 

Wikipedia wikitech RSS feed   Index | Next | Previous | View Threaded


daniel.werner at wikimedia

May 23, 2012, 10:16 AM

Post #1 of 13 (677 views)
Permalink
HTMLMultiSelectField as <select multiple="multiple"/>

Right now I am implementing a new option (as part of
https://bugzilla.wikimedia.org/show_bug.cgi?id=36425) for which I'd like to
use a <select multiple="multiple"/> html element with options. Right now
MediaWiki always generates a list of selectboxes instead of that when using
the HTMLMultiSelectField class. We are talking about 280+ selectable items
here, so for now we came to the conclusion that a real multi <select/>
would be nicer and less space consuming for now
I have already managed to implement this multiple select,
modifying HTMLMultiSelectField adding a new option 'usecheckboxes' which
can be set to false to disable the known behavior and use a select element
instead.

This would mainly be for the JavaScript-less ui. If javascript were
enabled, we could still do something nicer, for example with something like
jQuery chosen plugin here.

My question would just be, how I should implement these changes preferably.
Is it ok with the new option for HTMLMultiSelectField or should this be a
new class inheriting from HTMLMultiSelectField? I think
HTMLMultiSelectField sounds more like describing what I just implemented
rather than a bunch of select boxes, but of course renaming the existing
one could "break" extensions (even though both are fully compatible and
interchangeable). So one option would be simply naming the new one
HTMLMultiSelectField2 if we don't want to stick with an additional option
here.

Cheers
Daniel

--
Daniel Werner
Software Engineer

Wikimedia Deutschland e.V. | NEU: Obentrautstr. 72 | 10963 Berlin
Tel. (030) 219 158 26-0

http://wikimedia.de

Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/681/51985.
_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


happy.melon.wiki at gmail

May 23, 2012, 11:26 AM

Post #2 of 13 (623 views)
Permalink
Re: HTMLMultiSelectField as <select multiple="multiple"/> [In reply to]

On 23 May 2012 18:16, Daniel Werner <daniel.werner [at] wikimedia> wrote:

> Right now I am implementing a new option (as part of
> https://bugzilla.wikimedia.org/show_bug.cgi?id=36425) for which I'd like
> to
> use a <select multiple="multiple"/> html element with options. Right now
> MediaWiki always generates a list of selectboxes instead of that when using
> the HTMLMultiSelectField class. We are talking about 280+ selectable items
> here, so for now we came to the conclusion that a real multi <select/>
> would be nicer and less space consuming for now
> I have already managed to implement this multiple select,
> modifying HTMLMultiSelectField adding a new option 'usecheckboxes' which
> can be set to false to disable the known behavior and use a select element
> instead.
>
> This would mainly be for the JavaScript-less ui. If javascript were
> enabled, we could still do something nicer, for example with something like
> jQuery chosen plugin here.
>
> My question would just be, how I should implement these changes preferably.
> Is it ok with the new option for HTMLMultiSelectField or should this be a
> new class inheriting from HTMLMultiSelectField? I think
> HTMLMultiSelectField sounds more like describing what I just implemented
> rather than a bunch of select boxes, but of course renaming the existing
> one could "break" extensions (even though both are fully compatible and
> interchangeable). So one option would be simply naming the new one
> HTMLMultiSelectField2 if we don't want to stick with an additional option
> here.
>
> Cheers
> Daniel
>
>
There's some relevant comments and discussion in our draft style guide [1]
that might be interesting/relevant.

--HM

[1] https://www.mediawiki.org/wiki/Style_guide/Forms
_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


Platonides at gmail

May 23, 2012, 12:49 PM

Post #3 of 13 (621 views)
Permalink
Re: HTMLMultiSelectField as <select multiple="multiple"/> [In reply to]

On 23/05/12 19:16, Daniel Werner wrote:
> Right now I am implementing a new option (as part of
> https://bugzilla.wikimedia.org/show_bug.cgi?id=36425) for which I'd like to
> use a <select multiple="multiple"/> html element with options. Right now
> MediaWiki always generates a list of selectboxes instead of that when using
> the HTMLMultiSelectField class. We are talking about 280+ selectable items
> here, so for now we came to the conclusion that a real multi <select/>
> would be nicer and less space consuming for now
> I have already managed to implement this multiple select,
> modifying HTMLMultiSelectField adding a new option 'usecheckboxes' which
> can be set to false to disable the known behavior and use a select element
> instead.
>
> This would mainly be for the JavaScript-less ui. If javascript were
> enabled, we could still do something nicer, for example with something like
> jQuery chosen plugin here.
>
> My question would just be, how I should implement these changes preferably.
> Is it ok with the new option for HTMLMultiSelectField or should this be a
> new class inheriting from HTMLMultiSelectField? I think
> HTMLMultiSelectField sounds more like describing what I just implemented
> rather than a bunch of select boxes, but of course renaming the existing
> one could "break" extensions (even though both are fully compatible and
> interchangeable). So one option would be simply naming the new one
> HTMLMultiSelectField2 if we don't want to stick with an additional option
> here.

No. You shouldn't need to know that HTMLMultiSelectField2 is a
MultiSelect but HTMLMultiSelectField uses checkboxes.
Your useCheckboxes looks good.
I recommend you to make it a tri-state value, so you could force
checkboxes, select or let it decide (eg. checkboxes for < 100 elements,
select for more)



_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


agarrett at wikimedia

May 23, 2012, 6:44 PM

Post #4 of 13 (615 views)
Permalink
Re: HTMLMultiSelectField as <select multiple="multiple"/> [In reply to]

On Thu, May 24, 2012 at 3:16 AM, Daniel Werner
<daniel.werner [at] wikimedia>wrote:

> Right now I am implementing a new option (as part of
> https://bugzilla.wikimedia.org/show_bug.cgi?id=36425) for which I'd like
> to
> use a <select multiple="multiple"/> html element with options. Right now
> MediaWiki always generates a list of selectboxes instead of that when using
> the HTMLMultiSelectField class. We are talking about 280+ selectable items
> here, so for now we came to the conclusion that a real multi <select/>
> would be nicer and less space consuming for now
> I have already managed to implement this multiple select,
> modifying HTMLMultiSelectField adding a new option 'usecheckboxes' which
> can be set to false to disable the known behavior and use a select element
> instead.
>
> This would mainly be for the JavaScript-less ui. If javascript were
> enabled, we could still do something nicer, for example with something like
> jQuery chosen plugin here.
>
> My question would just be, how I should implement these changes preferably.
> Is it ok with the new option for HTMLMultiSelectField or should this be a
> new class inheriting from HTMLMultiSelectField? I think
> HTMLMultiSelectField sounds more like describing what I just implemented
> rather than a bunch of select boxes, but of course renaming the existing
> one could "break" extensions (even though both are fully compatible and
> interchangeable). So one option would be simply naming the new one
> HTMLMultiSelectField2 if we don't want to stick with an additional option
> here.
>

Thanks for working on this! It'll be really handy.

I'd definitely recommend using a parameter.

—Andrew
--
Andrew Garrett
Wikimedia Foundation
agarrett [at] wikimedia
_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


daniel.werner at wikimedia

May 25, 2012, 9:11 AM

Post #5 of 13 (612 views)
Permalink
Re: HTMLMultiSelectField as <select multiple="multiple"/> [In reply to]

> Message: 8
> Date: Wed, 23 May 2012 21:49:57 +0200
> From: Platonides <Platonides [at] gmail>
> To: wikitech-l [at] lists
> Subject: Re: [Wikitech-l] HTMLMultiSelectField as <select
> multiple="multiple"/>
> Message-ID: <jpjf1s$b23$1 [at] dough>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On 23/05/12 19:16, Daniel Werner wrote:
> > Right now I am implementing a new option (as part of
> > https://bugzilla.wikimedia.org/show_bug.cgi?id=36425) for which I'd
like to
> > use a <select multiple="multiple"/> html element with options. Right now
> > MediaWiki always generates a list of selectboxes instead of that when
using
> > the HTMLMultiSelectField class. We are talking about 280+ selectable
items
> > here, so for now we came to the conclusion that a real multi <select/>
> > would be nicer and less space consuming for now
> > I have already managed to implement this multiple select,
> > modifying HTMLMultiSelectField adding a new option 'usecheckboxes' which
> > can be set to false to disable the known behavior and use a select
element
> > instead.
> >
> > This would mainly be for the JavaScript-less ui. If javascript were
> > enabled, we could still do something nicer, for example with something
like
> > jQuery chosen plugin here.
> >
> > My question would just be, how I should implement these changes
preferably.
> > Is it ok with the new option for HTMLMultiSelectField or should this be
a
> > new class inheriting from HTMLMultiSelectField? I think
> > HTMLMultiSelectField sounds more like describing what I just implemented
> > rather than a bunch of select boxes, but of course renaming the existing
> > one could "break" extensions (even though both are fully compatible and
> > interchangeable). So one option would be simply naming the new one
> > HTMLMultiSelectField2 if we don't want to stick with an additional
option
> > here.
>
> No. You shouldn't need to know that HTMLMultiSelectField2 is a
> MultiSelect but HTMLMultiSelectField uses checkboxes.
> Your useCheckboxes looks good.
> I recommend you to make it a tri-state value, so you could force
> checkboxes, select or let it decide (eg. checkboxes for < 100 elements,
> select for more)

Alright, just submitted this for review to gerrit:
https://gerrit.wikimedia.org/r/#/c/8924/

I implemented it as tri-state now. By default 'usecheckboxes' will be true,
not set to a number. This could be changed (would make sense imo) but for
now I didn't want to do this since it could for example affect the default
search namespace user preference in wikis with many search namespaces. I
think the plain multiple select HTML element is not that nice because it is
not very obvious that you can do multiple selects by holding the control
key. There should be some JavaScript ui element replacing this for users
having JS enabled I think before using this as default for huge multiselect
options. I think if all of that were implemented, 15 or 20 would be a good
default value for the option.

Cheers
Daniel
_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


daniel at nadir-seen-fire

Sep 28, 2012, 7:51 PM

Post #6 of 13 (547 views)
Permalink
Re: HTMLMultiSelectField as <select multiple="multiple"/> [In reply to]

On Fri, 25 May 2012 09:11:20 -0700, Daniel Werner
<daniel.werner [at] wikimedia> wrote:

>> Message: 8
>> Date: Wed, 23 May 2012 21:49:57 +0200
>> From: Platonides <Platonides [at] gmail>
>> To: wikitech-l [at] lists
>> Subject: Re: [Wikitech-l] HTMLMultiSelectField as <select
>> multiple="multiple"/>
>> Message-ID: <jpjf1s$b23$1 [at] dough>
>> Content-Type: text/plain; charset=ISO-8859-1
>>
>> On 23/05/12 19:16, Daniel Werner wrote:
>> > Right now I am implementing a new option (as part of
>> > https://bugzilla.wikimedia.org/show_bug.cgi?id=36425) for which I'd
> like to
>> > use a <select multiple="multiple"/> html element with options. Right
>> now
>> > MediaWiki always generates a list of selectboxes instead of that when
> using
>> > the HTMLMultiSelectField class. We are talking about 280+ selectable
> items
>> > here, so for now we came to the conclusion that a real multi <select/>
>> > would be nicer and less space consuming for now
>> > I have already managed to implement this multiple select,
>> > modifying HTMLMultiSelectField adding a new option 'usecheckboxes'
>> which
>> > can be set to false to disable the known behavior and use a select
> element
>> > instead.
>> >
>> > This would mainly be for the JavaScript-less ui. If javascript were
>> > enabled, we could still do something nicer, for example with something
> like
>> > jQuery chosen plugin here.
>> >
>> > My question would just be, how I should implement these changes
> preferably.
>> > Is it ok with the new option for HTMLMultiSelectField or should this
>> be
> a
>> > new class inheriting from HTMLMultiSelectField? I think
>> > HTMLMultiSelectField sounds more like describing what I just
>> implemented
>> > rather than a bunch of select boxes, but of course renaming the
>> existing
>> > one could "break" extensions (even though both are fully compatible
>> and
>> > interchangeable). So one option would be simply naming the new one
>> > HTMLMultiSelectField2 if we don't want to stick with an additional
> option
>> > here.
>>
>> No. You shouldn't need to know that HTMLMultiSelectField2 is a
>> MultiSelect but HTMLMultiSelectField uses checkboxes.
>> Your useCheckboxes looks good.
>> I recommend you to make it a tri-state value, so you could force
>> checkboxes, select or let it decide (eg. checkboxes for < 100 elements,
>> select for more)
>
> Alright, just submitted this for review to gerrit:
> https://gerrit.wikimedia.org/r/#/c/8924/
>
> I implemented it as tri-state now. By default 'usecheckboxes' will be
> true,
> not set to a number. This could be changed (would make sense imo) but for
> now I didn't want to do this since it could for example affect the
> default
> search namespace user preference in wikis with many search namespaces. I
> think the plain multiple select HTML element is not that nice because it
> is
> not very obvious that you can do multiple selects by holding the control
> key. There should be some JavaScript ui element replacing this for users
> having JS enabled I think before using this as default for huge
> multiselect
> options. I think if all of that were implemented, 15 or 20 would be a
> good
> default value for the option.
>
> Cheers
> Daniel

Yes, multiselect is a VERY bad usability choice. Frankly we shouldn't use
it anywhere. If we're using JS to make a better UI it would actually be
much better to output usable checkboxes and then turn the checkboxes into
a special JS multi-select. Instead of outputting an unusable multi-select
and compensating for it.

--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]


_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


krinklemail at gmail

Sep 28, 2012, 10:38 PM

Post #7 of 13 (546 views)
Permalink
Re: HTMLMultiSelectField as <select multiple="multiple"/> [In reply to]

On Sep 29, 2012, at 4:51 AM, Daniel Friesen <daniel [at] nadir-seen-fire> wrote:

> On Fri, 25 May 2012 09:11:20 -0700, Daniel Werner <daniel.werner [at] wikimedia> wrote:
>
>>
>> Alright, just submitted this for review to gerrit:
>> https://gerrit.wikimedia.org/r/#/c/8924/
>>
>> [..]
>
> Yes, multiselect is a VERY bad usability choice. Frankly we shouldn't use it anywhere. If we're using JS to make a better UI it would actually be much better to output usable checkboxes and then turn the checkboxes into a special JS multi-select. Instead of outputting an unusable multi-select and compensating for it.
>

+1 :-)

-- Krinkle


_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


katkov.juriy at gmail

Sep 29, 2012, 2:11 AM

Post #8 of 13 (551 views)
Permalink
Re: HTMLMultiSelectField as <select multiple="multiple"/> [In reply to]

Hi guys!

In Semantic Form Inputs extension we use the multiselect that is
stylized and more usable. Here is the library:
http://loudev.com/

Some other options are:
http://harvesthq.github.com/chosen/ (will be included in the next
Semantic Form Inputs)
http://www.erichynds.com/jquery/jquery-ui-multiselect-widget/

-----
Yury Katkov



On Sat, Sep 29, 2012 at 9:38 AM, Krinkle <krinklemail [at] gmail> wrote:
> On Sep 29, 2012, at 4:51 AM, Daniel Friesen <daniel [at] nadir-seen-fire> wrote:
>
>> On Fri, 25 May 2012 09:11:20 -0700, Daniel Werner <daniel.werner [at] wikimedia> wrote:
>>
>>>
>>> Alright, just submitted this for review to gerrit:
>>> https://gerrit.wikimedia.org/r/#/c/8924/
>>>
>>> [..]
>>
>> Yes, multiselect is a VERY bad usability choice. Frankly we shouldn't use it anywhere. If we're using JS to make a better UI it would actually be much better to output usable checkboxes and then turn the checkboxes into a special JS multi-select. Instead of outputting an unusable multi-select and compensating for it.
>>
>
> +1 :-)
>
> -- Krinkle
>
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l [at] lists
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


daniel.werner at wikimedia

Sep 30, 2012, 1:41 PM

Post #9 of 13 (549 views)
Permalink
Re: HTMLMultiSelectField as <select multiple="multiple"/> [In reply to]

On Sep 29, 2012, at 4:51 AM, Daniel Friesen <daniel [at] nadir-seen-fire>
wrote:
> Yes, multiselect is a VERY bad usability choice. Frankly we shouldn't use
it anywhere. If we're using JS to make
> a better UI it would actually be much better to output usable checkboxes
and then turn the checkboxes into a
> special JS multi-select. Instead of outputting an unusable multi-select
and compensating for it.

>
Sure, as long as there is JS available we should turn the multi-select into
something nicer. But the original idea behind this was that a multi select
would still be more user friendly than an endless list of check-boxes when
having around 300 choices (e.g. for languages).
Take jQuery chosen for example (thanks for the link Yury), it takes a
multi-select as source and turns it into some very nice piece of UI. It
doesn't matter whether you originally have a bunch of check-boxes or a
multi-select from a JS perspective.

Anyhow, I would still appreciate if someone would merge the thing, it's
sitting around for too long already and it seems that it got stuck because
of some very minor issue once again:
https://gerrit.wikimedia.org/r/#/c/8924/
Thanks!

--
Daniel Werner
Software Engineer

Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin
Tel. (030) 219 158 26-0

http://wikimedia.de

Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/681/51985.
_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


daniel at nadir-seen-fire

Sep 30, 2012, 1:55 PM

Post #10 of 13 (546 views)
Permalink
Re: HTMLMultiSelectField as <select multiple="multiple"/> [In reply to]

On Sun, 30 Sep 2012 13:41:30 -0700, Daniel Werner
<daniel.werner [at] wikimedia> wrote:

> On Sep 29, 2012, at 4:51 AM, Daniel Friesen <daniel [at] nadir-seen-fire>
> wrote:
>> Yes, multiselect is a VERY bad usability choice. Frankly we shouldn't
>> use
> it anywhere. If we're using JS to make
>> a better UI it would actually be much better to output usable checkboxes
> and then turn the checkboxes into a
>> special JS multi-select. Instead of outputting an unusable multi-select
> and compensating for it.
>
>>
> Sure, as long as there is JS available we should turn the multi-select
> into
> something nicer. But the original idea behind this was that a multi
> select
> would still be more user friendly than an endless list of check-boxes
> when
> having around 300 choices (e.g. for languages).

Checkboxes would still be better for non-js users... in this case
multiselect is even worse. Now not only do you have to worry about users
not knowing they can select multiple items, when they try to actually
select a bunch of items their own computer is going to inevitably screw
them over at some point when they forget the ctrl or their finger slips
off of it, they click, and poof the dozens of items they selected ALL
disappear.
That kind of situation is incredibly more anti-user than a list of
checkboxes. And you can get most of the same scrolling effect just by
giving the checkbox list an overflow: auto;

> Take jQuery chosen for example (thanks for the link Yury), it takes a
> multi-select as source and turns it into some very nice piece of UI. It
> doesn't matter whether you originally have a bunch of check-boxes or a
> multi-select from a JS perspective.
>
> Anyhow, I would still appreciate if someone would merge the thing, it's
> sitting around for too long already and it seems that it got stuck
> because
> of some very minor issue once again:
> https://gerrit.wikimedia.org/r/#/c/8924/
> Thanks!
>


--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]


_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


jeroendedauw at gmail

Sep 30, 2012, 2:02 PM

Post #11 of 13 (545 views)
Permalink
Re: HTMLMultiSelectField as <select multiple="multiple"/> [In reply to]

Hey,

> On 30 September 2012 22:55, Daniel Friesen <daniel [at] nadir-seen-fire>wrote:
> Checkboxes would still be better for non-js users...

I'm sure people can find situations in which using a multiselect is not a
good idea. Does that mean we should not have a multiselect input type
developers can use when they think it is applicable? :)

Cheers

--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil.
--
_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


krinklemail at gmail

Sep 30, 2012, 9:23 PM

Post #12 of 13 (537 views)
Permalink
Re: HTMLMultiSelectField as <select multiple="multiple"/> [In reply to]

Nobody (afaik) is saying that jQuery chosen isn't better than a bunch of
checkboxes.

The point is that <select multiple> (without javascript enhancement) is horrible
and (imho) unacceptable. And no, it is not because we found situations in which
it is not a good idea. It is because it is never a good idea, never.

The solution I'd propose (and Daniel also mentioned this various times here and
elsewhere) to output checkboxes as fallback and an interface like "jQuery Chosen"
as enhancement.

-- Krinkle


_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


daniel.werner at wikimedia

Oct 1, 2012, 6:20 AM

Post #13 of 13 (534 views)
Permalink
Re: HTMLMultiSelectField as <select multiple="multiple"/> [In reply to]

Alright, you convinced me that a scrollable(!) list of check boxes (using
overflow scroll) might be better than a multi select. That is if you have
at least CSS enabled. Without CSS I would definitely go for a multi-select
because a list of 300 checkboxes still sucks more in my opinion.

I guess I could change my change set to add those css styles rather than
using a multi-select, or even add some css per default to avoid utterly
long lists of checkboxes.

On the other hand, this had been on the list and in review for months now
and there are people who would find a multiselect useful apparently. It
seems close to impossible to make it right for everybody. It doesn't really
seem productive nor motivating to question small changes like this in all
details after non trivial amount of work has gone into it by different
parties (discussion, several patch-sets, reviews). For now I have abandoned
this since I don't even need it anymore in STTL. So may someone else try to
improve upon it or not.

Cheers,
Daniel

2012/10/1 Krinkle <krinklemail [at] gmail>

> Nobody (afaik) is saying that jQuery chosen isn't better than a bunch of
> checkboxes.
>
> The point is that <select multiple> (without javascript enhancement) is
> horrible
> and (imho) unacceptable. And no, it is not because we found situations in
> which
> it is not a good idea. It is because it is never a good idea, never.
>
> The solution I'd propose (and Daniel also mentioned this various times
> here and
> elsewhere) to output checkboxes as fallback and an interface like "jQuery
> Chosen"
> as enhancement.
>
> -- Krinkle
>
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l [at] lists
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>



--
Daniel Werner
Software Engineer

Wikimedia Deutschland e.V. | NEU: Obentrautstr. 72 | 10963 Berlin
Tel. (030) 219 158 26-0

http://wikimedia.de

Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/681/51985.
_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Wikipedia wikitech RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.