Re: [Wikitech-l] Does [EMAIL PROTECTED] work?
[EMAIL PROTECTED] redirects to info-en::[EMAIL PROTECTED], IIRC, that is to a subqueue of info-en. However, this subqueue often only contains spam, that is, we should makes sure that OTRS people keep an eye on the subqueue now. Michael On Mon, Dec 8, 2008 at 11:09 AM, David Gerard [EMAIL PROTECTED] wrote: Just a quick check - I did the BBC Radio 4 Today show about the [[:en:Virgin Killer]] blocking. Both presenters asked afterwards how to get their crappy articles fixed - I said email [EMAIL PROTECTED]. Bet you they email [EMAIL PROTECTED] - does that address redirect in the obvious and sensible fashion? Same for info-en@, etc? I realise these addresses are deprecated, but you know people are going to go there first. - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Michael Bimmler [EMAIL PROTECTED] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bring your language to Commons
Hi, I never liked a bot to welcome new users. Isn't it much better to do it by hand? So people also have a contact to go to with qeustions. -- Leave nothing but footprints, take nothing but pictures http://commons.wikimedia.org/wiki/User:SterkeBak ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bring your language to Commons
Hi! On Mon, Dec 8, 2008 at 9:55 AM, Brion Vibber [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eugene Zelenko wrote: How about demanding from foundation to allocate some part of latest usability improvement grant/resources (http://wikimediafoundation.org/wiki/Press_releases/Wikipedia_to_become_more_user-friendly_for_new_volunteer_writers) to solve at some of Commons problems? We probably won't get to much Commons-specific stuff in there, but we'll see what sub-projects come up. Will be good idea to find old e-mail to wikitech-l from Brianna Laugher with Commons requirements since most of the requests still not implemented :-( For example, unsupported categories translation already used for Commons bad publicity on Russian Wikipedia. As for user language: see comments in similar request about user's gender (https://bugzilla.wikimedia.org/show_bug.cgi?id=13040), which also affect quality of MediaWiki localizations. Will social gender (often, but not always aligned with biological sex) always track with grammatical gender? I hope so :-) What are the cascading implications of user gender on localization (adjective agreement in Romance languages, verb agreement in Semitic languages) and what technical requirements would be imposed? Messages should be similar to GRAMMAR (for example GENDER). So sentences such as User uploaded could be more correctly translated as Участник загрузил/Участница загрузила on Russian or Удзельнік загрузіў/Удзельніца загрузіла on Belarusian. Same thing for Polish/Ukrainian and most likely for other Slavic languages. Gender settings could be also used in Babel extension and user boxes (currently uses parameters for this purpose). - -- brion -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkk9X4EACgkQwRnhpk1wk44/AACgu3otzh0dqTkIZRi/W5VGbPfn 9sIAmwbir/irI6iViQHWAZ9GgrSdVckM =GE4z -END PGP SIGNATURE- ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l Eugene. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] The never-dying topic: category intersection (been there done that .. to the power of three)
Gregory Maxwell wrote: Because adding the parents produces non-sense results because categorization is a flawed concept except at the most fuzzy and course levels: Reality doesn't fit into neat nested boxes (not even the N-dimensional ones created by multiple parentage). The two primary problems are semantic drift (the further away you get from a relationship the more not-quite-matching error accumulates), and multiple link types (we use categories to describe different types of membership, and while within a type the membership relation is commutative among types it is usually not). So with parentages you get chains like [periodic table]-[hydrogen]-[hydrogen compounds]-[water]-[places with water]-[beaches]-[beaches in america]-[beaches of lalaville]-[lalavill beach]-[Image:Ironmeteor_at_lalavill_beach.jpg] Is an iron meteor a beach in america or a hydrogen compound? No. True, but there are _some_ relationships that should always hold. All dogs are animals. All integers are numbers. All places in New York are in the United States. Arguably, any page which is in [[Category:Dogs]] but not in [[Category:Animals]] is a failure of atomic categorization. Of course, there are also many relationships that _don't_ hold so strictly. Most dogs are pets, but not all. Most places in the United States are in North America, but not all. So, yes, some of the consistency checking will have to be done at least partly manually. But really, I wouldn't worry about this too much. Sure, having a way to enforce some category relationships would be useful, as would automatically recommending others. But even if we don't implement it immediately in the software, someone will write a bot (or several) to help with it. It won't be perfect, but I wouldn't expect it to be much more broken than the current interlanguage link system, which we consider useful enough to keep deployed despite its numerous failings. (While thinking about this, I thought back to an earlier discussion on this list (or possibly wikien-l, can't remember now) about the fact that there are essentially two types of categories: thematic and taxonomic. For the former, the tag model of atomic categorization is quite natural, but the latter would fit much more naturally into a strictly hierarchical model. It might not be an entirely unreasonable idea to formally split the two, perhaps even into separate namespaces, and apply different technical approaches to handling them.) -- Ilmari Karonen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bring your language to Commons
On Mon, Dec 8, 2008 at 12:55 PM, Brion Vibber [EMAIL PROTECTED] wrote:
Will social gender (often, but not always aligned with biological sex)
always track with grammatical gender?
I believe there are some languages with more complicated gender
systems than just male/female. On the other hand, getting just the
male/female/unknown distinction right would be a huge improvement for
a lot of languages, so it's probably worth it to do just that.
If there are significant other uses of gender in some languages, we
might consider offering different preferences for them somehow. So
for instance, if the hypothetical language Zulitutsi used different
verbs for people who were above or below the age of 30, we could add
an extra option when either the interface language *or* the user
language is Zulitutsi, Are you above the age of 30? This could then
be handled in the same framework as gender generally (see below for
thoughts on that). Of course, a Zulitutsi speaker on enwiki would
then find that almost all other users would fall back to the unknown
case, but that's acceptable.
I would wait for actual use-cases to come up to bother with this,
though. We should just make sure that nothing in the basic framework
really strictly assumes a male/female/unknown trichotomy.
What are the cascading implications of user gender on localization
(adjective agreement in Romance languages, verb agreement in Semitic
languages) and what technical requirements would be imposed?
You'd likely need to write messages like Automatically block the last
IP address used by this user, and any subsequent IPs {{#gender:$1|he
tries|she tries|they try}} to edit from, where $1 is the *username*
of the affected user. This could be handled the way we handle plurals
right now, no huge deal in that sense: things like verb/adjective
agreement would come free, since they'd just be manually specified in
the messages. If there are more genders somehow, those could be dealt
with the same way as with plurals (specify that in the Language class
somehow).
The difficulty here is of course that the genders of all users would
have to be stored in the database, and every call to #gender would
require a query. In particular, for many languages this would require
a query for every link to a user page (of a user who exists). We
would have to batch these somehow; that might be the only tricky part
of writing this. Most likely we'd want to store this as a new field,
not in user_options, because we'd be fetching it pretty often when we
wouldn't want the rest of the user's options.
Note that I made the first argument to {{#gender:}} a username, not an
actual gender. The latter would be much, much more invasive, because
it would require every single message that could possibly use the
gender of a particular user to pass that gender in as a parameter,
which would be a huge mess. It's better from a functionality/code
cleanliness point of view to accept the username as an argument and
treat initialization of the gender as an optimization.
On the other hand, this might have serious performance implications if
users begin spamming genders everywhere (as is likely). If some way
could be contrived that we wouldn't mind retrieving the gender of
hundreds of (random and unpredictable) users per request, that would
be great. In principle it's little enough info that we could easily
cache it locally on all the app servers, but that seems like a lot of
effort. We might want to initially be optimistic and just fetch from
the database, precaching with batch queries where appropriate, and see
if it becomes a problem. We could add it as an option first, off by
default, and try enabling it gradually on large wikis to see if it
becomes a problem. Fetching unbatched genders from memcached would
likely be a good idea (but large batches should likely still go to the
DB so they can be fetched all at once).
You'd need to special-case the User namespace, undoubtedly, because I
doubt we want to support parser functions in namespace names, but
pretty much everything else should be possible to handle by just the
addition of that one parser function and the appropriate database
field.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] The never-dying topic: category intersection
On Mon, Dec 8, 2008 at 5:38 PM, Aerik Sylvan [EMAIL PROTECTED] wrote: Okay, it's not quite done, and it's still really crude, but starting to take shape - I've got some basic intersections functionality running on Wikidweb - I hacked skin.php and added links to the special intersections page. The intersections are using a MyIsam fulltext index. I'm not using 'boolean mode' queries, as this seems to give more interesting results. Is there a patch available somewhere? Have you asked for commit access to work on this in the Wikimedia repo? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Altering main page title via Pagetitle-view-mainpage property
On Tue, Dec 9, 2008 at 12:02 AM, Peter Adams [EMAIL PROTECTED] wrote: How does one change the page title template used for main page? I saw that the latest version of mediawiki release notes mentioned a property called 'Mediawiki:Pagetitle-view-mainpage', however editing that alone doesn't seem to do the trick. I'd prefer not to hack the template class/files if possible. What do you mean by template? The contents of the title element of the main page can be overridden with MediaWiki:Pagetitle-view-mainpage - that's all there is to it. See http://en.wikipedia.org/wiki/MediaWiki:Pagetitle-view-mainpage for an example. -- Remember the dot http://en.wikipedia.org/wiki/User:Remember_the_dot ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
