Re: [Wikitech-l] Increasing default cookie expiry time
Would it be possible for a user to create a small javascript to replace the default cookie by another one which doesn't expires? Helder On Sun, Aug 22, 2010 at 16:20, Max Semenik maxsem.w...@gmail.com wrote: I propose to raise the default ($wgCookieExpiration) at least to 90 days from current 30. This setting was supposed to combat leakage of logged in sessions by making them expire before before an attacker grabs them. However, cookie expiry does little to stop bad guys and annoys good ones: * Once you've left a public PC without clicking on log out, your session is already compromised, even making cookies session-only won't help. * If nobody looks specifically for your session, they can stumble upon it accidentally, while browsing the same site as you did. Lowish expiry time can indeed help lessen this possibility, however with Wikipedia's popularity there's pretty solid chance that someone will visit it from a public teminal within hours, not days. Less popular sites are, on the other hand, protected by smaller possibilities of someone looking for them. * MediaWiki provides no way to adjust preferences without having an account, so advice register and set this or that in 'my preferences' is pretty popular these days. However, the need to log in every month which is mildly annoying for wiki regulars, may have a drastic effect on casual visitors. You told me to register and when I did, I had to relogin after a couple of visits!!1 Taking this all into account, I see no reason to keep the current default. -- Max Semenik ([[User:MaxSem]]) ___ 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] Wikisource books and web 1.0 pages (was: pas de sujet)
On Fri, Aug 13, 2010 at 07:23, Tei oscar.vi...@gmail.com wrote: On 13 August 2010 10:27, Lars Aronsson l...@aronsson.se wrote: ... If we applied this web 2.0 principle to Wikibooks and Wikisource, we wouldn't need to have pages with previous/next links. We could just have smooth, continuous scrolling in one long sequence. Readers could still arrive at a given coordinate (chapter or page), but continue from there in any direction. Examples of such user interfaces for books are Google Books and the Internet Archive online reader. You can link to page 14 like this: http://books.google.com/books?id=Z_ZLMAAJpg=PA14 and then scroll up (to page 13) or down (to page 15). The whole book is never in your browser. New pages are AJAX loaded as they are needed. You are not thinking web here. The web way to solve a problem like easy access to next page or different chapters is to have a next page link or have all the chapters as tabs, or something like that. Make the wiki aware of the structure of a book, and make it render these nextpage link / chapters tabs. Well, to make the wiki aware of the structure of a book is essentially what is requested in bug 15071 [1], which is open since 2008 and blocking 6 other requests which would solve Wikisource/Wikibooks (but non-Wikipedia) specific issues... Helder [1] Wikibooks/Wikisource needs means to associate separate pages with books: https://bugzilla.wikimedia.org/show_bug.cgi?id=15071 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Using LanguageConverter for Portuguese Variants
On Sun, Aug 8, 2010 at 19:19, Roan Kattouw roan.katt...@gmail.com wrote: 2010/8/9 Helder Geovane heldergeov...@gmail.com: Would a prototype wiki be a good place to make it possible for Portuguese community to test the Language Conversion in practice? Sounds good to me personally, although I'll ask some other people to weigh in. I personally like the idea of a world where the standard response to hey we wanna play with this thing and it's all coded up already is sure, lemme set you up with a prototype wiki. We are considering[1][2] the possibility of using the system to handle regional differences in the written Portuguese, but it seems that the editors need more contact with the system before they can decide in favour or agains an efective use of the conversion system at pt.wikipedia. We have made some drafts of the PHP code[3] which is needed to start, and set of possible global conversion rules for some variants[4]. What should we do to have a prototype wiki for this, if that is possible? You should start with getting your code in SVN. If it is or can be written in a way that makes it easy to disable (or if there's some other caveat such as it not doing anything if the conversion tables are empty), it can be committed straight to trunk. If this is not possible, it can be put in a branch, but trunk would really be preferred here, and disableability should be relatively easy to accomplish. Then when it's agreed that this should go on a prototype wiki, Ryan or I will set up the wiki and configure it, and it'll be all yours. Roan Kattouw (Catrope) It seems to be sufficient to add set *$wgDisableLangConversion = true;* for Portuguese wikis while testing at a prototype wiki (there it would have it's default value [*=false]*). Would that be possible? There is also an open bug related to this variable: https://bugzilla.wikimedia.org/show_bug.cgi?id=18958 Helder ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Using LanguageConverter for Portuguese Variants
On Mon, Aug 9, 2010 at 10:31, Roan Kattouw roan.katt...@gmail.com wrote:
2010/8/9 Helder Geovane heldergeov...@gmail.com:
It seems to be sufficient to add set *$wgDisableLangConversion = true;*
for
Portuguese wikis while testing at a prototype wiki (there it would have
it's
default value [*=false]*). Would that be possible?
There is also an open bug related to this variable:
https://bugzilla.wikimedia.org/show_bug.cgi?id=18958
From reading that and the commits involved, it seems
$wgDisableLangConversion doesn't completely disable language
conversion, so that may need to be fixed first.
Roan Kattouw (Catrope)
If no one add rules to the MediaWiki:Conversiontable/pt-xyz tables and do
not add manual markup -{}- in the text, the language converter doesn't do
any conversion (at least it doesn't seems to do). But in this case we still
have the drop down menu at the top of the wiki pages (for variant selection)
and another at Special:Preferences. If we add $wgDisableLangConversion =
true; to LocalSettings.php then both menus are also disabled (they are not
shown), and so the feature seems to be completely disabled.
Does anybody know what would not be disabled with this setting?
Helder
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] On proper sorting using CLDR (was: varchar(255) binary in tables.sql)
Hi!
On Thu, Jun 10, 2010 at 09:40, Domas Mituzas midom.li...@gmail.com wrote:
[snip]
Of course, we can use community driven sortkey hacks for some features ;-)
Domas
Currently it is possible to define the sortkeys using
{{DEFAULTSORT:Sortkey}}
and in lots of places this sortkey coincide with the value of magic
words like {{PAGENAME}} and {{SUBPAGENAME}}, so we don't need to
update them manually. The (annoying) exception is when the value
returned by these magic words starts, for example, with Á and we
would like to have the page sorted in A: in this cases we are forced
to type the sortkey manually.
Would it be possible to have some command for language-dependent word
conversions, like {{collation:langcode|string}}, whose result
should be the given string with character Á changed to A (and so
on for other characters), according to the langcode?
This could be used in situations like
{{DEFAULTSORT: {{collation: pt | {{SUBPAGENAME}} }} }}
or even to create a template {{Simplified sortkey}} with the code above.
What do you think?
Helder
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] js2 extensions / Update ( add-media-wizard, uploadWizard, timed media player )
On Tue, May 18, 2010 at 08:39, Ilmari Karonen nos...@vyznev.net wrote: On 05/18/2010 08:53 AM, Michael Dale wrote: But in general its probably better / easier for end users to just identify their platform and whats not working, since its all code to them anyway. If they are a developer or are going to do something productive with what they are seeking they likely have the code checked out locally and use the debug mode. The problem here is Wikimedia sites. If you leave the debug mode off and serve fully minified scripts on WMF sites, the hundreds if not thousands of people who develop user/site scripts for them will have a very hard time debugging anything that involves interactions with the minified code. If you turn debug mode on permanently, you lose most of the benefit of having a minifier to begin with (Wikimedia being the single biggest user of MediaWiki). Then there's also the problem that the MediaWiki environment on Wikimedia sites can be quite different from a stock install, and duplicating enough of it on a test wiki to be able to reproduce a Wikimedia-specific bug may be quite difficult -- particularly so if you have to do this before you even know where the bug occurs, because you couldn't do any useful debugging due to the code being minified. I'd like to second Aryeh's suggestion to at least tweak the minifier to leave newlines intact (although collapsing multiple consecutive newlines to one would be OK, I guess). That way users could at least set up useful breakpoints and receive error messages that tell more than which file the problem occurred in. I would support a url flag to avoid minification and or avoid script-grouping, as suggested by Michael Dale, or even to have a user preference for enable/disable minification in a more permanent way (so we don't need to change the url on each test: we just disable minification, debug the code and then enable it again) Helder ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wiki syntax for representing that a page is a child of another page?
2010/4/11 Aryeh Gregor
simetrical+wikil...@gmail.comsimetrical%2bwikil...@gmail.com
It might be possible in principle to use some kind of template that
normally renders as a link, but could be persuaded to render as an
inclusion under some conditions. I'm not sure offhand what the best
way to do this would be.
Maybe something like this?
Template:Chapter:
{{#ifeq:{{SUBPAGENAME}}|Print
|{{:{{BASEPAGENAME}}/{{{1}
|[[/{{{1}}}/]]
}}
Table of Contents of the manual, at Manual:
{{Chapter|Title of chapter 1}}
{{Chapter|Title of chapter 2}}
...
which at Manual expands to links:
[[/Title of chapter 1/]]
[[/Title of chapter 2/]]
and at Manual/Print, using
{{:Manual}}
expands to this transclusions:
{{:Manual/Title of chapter 1}}
{{:Manual/Title of chapter 2}}
...
Helder
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wiki syntax for representing that a page is a child of another page?
2010/4/10 Jack Bates ms...@freezone.co.uk Does there exist a recommended wiki syntax for representing that a page is hierarchically a child of another page? I don't want to rename the pages Currently I use this static, hierarchical index of wiki pages which are part of our user manual, http://github.com/jablko/manual/raw/master/manual.html - to compile the pages into this PDF, http://ica-atom.org/manual.pdf Now however, instead of the static index, I want to represent in each page's wiki markup, which pages are logically children of that page Among the reasons for doing this is that, to build the PDF based on the static index, currently I recursively concatenate first the body of a page, followed by each of its children Now I have a case where, instead of concatenating the children after the page body, the children need to be inserted at various positions in the page body So I think I need to indicate these positions with some wiki syntax, and this will make the static index redundant I thought transclusion was a candidate, because pages are recursively transcluded to build the PDF, http://www.mediawiki.org/wiki/Transclusion In the wiki however, I don't actually want to display pages embedded in each other - instead I want links to child pages. This represents enough information about the hierarchical structure to build the PDF My current best candidate is the a href=... rel=down/ link relation, * http://www.imc.org/atom-syntax/mail-archive/msg21260 * http://tools.ietf.org/html/draft-divilly-atom-hierarchy-03 Is there a better syntax for representing, at a particular position in a page, that another page is a child? I seems that this is another instance of the problem mentioned at bug 15073: https://bugzilla.wikimedia.org/show_bug.cgi?id=15073 What is needed is a set of special pages for handling meta-organization of books, but this depends on bug 15071 (Wikibooks custom database schema): https://bugzilla.wikimedia.org/show_bug.cgi?id=15071 https://bugzilla.wikimedia.org/show_bug.cgi?id=15071for which doesn't have any progress since 2008-09-16... Helder ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Inconsistent revision history after importing
Hello!
After importing
http://pt.wikibooks.org/w/index.php?title=Especial%3ARegistotype=importuser=page=Predefini%C3%A7%C3%A3o%3APeqindyear=month=-1uselang=en
a template from pt.wikipedia to pt.wikibooks, the revision history seems to
be inconsistent. According to the history
http://pt.wikibooks.org/w/index.php?title=Predefini%C3%A7%C3%A3o:Peqindaction=historyuselang=en
, the last 3 edits are:
# (cur) (prev) 2009-12-01T08:48:52 Heldergeovane (Talk | contribs) m (324
bytes) (19 edições de w:Predefinição:Peqind: importando o histórico de
contribuições) (undo)
# (cur) (prev) 2009-11-08T19:17:22 Berganus (Talk | contribs) (324 bytes)
(Criou nova página com '__NOTOC__ {| border=0 id=toc style=margin: 0
auto; align=center | '''Índice: ''' A B C D E F G H I [[#J...') (undo)
# (cur) (prev) 2009-07-25T12:30:47 Capmo (Talk | contribs) (673 bytes)
(adicionando {{PAGENAME}}) (undo)
When I select the edits from 2009-07-25 and 2009-11-08 for diffs, I get
this
http://pt.wikibooks.org/w/index.php?title=Predefini%C3%A7%C3%A3o%3APeqindaction=historysubmitdiff=142330oldid=144851uselang=en
where is is shown (18 intermediate revisions not shown). Besides this,
when clicking at Newer edit →, we go to an edit from 2004
http://pt.wikibooks.org/w/index.php?title=Predefini%C3%A7%C3%A3o:Peqinddiff=nextoldid=142330uselang=en
What is wrong?
Helder
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Language variants
2009/9/9 Tim Starling tstarl...@wikimedia.org The language variant system that we have could easily convert between US and UK English. In fact it already does convert between a language pair with a far more complex relationship, that is Simplified and Traditional Chinese. The language conversion system is very simple, it's just a table of translated pairs, where the longest match takes precedence. The translation table in one direction (e.g. UK - US) can be different to the table in the other direction (US - UK). You would not list ize - ise, you would list every word in the dictionary with an -ize ending that can be translated to -ise without controversy. The current software could handle 50k pairs or so without serious performance problems, and it could be extended and optimised to allow millions of pairs if there was a need for that. Hello again! What would be needed in order to use pages like MediaWiki:Conversiontable/pt and MediaWiki:Conversiontable/pt-br at the wikimedia projects in Portuguese for the conversion? Is it easy to have the language conversion enabled? Could we gradually create the conversion tables? Sorry for so many questions... Helder ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Language variants
Hello! I think the code is these: http://svn.wikimedia.org/doc/LanguageConverter_8php-source.html#l00018 http://svn.wikimedia.org/doc/LanguageZh_8php-source.html#l9 and a comment at http://svn.wikimedia.org/doc/LanguageConverter_8php-source.html#l00258 says: 00271 /* we convert everything except: 00272 1. html markups (anything between and ) 00273 2. html entities 00274 3. place holders created by the parser 00275 */ So, I don't think it will convert span style=color:red. But I'm not sure, because I'm still learning php... By the way, I can't understand Chinese, but (after using an on-line translator) I think the page they have for documenting the system is this: http://zh.wikipedia.org/wiki/Help:%E4%B8%AD%E6%96%87%E7%BB%B4%E5%9F%BA%E7%99%BE%E7%A7%91%E7%9A%84%E7%B9%81%E7%AE%80%E5%A4%84%E7%90%86 Helder 2009/9/10 Aryeh Gregor simetrical+wikil...@gmail.com On Thu, Sep 10, 2009 at 6:44 PM, Roan Kattouw roan.katt...@gmail.com wrote: Seems I'm not the only one who had a completely wrong idea about how variants work. We definitely need more documentation and fame for this system, so its potential doesn't go to waste. I theoretically knew that it was just a string-replace system, but it didn't occur to me that it would be useful for more than transliteration. It makes sense now that Tim pointed that out. How would it handle word breaks, though? It would just ignore them, so color - colour also changes uncolored - uncoloured? What about things like HTML id's or even attribute/property names (span style=color:red)? I'm sure I could dig through the code to find the answers to these, but actually I'm not even sure offhand where the code *is*. ___ 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] Language variants
Nice! ;-)
Do you think tables like these
http://pt.wiktionary.org/wiki/Wikcionário:Versões da língua portuguesa/Tabela
http://pt.wikipedia.org/wiki/Wikipedia:Versões da língua portuguesa/tabela
could be a start point to a similar conversion system for pt - pt-br?
Meanwhile, I was also trying to adapt the Template:LangSwitch from
Wikimedia Commons
(http://commons.wikimedia.org/wiki/Template:LangSwitch), in order to
be able to use the template syntax like this:
{{Language variations| pt = word 1| pt-br = word 2}}
For this, I've created two pages:
* MediaWiki:Lang, with 'pt'
* MediaWiki:Lang/pt-br, with 'pt-br'
and the template code is essentially:
{{#switch:{{int:Lang}}
|pt-br={{{pt-br|}}}
|pt
|#default={{{pt|}}}
}}
But I wasn't able to create a param default in order we could set
which of the variants will be shown by default for anonymous users. It
would be good if we could use {{Language variations| default = pt-br |
pt = word 1| pt-br = word 2}} to get:
(a) word 2, for annonimous users;
(b) word 1, for logged users which choose 'pt' in their preferences;
(c) word 2, for logged users which choose 'pt-br' in their preferences;
The option (a) would be necessary if we don't want to change an
existing text from 'pt-br' to 'pt' (for anonymous users) just because
we want the logged users to be able to choose the content variant.
Is there any way of detect if the reader is logged in with something
in the style {{#if: what? | foo| bar}}?
(the problem with {{int:Lang}} is that for anonymous users and for
users who choose 'pt' the result is the same: 'pt', so I can't
distinguish these two cases at the template...)
Anyway, I think it would be better to have some kind of an automatized
conversion system, even if it doesn't convert all cases ( at least for
the words in the tables above it would be useful)
Thank you for all,
Helder
2009/9/9 Tim Starling tstarl...@wikimedia.org:
Roan Kattouw wrote:
That's the alphabet variant thing I mentioned earlier. If the majority
of the differences between pt and pt-br can be summed up with simple
rules that a computer can handle, we might be able to work something
out. However, that's usually not the case; I don't know Portugese, but
I do know that handling even simple differences between en-us and
en-gb is too complex already: a system that would successfully convert
'realise' to 'realize' may also try to wrongfully convert 'disguise'.
I don't know why you're writing this nonsense, you obviously haven't
looked at the code at all.
The language variant system that we have could easily convert between
US and UK English. In fact it already does convert between a language
pair with a far more complex relationship, that is Simplified and
Traditional Chinese.
The language conversion system is very simple, it's just a table of
translated pairs, where the longest match takes precedence. The
translation table in one direction (e.g. UK - US) can be different to
the table in the other direction (US - UK). You would not list ize
- ise, you would list every word in the dictionary with an -ize
ending that can be translated to -ise without controversy. The current
software could handle 50k pairs or so without serious performance
problems, and it could be extended and optimised to allow millions of
pairs if there was a need for that.
It's possible to handle any pair of languages which are separated only
by vocabulary, and transliteration or spelling. It's only differences
in grammar, such as word order, that would give it trouble.
-- Tim Starling
___
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
[Wikitech-l] SQL
Hello!
I was looking at this code
http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/intersection/DynamicPageList.php?view=markup
and trying to figure out how to change this piece of code
if ('lastedit' == $sOrderMethod)
$sSqlWhere .= ' ORDER BY page_touched ';
else
$sSqlWhere .= ' ORDER BY c1.cl_timestamp ';
$sSqlWhere .= $sSqlOrder;
in such way that the extension could order the list alphabetically.
I imagine it would be a simple change, like this:
switch ($sOrderMethod)
{
case 'lastedit':
$sSqlWhere .= ' ORDER BY page_touched ';
break;
case 'alphabetical':
$sSqlWhere .= ' ORDER BY WHAT? ';
break;
case 'categoryadd':
default:
$sSqlWhere .= ' ORDER BY c1.cl_timestamp ';
break;
}
But I don't know what to use in the SQL instead of the WHAT?.
Does anybody knows what should it be?
Thanks in advance!
Helder
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Preload doesn't work at MediaWiki namespace?
Hi! When we go to links such as: http://pt.wikibooks.org/w/index.php?action=editpreload=Project:Abouttitle=test http://pt.wikibooks.org/w/index.php?action=editpreload=Project:Abouttitle=MediaWiki:test we note that both testand MediaWiki:test doesn't exist. But using the preload parameter for the first page we get the text #REDIRECT [[wikibooks:Sobre]] preloaded although for the second we don't. Is this the expected behavior for MediaWiki namespace? Helder ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] How sort key works?
Hi! Some time ago I was categorizing some pages at pt.wikibooks and I found the following curious situation: I've used the code [[Category:Test|*]] in these pages: http://pt.wikibooks.org/w/index.php?title=User:Heldergeovane/*Bi* ologia_celular/Índiceaction=edithttp://pt.wikibooks.org/w/index.php?title=User:Heldergeovane/Biologia_celular/%C3%8Dndiceaction=edit http://pt.wikibooks.org/w/index.php?title=User:Heldergeovane/*Bo* nsai_no_Brasil:_Índiceaction=edithttp://pt.wikibooks.org/w/index.php?title=User:Heldergeovane/Bonsai_no_Brasil:_%C3%8Dndiceaction=edit So, we expect: * Both pages should appear at Category:Test under *, and * User:Heldergeovane/B*i*ologia_celular/Índice should be before User:Heldergeovane/B*o*nsai_no_Brasil:_Índice (since i comes first than o). However, what we found at http://pt.wikibooks.org/w/index.php?title=Category:Test is the reverse order. 1) What is the criteria for ordering the pages when the sort key of two pages are the same? 2) Is there anything wrong with the ordering of the two pages above? Helder ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How sort key works?
2009/8/10 Aryeh Gregor
simetrical+wikil...@gmail.comsimetrical%2bwikil...@gmail.com
We could break ties by appending the page title to custom sort keys,
if this is a problem.
I think it would be good! =)
(We actually have manually used *{{PAGENAME}} for a while... =S)
Helder
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Interwiki linking
2009/7/10 Platonides platoni...@gmail.com:
Seems you don't know the pipe trick. Type [[Lang:Project:Page|]] and it
will be automatically expanded to [[Lang:Project:Page|Page]] on save.
Thank you Platonides!
I really didn't know this trick.
So, wouldn't be better to avoid duplication of long texts making
[[Lang:Project:Page|]] remains unexpanded on save (but still pointing
to Lang:Project:Page and showing the text Page)?
Note that this is the behavior of [[/subpage/]] that generates the
same output as [[/subpage|subpage]] but not the same wikitext (and
this makes the wikicode more clear, so it is desirable).
This is more likely to be expected by the users:
http://en.wikipedia.org/w/index.php?title=Help_talk:Pipe_trickoldid=197853113#You_live_and_learn.21
I mean, the wikitext is not supposed to change after we saves it...
(unless I use {{subst:...}})
Also, since the wikicode changes, it is _not_ likely the new wiki
users will found the syntax [[Foo|]] in the pages, so the only way
they could know the *trick* is to find the Help page about it. If the
[[Foo|]] were saved as is, this would be part of the syntax , not a
trick...
(a related link:
http://www.mediawiki.org/w/index.php?title=Manual_talk:Interwikioldid=262478#Hiding_the_interwiki_name.3F)
Helder
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] URLs that aren't cool...
2009/7/28 Brion Vibber br...@wikimedia.org: A nearer-term help would be to go ahead and implement what we talked about a billion years ago but never got around to -- a decent did you mean X? message to display when you go to an empty page but there's something similar nearby. If it's at least trivial to click through from [[New york city]] to [[New York City]], that's better than having to search for it anew. I think this would be really good to implement this, since it also help us when creating and following interwiki links (see also the point 3 I was talking here: http://lists.wikimedia.org/pipermail/wikitech-l/2009-July/044007.html) Helder ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Formatting links according to the wikiproject
2009/7/6, Aryeh Gregor simetrical+wikil...@gmail.com:
On Mon, Jul 6, 2009 at 4:00 PM, Ahmad Sherifahmad.m.she...@gmail.com
wrote:
We make it strict to #bodyContent then :)
#bodyContent a.extiw[href*=.wikipedia.org/w] { ... }
[[b:Look at this strange Wikibooks page name! .wikipedia.org/what a
strange name]]
I'm not saying it's likely, but false positives are possible, and that
should be kept in mind.
___
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
[Wikitech-l] Interwiki linking
Hi!
Currently, when an editor create at some wikiproject an interwiki link
using [[Lang:Project:Page|Text]] the readers get a link to a Page of
Project (in the Lang language) and Text is shown in the link.
Besides this:
1) The title attribute of the a element is equals to (something
not very intuitive for readers): [[Lang:Project:Page]].
2) If Text is equals to Page, and we want/need to show only the
Page text, it is needed to use [[Lang:Project:Page|Page]] (although
for local links [[A very long page name|A very long page name]] can be
abbreviated to [[A very long page name]])
3) When the target page doesn't exists, the reader go to a page
showing the system message MediaWiki:Noarticletext.
I have some considerations:
1) What if the title attribute could be something more descriptive
like Search at Project (in Lang) for pages related to 'Page'?
The exact text could be translated for each language (or accordingly
to the target project), in such way that Page, the real name of
Project (Wikipedia instead of w, etc...) and the real name of
Language could be variables $1, $2, etc...;
2) For example, if in a page of a wikibook we need to use various
links to wiktionary and Wikinews, we would have to duplicate the total
size of each link (the number of characters to be typed) just to have
only the Page text shown. This is also bad for summaries, where we
can not use a long text. Perhaps another _short_ syntax could be used
to get Page instead of Lang:Project:Page without having to type
(the possible very long) Page two times (maybe the prefixed colon
[[:Lang:Project:Page]]?), in order to facilitate the integration
between the content of the projects;
3)Compare the following:
3.1) http://en.wikipedia.org/wiki/Education_collaboration
3.2) http://en.wikipedia.org/wiki/Special:Search/education_collaboration
and note that:
3.3) If the article Education collaboration exists, the two links
carries the reader to it.
3.4) If not, 3.1 could be frustrating for a reader that has clicked in
the link expecting to get (immediately) more information (remember,
not every reader wants to became an collaborator, and that is fine)
related to what he was reading. There are various reasons to the
reader get the Noarticletext message, as in 3.1:
3.4.1) If the editor that created the interwiki link wrongly typed
colaboration is his edit, the reader will get:
http://en.wikipedia.org/wiki/Education_colaboration
Note that in this case, something like 3.2 is better than 3.1, for the reader:
http://en.wikipedia.org/wiki/Special:Search/education_colaboration
I mean, he gets a message Did you mean: education collaboration and
still have some related links shown in the search results. While the
reader could prefer to go exactly to an Wikipedia article about
education and collaboration, and because of a typo (that could take a
long time to be corrected) he didn't, he could be happy to found
another article in the results (maybe one more interesting than the
article suggested by the editor who created the wrong link).
3.4.2) When writing, the editor simply imagine There could be
something about this at Wikipedia, and some news at Wikinews, let me
create [[w:whis|this]] and [[n:whis|this]] links... but instead of
search at Wikipedia and Wikinews for the exact text to put in each
link, he prefers to do a link using keywords like education and/or
collaboration. But these [interwiki] links are not red [interwiki]
links, so they could stay exactly as they were created for a long
time, and bother some readers in the meantime...
3.4.3) Some editor do a search for Education And Collaboration at
Wikipedia and find a page (say, Education and collaboration). So he
creates a link (by copy and paste) pointing to Education And
Collaboration that is not at Wikipedia, because of the A and C.
Then, although the search engine is case insensitive and the editor
has found the article when he _searched_ for it at Wikipedia, the
reader that will _click_ in the link will not go directly to the
article.
3.4.4 And so on...
The enhancement of these features can be achieved easily by means of a
template whit code similar to this:
Begin of Template:Wikt
[[wikt:Special:Search/{{{1}}}|span title=Search at Wiktionary the
meaning of '{{{1}}}'{{{2|{{{1}}/span]]
End of Template:Wikt
then, we can use:
* {{wikt|word|text}} instead of [[wikt:word|text]]
* {{wikt|word}} instead of [[wikt:word|word]]
and each of the resulting links points to
* http://en.wikitionary.org/wiki/Special:Search/word
instead of
* http://en.wikitionary.org/wiki/word
Note that with Special:Search/ links, the reader still gets a red
link for easily create the page (if he wants to became an editor)
when no result is found.
I would like to hear from you if, besides the need of use a template
syntax just for create links, is there any other (technical/practical)
disadvantages (advantages?) of using such behavior in the interwiki
links (with or without using templates), and
