Re: [Wikitech-l] SVN commit access
* Jan Luca j...@jans-seite.de [Sun, 30 Aug 2009 14:35:00 +0200]: Hello, you must use your private key and not a password. Hello, Jan! I've been asking about this problem in IRC. I've been suggested debug using ssh-l questpc -vvv svn.wikimedia.org . It the debug log (-vvv) it says the order is publickey, then password. It tires the password only because publickey fails. Switched to old key pair, but no luck. I'll try to figure out by myself. Until that, I am just re-submitting the request with new public key. For Linux: Run ssh-add /path/to/your/private/key/file I use linux in this case. My mistake probably was that the first (old) keys were generated by trial-and-error studying ssh options, only at the second attempt I've processed according to FAQ: http://sial.org/howto/openssh/publickey-auth/ BTW, they say that authorization should work without setting up nohup ssh-agent -s ~/.ssh-agent and using ssh-add. ssh-agent and ssh-add are only the handy way to cache your passphrase: To reduce the frequency with which the key passphrase must be typed in, setup a ssh-agent(1) daemon to hold the private portion of the RSA key pair for the duration of a session. There are several ways to run and manage ssh-agent, for example from a X11 login script or with a utility like Keychain. These notes rely on the setup of ssh-agent via an @reboot crontab(5) entry, along with appropriate shell configuration. Dmitriy ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikistats
Domas Mituzas wrote:
Hello Anthony,
I'm back at my lair (phew, finally ;-)
Regarding the files at http://dammit.lt/wikistats/ :
What are en.b, en.d, en2, etc?
suffixes indicate projects - from
http://svn.wikimedia.org/viewvc/mediawiki/trunk/webstatscollector/filter.c?revision=34989view=markup
:
projects[] = {
{wikipedia,,NULL},
{wiktionary,.d,NULL},
{wikinews,.n,NULL},
{wikimedia,.m,check_wikimedia},
{wikibooks,.b,NULL},
{wikisource,.s,NULL},
{mediawiki,.w,NULL},
{wikiversity,.v,NULL},
{wikiquote,.q,NULL},
NULL
},
en2 is, um, http://en2.wikipedia.org/ ;-) it used to exist once upon a
time, and apparently there're some referrals.
Are edits included, or only views?
That is views only - though you can find actual logic in above file,
it is mostly this pattern:
http://*.*.org/wiki/*
which is what we have for special pages and views.
Are the hit counts actual, or 1/10th sampled, or something else?
They are actual, with duplicates removed (that is, we don't count in
cache-to-cache traffic, only end-user-to-cache).
pagecounts-20090501-20.gzhttp://dammit.lt/wikistats/pagecounts-20090501-20.gz
is
the hour *beginning* 20:00:00?
ending, I think. let me check, yes, end time. logic is in
produceDump() at
http://svn.wikimedia.org/viewvc/mediawiki/trunk/webstatscollector/collector.c?revision=30113view=markup
:)
I think I may end up documenting this somewhat more, but I need to do
some promised and long overdue development on this project.
If no one minds, I think I will copy this email to the toolserver wiki :)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikistats
Hello Anthony,
I'm back at my lair (phew, finally ;-)
Regarding the files at http://dammit.lt/wikistats/ :
What are en.b, en.d, en2, etc?
suffixes indicate projects - from
http://svn.wikimedia.org/viewvc/mediawiki/trunk/webstatscollector/filter.c?revision=34989view=markup
:
projects[] = {
{wikipedia,,NULL},
{wiktionary,.d,NULL},
{wikinews,.n,NULL},
{wikimedia,.m,check_wikimedia},
{wikibooks,.b,NULL},
{wikisource,.s,NULL},
{mediawiki,.w,NULL},
{wikiversity,.v,NULL},
{wikiquote,.q,NULL},
NULL
},
en2 is, um, http://en2.wikipedia.org/ ;-) it used to exist once upon a
time, and apparently there're some referrals.
Are edits included, or only views?
That is views only - though you can find actual logic in above file,
it is mostly this pattern:
http://*.*.org/wiki/*
which is what we have for special pages and views.
Are the hit counts actual, or 1/10th sampled, or something else?
They are actual, with duplicates removed (that is, we don't count in
cache-to-cache traffic, only end-user-to-cache).
pagecounts-20090501-20.gzhttp://dammit.lt/wikistats/pagecounts-20090501-20.gz
is
the hour *beginning* 20:00:00?
ending, I think. let me check, yes, end time. logic is in
produceDump() at
http://svn.wikimedia.org/viewvc/mediawiki/trunk/webstatscollector/collector.c?revision=30113view=markup
:)
I think I may end up documenting this somewhat more, but I need to do
some promised and long overdue development on this project.
Domas
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Links to Special:ListUsers/...
Aryeh Gregor wrote: On Sun, Aug 30, 2009 at 8:37 PM, Platonidesplatoni...@gmail.com wrote: You get a request for page Foo:Bar. It could be a page name, or Foo could mean Special in Bantu. How do you check (efficiently) over 300 languages? Ouch. Okay, that's out for namespaces. It should work fine for special page names, though, right? Although I guess that's semi-pointless if the Special: part doesn't work. Special page names are better in the sense that you know what it is offhand, but i'm not sure if such search is still acceptable. Clearly it was a bad idea to use a character for namespace separator that's allowed in page names. Crazy idea, but maybe we could still change . . . would it cause conflicts to use , say? I don't think it'd get too much support. Then we could display the namespace in a breadcrumb-y fashion, with spaces on either side. Obviously we'd accept : forever as well, for compatibility. I'd think it would be pretty easy to get most stuff working with a new namespace separator, just some hackery with Title::secureAndSplit() should do it. You would need to deal with the parser, for linking to non-ns0 namespaces. I'd prefer not to add a new complexity there. I'd prefer an option (stored as a global preference) to use canonical names instead of localised ones. It doesn't need to redirect from localised to canonical, simply keep the url which was inputted. It's uncomfortable browsing to xy.wikipedia.org/wiki/Special:something, then moving to check it on yx.wikpedia, and having to go back to retype the pagename because Spécialis:somethingelese doesn't exist. Having canonical pagenames also used to be helpful when browsing a wiki on a foreign language to determine which link lead to eg. the contributions of a user, by hovering the different options (now you will need to change to ?uselang=). This should work fine with a global language preference, shouldn't it? Only for the later usecase. And it's more intrusive. You may want some wikis to be kept on the original language and understand enough for the other just with url tips. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] how to chang {{SITENAME}}
Hello,
For example, [[MediaWiki:Aboutsite]] have the default message About
{{SITENAME}}. But we have overwritten it by ウィキペディ
アについて
（translated word from about Wikipedia).
Performance-wise it is even better, if all main messages which have
{{SITENAME}} get replacements with literals. Otherwise you're adding
up 5ms of page load time to each page. :)
Domas
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] how to chang {{SITENAME}}
2009/8/31 Domas Mituzas midom.li...@gmail.com:
Hello,
For example, [[MediaWiki:Aboutsite]] have the default message About
{{SITENAME}}. But we have overwritten it by ウィキペディ
アについて
（translated word from about Wikipedia).
Performance-wise it is even better, if all main messages which have
{{SITENAME}} get replacements with literals. Otherwise you're adding
up 5ms of page load time to each page. :)
It would be good if that was documented ;-P
http://www.mediawiki.org/wiki/Manual:Interface/Aboutsite
I asked about this a while ago.
http://www.mediawiki.org/wiki/Project:Support_desk/Archives/Miscellaneous/007#tuning_MediaWiki:Aboutsite
--
John Vandenberg
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikistats
Hi, However, note that after saving an edit, the editor will be sent to a view. yes, you're absolutely right, but no differentiation is done on that. technically, you're not editing, you're viewing :) Domas ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Fwd: [WikiEN-l] Wired: Wikipedia to Color Code Untrustworthy Text
Hi all, According to Wired, WikiTrust will be enabled on Wikipedia. Does anyone know anything about this? It's also been picked up by TG Daily - http://www.tgdaily.com/content/ view/43812/140/ - which says it's already in place. Mike Begin forwarded message: From: Keith Old keith...@gmail.com Date: 31 August 2009 01:24:50 BDT To: English Wikipedia wikie...@lists.wikimedia.org Subject: [WikiEN-l] Wired: Wikipedia to Color Code Untrustworthy Text Reply-To: English Wikipedia wikie...@lists.wikimedia.org Folks, http://www.wired.com/wiredscience/2009/08/wikitrust/ Wired reports: *Starting this fall, you’ll have a new reason to trust the information you find on Wikipedia: An optional feature called “WikiTrust” will color code every word of the encyclopedia based on the reliability of its author and the length of time it has persisted on the page.* *More than 60 million people visit the free, open-access encyclopedia each month, searching for knowledge on 12 million pages in 260 languages. But despite its popularity, **Wikipedia*http://www.wired.com/wiredscience/2009/08/wikitrust/ www.wikipedia.org * has long suffered criticism from those who say it’s not reliable. Because anyone with an internet connection can contribute, the site is subject to vandalism, bias and misinformation. And edits are anonymous, so there’s no easy way to separate credible information from fake content created by vandals.* *Now, researchers from the **Wiki Lab* http://trust.cse.ucsc.edu/ * at the University of California, Santa Cruz have created a system to help users know when to trust Wikipedia—and when to reach for that dusty Encyclopedia Britannica on the shelf. Called **WikiTrust*http://wikitrust.soe.ucsc.edu/index.php/Main_Page *, the program assigns a color code to newly edited text using an algorithm that calculates author reputation from the lifespan of their past contributions. It’s based on a simple concept: The longer information persists on the page, the more accurate it’s likely to be.* *Text from questionable sources starts out with a bright orange background, while text from trusted authors gets a lighter shade. As more people view and edit the new text, it gradually gains more “trust” and turns from orange to white.* More in story *Regards* ** *Keith* ___ WikiEN-l mailing list wikie...@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikistats
Domas Mituzas wrote: Hi, However, note that after saving an edit, the editor will be sent to a view. yes, you're absolutely right, but no differentiation is done on that. technically, you're not editing, you're viewing :) Domas I know, but its worth remembering that to people who might want to do some kind of edit differenciating. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikistats
On Mon, Aug 31, 2009 at 11:03 AM, Domas Mituzasmidom.li...@gmail.com wrote: en2 is, um, http://en2.wikipedia.org/ ;-) it used to exist once upon a time, and apparently there're some referrals. Wikimedia news, October 2003: -- A portion of traffic to www.wikipedia.org will be diverted to en2.wikipedia.org, while most of it will go to en.wikipedia.org, where all logins will be directed. Until the server configuration is more stable and transparent load-sharing is set up, this should help share some of the traffic without burdening the other wikis too greatly. -- I think the reason that en got the lion's share is that en2 was on one machine with the other languages whereas en was on a machine on its own. At that time apparently en: still had significantly more traffic than all other languages taken together. -- André Engels, andreeng...@gmail.com ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikistats
Andre, Wikimedia news, October 2003: Thanks for that! Awesome artifact ;-) Domas ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Fwd: [WikiEN-l] Wired: Wikipedia to Color Code Untrustworthy Text
On 8/31/09 7:35 AM, Michael Peel wrote: Hi all, According to Wired, WikiTrust will be enabled on Wikipedia. Does anyone know anything about this? We've been planning to get a test setup together since conversations at the Berlin developer meetup in April, but actual implementation of it is pending coordination with Luca and his team. My understanding is that work has proceeded pretty well on setting it up to be able to fetch page history data more cleanly internally, which was a prerequisite, so we're hoping to get that going this fall. It's also been picked up by TG Daily - http://www.tgdaily.com/content/ view/43812/140/ - which says it's already in place. That sounds a bit factually incorrect. :) -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] how to chang {{SITENAME}}
Hoi, Changing the messages in this way may be good from a performance perspective it really hurts the usability of our messages. Messages are localised at translatewiki.net and this is where we do require these messages. When messages are to have hardcoded strings as you propose you defeat the objectives of using a set of messages that are universally usable. In my opinion your proposal has really nasty side effects so my question is how you want to ensure that we are not working cross purposes. Thanks, GerardM 2009/8/31 Domas Mituzas midom.li...@gmail.com I asked about this a while ago. http://www.mediawiki.org/wiki/Project:Support_desk/Archives/Miscellaneous/007#tuning_MediaWiki :Aboutsite asking on-wiki doesn't really makes much sense, as I don't read it ;-p Anyway, we have to ensure, that most of wikis (at least top20 ones) have got ridden of curly braces and any other expensive parser stuff in these messages, as that costs them up to 10 milliseconds per pageview (if anyone writes a bot to do this automatically, I'd gladly run it with my global super duper privileges :)) : aboutpage aboutsite accesskey-ca-delete accesskey-ca-edit accesskey-ca-history accesskey-ca-move accesskey-ca-nstab-main accesskey-ca-talk accesskey-ca-unprotect accesskey-ca-view accesskey-ca-watch accesskey-n-aboutsite accesskey-n-contact accesskey-n-contents accesskey-n-currentevents accesskey-n-featuredcontent accesskey-n-help accesskey-n-mainpage-description accesskey-n-portal accesskey-n-randompage accesskey-n-recentchanges accesskey-n-sitesupport accesskey-p-logo accesskey-pt-acaibeta accesskey-pt-betafeedback accesskey-pt-logout accesskey-pt-mycontris accesskey-pt-mytalk accesskey-pt-preferences accesskey-pt-userpage accesskey-pt-watchlist accesskey-search accesskey-search-fulltext accesskey-search-go accesskey-t-permalink accesskey-t-print accesskey-t-recentchangeslinked accesskey-t-specialpages accesskey-t-upload accesskey-t-whatlinkshere actions cite_article_link coll-add_page_tooltip coll-create_a_book coll-help_collections_tooltip coll-helppage coll-printable_version_pdf contact-url currentevents-url delete disclaimerpage disclaimers edit helppage history_short interaction jumpto jumptonavigation jumptosearch lastmodifiedat mainpage move mycontris mypreferences mytalk mywatchlist namespaces navigation nstab-main opensearch-desc optin-feedback optin-leave otherlanguages pagetitle pagetitle-view-mainpage permalink personaltools portal-url printableversion privacy privacypage randompage-url recentchanges-url recentchangeslinked-toolbox retrievedfrom search search-mwsuggest-disabled search-mwsuggest-enabled searcharticle searchbutton sidebar site-atom-feed site-rss-feed sitenotice sitesupport-url specialpages tagline talk toolbox tooltip-ca-delete tooltip-ca-edit tooltip-ca-history tooltip-ca-move tooltip-ca-nstab-main tooltip-ca-talk tooltip-ca-unprotect tooltip-ca-view tooltip-ca-watch tooltip-n-aboutsite tooltip-n-contact tooltip-n-contents tooltip-n-currentevents tooltip-n-featuredcontent tooltip-n-help tooltip-n-mainpage-description tooltip-n-portal tooltip-n-randompage tooltip-n-recentchanges tooltip-n-sitesupport tooltip-p-coll-create_a_book tooltip-p-interaction tooltip-p-logo tooltip-p-navigation tooltip-pt-acaibeta tooltip-pt-betafeedback tooltip-pt-logout tooltip-pt-mycontris tooltip-pt-mytalk tooltip-pt-preferences tooltip-pt-userpage tooltip-pt-watchlist tooltip-search tooltip-search-fulltext tooltip-search-go tooltip-t-permalink tooltip-t-print tooltip-t-recentchangeslinked tooltip-t-specialpages tooltip-t-upload tooltip-t-whatlinkshere unprotect unwatch unwatching upload userlogout vector-action-delete vector-action-move vector-action-unprotect vector-namespace-main vector-namespace-talk vector-view-edit vector-view-history vector-view-view views watch watching whatlinkshere wikimedia-copyright Domas ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikistats
On 8/31/09 7:51 AM, Andre Engels wrote: On Mon, Aug 31, 2009 at 11:03 AM, Domas Mituzasmidom.li...@gmail.com wrote: en2 is, um, http://en2.wikipedia.org/ ;-) it used to exist once upon a time, and apparently there're some referrals. Wikimedia news, October 2003: -- A portion of traffic to www.wikipedia.org will be diverted to en2.wikipedia.org, while most of it will go to en.wikipedia.org, where all logins will be directed. Until the server configuration is more stable and transparent load-sharing is set up, this should help share some of the traffic without burdening the other wikis too greatly. -- I think the reason that en got the lion's share is that en2 was on one machine with the other languages whereas en was on a machine on its own. At that time apparently en: still had significantly more traffic than all other languages taken together. Ah, the good old days! Sure glad we figured out Squid soon after that... ;) -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] how to chang {{SITENAME}}
On Mon, Aug 31, 2009 at 7:10 AM, Gerard Meijssengerard.meijs...@gmail.com wrote: Hoi, Changing the messages in this way may be good from a performance perspective it really hurts the usability of our messages. Messages are localised at translatewiki.net and this is where we do require these messages. When messages are to have hardcoded strings as you propose you defeat the objectives of using a set of messages that are universally usable. In my opinion your proposal has really nasty side effects so my question is how you want to ensure that we are not working cross purposes. Thanks, GerardM Yes, but once the wiki has the base message and they've customized it, there's certainly an incentive to using the string instead of the magic word. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] how to chang {{SITENAME}}
Hi!
Changing the messages in this way may be good from a performance
perspective
it really hurts the usability of our messages. Messages are
localised at
translatewiki.net and this is where we do require these messages. When
messages are to have hardcoded strings as you propose you defeat the
objectives of using a set of messages that are universally usable.
I'm suggesting doing that just on our wikis. Mediawiki users can have
whatever expensive logic, I don't care that much :-)
In my opinion your proposal has really nasty side effects so my
question is
how you want to ensure that we are not working cross purposes.
Using {{ on common messages is no-go on major wikimedia wikis. Again,
people can do whatever transformations they want at any level, except
final mediawiki message logic that is on our site.
BR,
Domas
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] how to chang {{SITENAME}}
Hoi,
There are two opposing objectives at play. Performance is one and quality
localisation for MediaWiki in all our projects is the second. Just stating
that performance trumps our localisation is also very much a nono.
These are consequences and they have to be considered. Just breaking the way
our localisation works in this way is at least equally unacceptable as poor
performance is.
Thanks,
GerardM
2009/8/31 Domas Mituzas midom.li...@gmail.com
Hi!
Changing the messages in this way may be good from a performance
perspective
it really hurts the usability of our messages. Messages are
localised at
translatewiki.net and this is where we do require these messages. When
messages are to have hardcoded strings as you propose you defeat the
objectives of using a set of messages that are universally usable.
I'm suggesting doing that just on our wikis. Mediawiki users can have
whatever expensive logic, I don't care that much :-)
In my opinion your proposal has really nasty side effects so my
question is
how you want to ensure that we are not working cross purposes.
Using {{ on common messages is no-go on major wikimedia wikis. Again,
people can do whatever transformations they want at any level, except
final mediawiki message logic that is on our site.
BR,
Domas
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Links to Special:ListUsers/...
On Mon, Aug 31, 2009 at 5:04 AM, Platonidesplatoni...@gmail.com wrote: Special page names are better in the sense that you know what it is offhand, but i'm not sure if such search is still acceptable. Why not? I can't think of any problems. I don't think it'd get too much support. Maybe, but substantive objections would be useful. You would need to deal with the parser, for linking to non-ns0 namespaces. I'd prefer not to add a new complexity there. It has nothing to do with the parser. When the parser finds a link, it just passes it off to a Title method. As far as I can think (without having actually tried it), it would be a fairly small change. It's uncomfortable browsing to xy.wikipedia.org/wiki/Special:something, then moving to check it on yx.wikpedia, and having to go back to retype the pagename because Spécialis:somethingelese doesn't exist. Having canonical pagenames also used to be helpful when browsing a wiki on a foreign language to determine which link lead to eg. the contributions of a user, by hovering the different options (now you will need to change to ?uselang=). This should work fine with a global language preference, shouldn't it? Only for the later usecase. Why doesn't it work for the first use case? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] RegioWikiCamp - September 25-27, Germany
Hi, I just heard about an unconference event called RegioWikiCamp. I imagine it will be of interest to lots of folks living near Germany (if you are not all conferenced out after Wikimania!). http://wiki.regiowiki.eu/RegioWikiCamp_2009 It will be from September 25th to 27th. The event is located in Furtwangen the middle of the beautiful Black Forest in Germany. It is organised by the European Regiowiki Society, location host is the faculty of Digital Media of the Furtwangen University of Applied Science. I see that some of the attendees include WMDE, Wikia and Semantic MediaWiki, so it must not be a completely unknown event, although I didn't find it mentioned on these lists yet. cheers Brianna -- They've just been waiting in a mountain for the right moment: http://modernthings.org/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] how to chang {{SITENAME}}
Hoi, Thank you for the hyperbole.. Your representation insinuates that our systems will crash unless this change is implemented. Fact is that currently our messages are parsed. Thanks, GerardM 2009/8/31 Aryeh Gregor simetrical+wikil...@gmail.comsimetrical%2bwikil...@gmail.com On Mon, Aug 31, 2009 at 8:27 AM, Gerard Meijssengerard.meijs...@gmail.com wrote: There are two opposing objectives at play. Performance is one and quality localisation for MediaWiki in all our projects is the second. Just stating that performance trumps our localisation is also very much a nono. These are consequences and they have to be considered. Just breaking the way our localisation works in this way is at least equally unacceptable as poor performance is. Slightly more burdensome localization makes the localizers' lives a bit more difficult. Running out of CPU means the site will crash. So, no, I don't think so. Of course, it would be nice if someone came up with a solution that everyone was happy with, but until then, performance *is* more important than localization convenience. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] how to chang {{SITENAME}}
On Mon, Aug 31, 2009 at 10:17 AM, Gerard
Meijssengerard.meijs...@gmail.com wrote:
Hoi,
Thank you for the hyperbole.. Your representation insinuates that our
systems will crash unless this change is implemented. Fact is that currently
our messages are parsed.
Thanks,
GerardM
2009/8/31 Aryeh Gregor
simetrical+wikil...@gmail.comsimetrical%2bwikil...@gmail.com
On Mon, Aug 31, 2009 at 8:27 AM, Gerard
Meijssengerard.meijs...@gmail.com wrote:
There are two opposing objectives at play. Performance is one and quality
localisation for MediaWiki in all our projects is the second. Just
stating
that performance trumps our localisation is also very much a nono.
These are consequences and they have to be considered. Just breaking the
way
our localisation works in this way is at least equally unacceptable as
poor
performance is.
Slightly more burdensome localization makes the localizers' lives a
bit more difficult. Running out of CPU means the site will crash.
So, no, I don't think so. Of course, it would be nice if someone came
up with a solution that everyone was happy with, but until then,
performance *is* more important than localization convenience.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
In the WMF environment, I know a lot of instances of {{SITENAME}}
have been changed to strings on a lot of the larger wikis. For the WMF,
this is a good performance gain with little drawback to the users. Their
sitename isn't changing anytime soon, so it doesn't really matter to
use {{SITENAME}} or not.
For individual wikis elsewhere, {{SITENAME}} may be of greater benefit.
This doesn't hold true for the WMF though, and that's what Domas is
talking about.
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] how to chang {{SITENAME}}
No need to have a heated debate here, I think.
I have known about this issue for high traffic MediaWiki wikis for at least
a year and a half - Domas actually made me aware of it, and based on that I
made a few changes in the Dutch language Wikipedia and notified some admins
of other larger Wikipedias about the resource use advantages it could have
for the WMF. Changing {{SITENAME}} in a few messages of the content language
to whatever that sitename is supposed to be replaced for fixes the issue.
That's it, nothing more.
There is also no need to change something in the standard localisation.
{{SITENAME}} works fine as it is where it is being used, although not using
it if possible is a better alternative, as {{SITENAME}} usage poses problems
in most languages that should have different grammar forms for SITENAME. We
(i18n dudes - still looking for girls in that area) have in the past
actively reduced SITENAME usage in messages, although nothing rigid was
done, and a closer look at it might not be a bad idea.
Cheers!
Siebrand
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] how to chang {{SITENAME}}
On Mon, Aug 31, 2009 at 8:27 AM, Gerard Meijssengerard.meijs...@gmail.com wrote: There are two opposing objectives at play. Performance is one and quality localisation for MediaWiki in all our projects is the second. Just stating that performance trumps our localisation is also very much a nono. These are consequences and they have to be considered. Just breaking the way our localisation works in this way is at least equally unacceptable as poor performance is. Slightly more burdensome localization makes the localizers' lives a bit more difficult. Running out of CPU means the site will crash. So, no, I don't think so. Of course, it would be nice if someone came up with a solution that everyone was happy with, but until then, performance *is* more important than localization convenience. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] how to chang {{SITENAME}}
On 31/08/2009, at 9:27 AM, Gerard Meijssen wrote: Hoi, There are two opposing objectives at play. Performance is one and quality localisation for MediaWiki in all our projects is the second. Just stating that performance trumps our localisation is also very much a nono. These are consequences and they have to be considered. Just breaking the way our localisation works in this way is at least equally unacceptable as poor performance is. You haven't explained exactly what impact this will have on localisation. Perhaps providing concrete disadvantages instead of vague topic areas will make your argument more convincing. -- Andrew Garrett agarr...@wikimedia.org http://werdn.us/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] how to chang {{SITENAME}}
Domas Mituzas wrote:
Anyway, we have to ensure, that most of wikis (at least top20 ones)
have got ridden of curly braces and any other expensive parser stuff
in these messages, as that costs them up to 10 milliseconds per
pageview (if anyone writes a bot to do this automatically, I'd gladly
run it with my global super duper privileges :)) :
1) Copy that list
2) Prepend MediaWiki: namespace
3) Post to Special:Export
4) Automate it:
sed s/wiki$/wikipedia/ all.dblist all.domains
sed -i s/metawikipedia/metawikimedia/ all.domains
sed -i s/commonswikipedia/commonswikimedia/ all.domains
sed -i s/wik/.wik/ all.domains
sed -i s/.wikimania\([0-9]\+\)wikipedia/wikimania\1.wikimedia/ all.domains
sed -i s/.wikimaniateamwikipedia/wikimaniateam.wikimedia/ all.domains
sed -i s/foundation.wikipedia/wikimediafoundation/ all.domains
sed -i
s/\(strategy\|usability\|collab\|advisory\|grants\|board\|incubator\|internal\|chair\|quality\|exec\|wikimaniateam\|office\|.*com\).wikipedia/\1.wikimedia/
all.domains
sed -i s/_/-/g all.domains
sed -i s/arbcom-/arbcom./ all.domains
sed -i s/-labs/.labs/ all.domains
sed -i s/wg-en.wikipedia/wg.en.wikipedia/ all.domains
sed -i s/media.wikiwikipedia/www.mediawiki/ all.domains
while read domain; do
wget http://$domain.org/wiki/Special:Export --post-file=postdata.txt -O
$domain.txt
done all.domains
6) Profit!!
Wikis using some kind of templating
grep -l {{ *|wc -l
255
Total usage:
grep {{ *|wc -l
732
Using parserfunctions
grep {{# *|wc -l
28 (across 22 wikis: als.wikipedia.org bar.wikipedia.org
ca.wikipedia.org commons.wikimedia.org en.labs.wikimedia.org
en.wikibooks.org fa.wikipedia.org fa.wikiquote.org gl.wikipedia.org
it.wikinews.org it.wikiquote.org meta.wikimedia.org ru.wikipedia.org
simple.wikipedia.org sv.wikibooks.org tr.wikibooks.org tr.wikipedia.org
tr.wikisource.org zh.wikibooks.org zh.wikipedia.org zh.wikiquote.org
zh.wikisource.org)
grep {{PAGENAME}} *|wc -l
18
Used for namespace name:
grep {{ns: *|wc -l
226
grep {{localurl: *|wc -l
5
grep {{grammar: *|wc -l
8
grep {{plural: *|wc -l
0
grep lt;nowiki *|wc -l
0
Wikis with using all default messages:
grep -L revision * | wc -l
273
Private wikis not read:
grep html *|wc -l
23
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Links to Special:ListUsers/...
Aryeh Gregor wrote: On Mon, Aug 31, 2009 at 5:04 AM, Platonides wrote: Special page names are better in the sense that you know what it is offhand, but i'm not sure if such search is still acceptable. Why not? I can't think of any problems. They still are a lot of languages? I don't think it'd get too much support. Maybe, but substantive objections would be useful. You would need to deal with the parser, for linking to non-ns0 namespaces. I'd prefer not to add a new complexity there. It has nothing to do with the parser. When the parser finds a link, it just passes it off to a Title method. As far as I can think (without having actually tried it), it would be a fairly small change. There might be ugly cases of nowiki or other tag extensions inside [[ getting a different behavior. This should work fine with a global language preference, shouldn't it? Only for the later usecase. Why doesn't it work for the first use case? The special page names are shown in the content language, not in the user language. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] how to chang {{SITENAME}}
Hoi, Centralised localisation works when the resulting localised messages are usable and useful in all environments. More exceptions to this rule make it seem as if central localisation is not a good idea. There is already one acknowledged exception to the rule; messages that inform about the policies of a local wiki, there is now a second category and they are messages that have parameters like the system name. While I appreciate Domas' search for more performance, I am equally of the opinion that there are other factors to consider. Siebrand wrote that HE is aware of this. This is nice but we support other projects that run MediaWiki and our support should allow for THEY are aware of this. There is also a constant flow of new localised messages and these can include the list of messages that has been shown earlier in this thread. I can imagine that we have some functionality that is part of the update.php that updates these values in the plain vanilla messages. What I am looking for is proper support. The least is proper documentation and it can be expanded to a procedure that allows other wikis to benefit from the knowledge we have gained. My overriding concern is that our language support is not sacrificed at the cost of a few cycles. Even when there are a lot of them. Thanks, GerardM 2009/8/31 Andrew Garrett agarr...@wikimedia.org On 31/08/2009, at 9:27 AM, Gerard Meijssen wrote: Hoi, There are two opposing objectives at play. Performance is one and quality localisation for MediaWiki in all our projects is the second. Just stating that performance trumps our localisation is also very much a nono. These are consequences and they have to be considered. Just breaking the way our localisation works in this way is at least equally unacceptable as poor performance is. You haven't explained exactly what impact this will have on localisation. Perhaps providing concrete disadvantages instead of vague topic areas will make your argument more convincing. -- Andrew Garrett agarr...@wikimedia.org http://werdn.us/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] how to chang {{SITENAME}}
On Mon, Aug 31, 2009 at 3:56 AM, Domas Mituzasmidom.li...@gmail.com wrote:
I asked about this a while ago.
http://www.mediawiki.org/wiki/Project:Support_desk/Archives/Miscellaneous/007#tuning_MediaWiki
:Aboutsite
asking on-wiki doesn't really makes much sense, as I don't read it ;-p
Anyway, we have to ensure, that most of wikis (at least top20 ones)
have got ridden of curly braces and any other expensive parser stuff
in these messages, as that costs them up to 10 milliseconds per
pageview (if anyone writes a bot to do this automatically, I'd gladly
run it with my global super duper privileges :)) :
In the long-term, wouldn't it be smarter to make some of these stable
and quasi-stable tokens automatically cache in their evaluated state?
For something like {{SITENAME}} there is little reason to be looking
it up every single time the message loads, so why not teach Mediawiki
to pre-evaluate that and similar items before putting it in the
message cache? For the rare case that such things do change you'd
need to make sure that the cache does get rebuilt periodically (or
have someway to detect such changes and deliberately refresh the
cache), but such changes are so rare that adding some lag on update
might be acceptable.
-Robert Rohde
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Links to Special:ListUsers/...
Platonides wrote: Aryeh Gregor wrote: Tangentially, is there any actual reason we couldn't allow any language's alias (e.g., for special page names or namespaces) to work in any other language? We'd have to make sure we have a moderately sane way of resolving conflicts, but those should be extremely uncommon. You get a request for page Foo:Bar. It could be a page name, or Foo could mean Special in Bantu. How do you check (efficiently) over 300 languages? With array_key_exists(), surely? It's (AFAIK) a (nearly) constant-time hash lookup. Of course, you don't want to have to load 300 Messages*.php files just to populate that array in the first place, but that just means that we'd have to consolidate the namespace aliases into a single file if we wanted to do this, rather than scattering them across hundreds of files like we do now. I've actually long wanted something like this for Commons. At the very least, It Would Be Nice If all the localized aliases of the File/Image namespace were added to $wgNamespaceAliases for Commons. -- Ilmari Karonen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] MediaWiki and J2EE Integration
Hello All, I would appreciate if somebody could get back to me regarding the MediaWiki and J2EE applications integration. The idea is to use MediaWiki for the presentation (end-user interface) layer and documentation management, and from the same MediaWiki-based presentation layer communicate with a J2EE application that provides enterprise information management (i.e., product life cycle management, project management, stakeholder and organization management, CRM, etc.). Regards, Goran Zugic Software Architect Semantion goran.zu...@semantion.com http://www.semantion.com ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] how to chang {{SITENAME}}
Platonides platoni...@gmail.com wrote in message news:h7gok4$6v...@ger.gmane.org... 1) Copy that list 2) Prepend MediaWiki: namespace 3) Post to Special:Export 4) Automate it: ... 6) Profit!! What's step 5? :-P --HM ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Fwd: [WikiEN-l] Wired: Wikipedia to Color Code Untrustworthy Text
2009/8/31 Brion Vibber br...@wikimedia.org: On 8/31/09 7:35 AM, Michael Peel wrote: We've been planning to get a test setup together since conversations at the Berlin developer meetup in April, but actual implementation of it is pending coordination with Luca and his team. My understanding is that work has proceeded pretty well on setting it up to be able to fetch page history data more cleanly internally, which was a prerequisite, so we're hoping to get that going this fall. To add to what Brion said: The author of the Wired story, Hadley Leggett, scheduled a call with me earlier this month, but she missed the call. I didn't have time to follow up with her after that, and she filed the story without it. This is why there's no WMF quote in the story. The gist of it is that: We're very interested in WikiTrust, primarily for two reasons: - it allows us to create blamemaps for history pages, so that you can quickly see who added a specific piece of text. This is very interesting for anyone who's ever tried to navigate a long version history to find out who added something. - it potentially allows us to come up with an algorithmic best recent revision guess. This is very useful for offline exports. The trust coloring is clearly the most controversial part of the technology. However, it's also integral to it, and we think it could be valuable. If we do integrate it, it would likely be initially as a user preference. (And of course no view of the article would have it toggled on by default.) There may also be additional community consultation required. Any integration is contingent on the readiness of the technology. It seems to have matured over the last couple of years, and we're planning to meet with Luca soon to review the current state of things. There's no fixed deployment roadmap yet, and the deployment of FlaggedRevs is our #1 priority. -- Erik Möller Deputy Director, Wikimedia Foundation Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki and J2EE Integration
Thank you very much Ryan. I'll look at this and get back to you if I have any additional questions. Regards, Goran -Original Message- From: Lane, Ryan [mailto:ryan.l...@ocean.navo.navy.mil] Sent: Monday, August 31, 2009 01:22 PM To: 'Wikimedia developers' Subject: Re: [Wikitech-l] MediaWiki and J2EE Integration I would appreciate if somebody could get back to me regarding the MediaWiki and J2EE applications integration. The idea is to use MediaWiki for the presentation (end-user interface) layer and documentation management, and from the same MediaWiki-based presentation layer communicate with a J2EE application that provides enterprise information management (i.e., product life cycle management, project management, stakeholder and organization management, CRM, etc.). Goran,Take a look at the External Data extension:http://www.mediawiki.org/wiki/Extension:External_DataIt may do what you want. I've been planning on adding other protocols, suchas SOAP or XMLRPC, to it.Otherwise, you could probably do iframes or write your own extension.V/r,Ryan Lane ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki and J2EE Integration
I would appreciate if somebody could get back to me regarding the MediaWiki and J2EE applications integration. The idea is to use MediaWiki for the presentation (end-user interface) layer and documentation management, and from the same MediaWiki-based presentation layer communicate with a J2EE application that provides enterprise information management (i.e., product life cycle management, project management, stakeholder and organization management, CRM, etc.). Goran, Take a look at the External Data extension: http://www.mediawiki.org/wiki/Extension:External_Data It may do what you want. I've been planning on adding other protocols, such as SOAP or XMLRPC, to it. Otherwise, you could probably do iframes or write your own extension. V/r, Ryan Lane ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] flaggedrevs.labs.wikimedia.org Status?
Greetings. Can anyone provide a status update regarding flaggedrevs.labs.wikimedia.org ? In the future perhaps it would be better to import simple english Wikipedia for enwp testing: The lack of templates makes the site look extensively vandalized already. I'm guessing that an alternative english language project would be more useful than a subset of enwp. :) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] how to chang {{SITENAME}}
On Mon, Aug 31, 2009 at 1:01 PM, Happy-melonhappy-me...@live.com wrote: Platonides platoni...@gmail.com wrote in message news:h7gok4$6v...@ger.gmane.org... 1) Copy that list 2) Prepend MediaWiki: namespace 3) Post to Special:Export 4) Automate it: ... 6) Profit!! What's step 5? :-P ???, presumably. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] how to chang {{SITENAME}}
Aryeh Gregor wrote: On Mon, Aug 31, 2009 at 1:01 PM, Happy-melonhappy-me...@live.com wrote: Platonides platoni...@gmail.com wrote in message news:h7gok4$6v...@ger.gmane.org... 1) Copy that list 2) Prepend MediaWiki: namespace 3) Post to Special:Export 4) Automate it: ... 6) Profit!! What's step 5? :-P ???, presumably. Right. :) (see Happy-melon, you _knew_ it!) ...Or perhaps a sysadmin beating those sysops so the servers can profit having a few less cpu usage. ;) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] how to chang {{SITENAME}}
Hi,
In the long-term, wouldn't it be smarter to make some of these stable
and quasi-stable tokens automatically cache in their evaluated state?
We already do, we cache such simplified messages in Mediawiki:
namespace.
For something like {{SITENAME}} there is little reason to be looking
it up every single time the message loads, so why not teach Mediawiki
to pre-evaluate that and similar items before putting it in the
message cache?
There is little reason to keep {{SITENAME}} in Mediawiki: namespace
too :)
Generally, this could be handled by simple bot.
Do note, we end up with other messages, where people want to use
singular/plural for e.g. 'Categories'.
For the rare case that such things do change you'd
need to make sure that the cache does get rebuilt periodically (or
have someway to detect such changes and deliberately refresh the
cache), but such changes are so rare that adding some lag on update
might be acceptable.
Well, Mediawiki: is such cache :) We don't need to change our code at
all then :)
Domas
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] how to chang {{SITENAME}}
I was under the impression we were talking about changing the strings at the individual Wikis, thus a custom message, not in the language files used for all MediaWiki sites... I'm not sure, then, what the problem is Gerard? If we alter a message locally at Wikipedia how does that affect TranslateWiki's efficacy with regards to non-Wikimedia wikis? Mark On 8/31/09, Gerard Meijssen gerard.meijs...@gmail.com wrote: Hoi, Centralised localisation works when the resulting localised messages are usable and useful in all environments. More exceptions to this rule make it seem as if central localisation is not a good idea. There is already one acknowledged exception to the rule; messages that inform about the policies of a local wiki, there is now a second category and they are messages that have parameters like the system name. While I appreciate Domas' search for more performance, I am equally of the opinion that there are other factors to consider. Siebrand wrote that HE is aware of this. This is nice but we support other projects that run MediaWiki and our support should allow for THEY are aware of this. There is also a constant flow of new localised messages and these can include the list of messages that has been shown earlier in this thread. I can imagine that we have some functionality that is part of the update.php that updates these values in the plain vanilla messages. What I am looking for is proper support. The least is proper documentation and it can be expanded to a procedure that allows other wikis to benefit from the knowledge we have gained. My overriding concern is that our language support is not sacrificed at the cost of a few cycles. Even when there are a lot of them. Thanks, GerardM 2009/8/31 Andrew Garrett agarr...@wikimedia.org On 31/08/2009, at 9:27 AM, Gerard Meijssen wrote: Hoi, There are two opposing objectives at play. Performance is one and quality localisation for MediaWiki in all our projects is the second. Just stating that performance trumps our localisation is also very much a nono. These are consequences and they have to be considered. Just breaking the way our localisation works in this way is at least equally unacceptable as poor performance is. You haven't explained exactly what impact this will have on localisation. Perhaps providing concrete disadvantages instead of vague topic areas will make your argument more convincing. -- Andrew Garrett agarr...@wikimedia.org http://werdn.us/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- skype: node.ue ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] RegioWikiCamp - September 25-27, Germany
Hi Brianna and *, Am Montag, 31. August 2009 16:17:24 schrieb Brianna Laugher: It will be from September 25th to 27th. The event is located in Furtwangen the middle of the beautiful Black Forest in Germany. It is organised by the European Regiowiki Society, location host is the faculty of Digital Media of the Furtwangen University of Applied Science. While I will definitely not go there, this is not far from my place. If you need a hub to get there - feel free to contact me. Unfortunately Furtwangen is a very remote place right in the middle of the black forest. While nice during summer in winter they have got the highest suicidal rate at the university there as you're really stuck in a dark valley up there with not many possibilities to do something or to get somewhere. Ways to get there: By train from Switzerland, Germany, France via Basel (national stations for all three national railways) via ICE to Offenburg via RE to Triberg then bus to Furtwangen By aircraft fly to EuroAirport Basel/Freiburg/Mulhouse IATA BSL/MLH/EAP take the swiss exit via Bus line 50 to Basel SBB then via train as described above Alternatively there is also a small airport Baden Airport near Karlsruhe and Baden-Baden, but there is only a bus line to Baden-Baden (where you can also pick an RE to Triberg). -- Regards Manuel Schneider Wikimedia CH - Verein zur Förderung Freien Wissens Wikimedia CH - Association for the advancement of free knowledge www.wikimedia.ch ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
