2011/8/20 Ashar Voultoiz <hashar+wmf(a)free.fr> Afaik that's not true. Those 3 steps are only needed if you need internationalization, in which case it makes sense to have multiple pages. If you just want a simple link and link name you can just use: *Some article|Click here! In which case the magic sidebar code will indeed look if there's a message by that name, but if there is not it will output that text raw. So there is no requirement to create two separate messages. 2011/8/20 Ashar Voultoiz <hashar+wmf(a)free.fr> Yes, definitely! This has been brought up a few times before and I think it's an obvious thing to do. It was brought up as a project for GSoC: Regarding the maintainability and automation from one wiki to another, I a shared table solves that easily if it needs to be synchronized across a wiki farm. And if only needed once or twice (export / import) one can use database table export/import from phpMyAdmin even. That's no different from any other database (ie. interwiki). The Sidebar feature could have an API module or SpecialPage-action that allows exporting to, for example, JSON. Which an then be imported on another wiki through the API or a SpecialPage-action. (eg. api.php?action=sidebar&op=export or Special:Sidebar/export). -- Krinkle

Why on earth would we call it the snidebar? -Chad On Aug 28, 2011 9:45 PM, <jidanni(a)jidanni.org> wrote:

- Horrible syntax becomes even more horrid - i18n nearly goes out the window - Accesskeys go out the window - External links don't work the same in the sidebar as they do in WikiText - Sidebar markup differs between skins... because rightfully that's the skin's decision to make on how it's laid out and styled - The user's ability to reposition the toolbox and language box disappears, search to if you're using monobook Please spare the ml all these unhelpful comments you keep making. ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] On 11-08-28 06:44 PM, jidanni(a)jidanni.org wrote:

<div id="p-navigation" class="portal collapsed"> <h5>{{int:navigation}}</h5> <div class="body"> {{#ifeq:{{int:mainpage}}|-|| * [[{{int:mainpage}}|{{int:mainpage-description}}]]}} * [[Special:NewPages|{{int:newpages}}]] * [[Special:Categories|{{int:categories}}]] {{#ifeq:{{int:recentchanges-url}}|-|| * [[{{int:recentchanges-url}}|{{int:recentchanges}}]]}} {{#ifeq:{{int:randompage-url}}|-|| * [[{{int:randompage-url}}|{{int:randompage}}]]}} </div> And: - Getting those #ifeq's right might actually require some extra <nowiki/>s - Accesskey config still goes out the window - External links still don't work the same way - The markup isn't portable to all skins - The SEARCH/TOOLBOX/LANGUAGES repositioning ability disappear. - We end up using a hugely complex parser just to parse something that is actually relatively simple ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] On 11-08-30 04:59 PM, jidanni(a)jidanni.org wrote:

~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] On 11-08-23 02:40 PM, Platonides wrote: How about we re-educate them on how to use the hook we have to introduce new wikitext blocks to the sidebar? Or perhaps something outside of mw:sidebar that lets us say to embed things like MediaWiki:Sidebar/foo's WikiText into the sidebar. Though, if someone is already modifying core, then telling them to put a hook into their LocalSettings.php isn't any worse since they already need php access to do the hack in the first place. Just saying that it's using transclusion syntax, but it doesn't behave like transclusion syntax. It doesn't come from Template: by default, in fact you can't even tell it to come from anywhere but a message, and yes of course, if you tried to use parameters it wouldn't work. I'm trying to expand support from our limited support for: MediaWiki:Sidebar with the format: * section ** link|text To support additional navigation such as: A single level header with the format: * link|text * link|text A recursive navigation menu with the format: * link|text ** link|text *** link|text **** link|text *** link|text And any other navigation that a skin wants to insert. The fact that we ONLY support MediaWiki:Sidebar and if a skin designer wants ANY other type of navigation they either have to hardcode it or completely re-implement navigation parsing in their skin is a flawed limitation in our skin system I'm trying to fix. I implemented a NavigationMessageParser that can parse MediaWiki:Sidebar's syntax and also the other variances like infinite depth, levels that support links and levels that don't, etc... But right now I can't see {{msgname}} being worked into that parser without a huge hack. To be fair though. A comment in the commit, and also one of the replies here have both brought up how flawed MediaWiki:Sidebar is from the start and the whole idea of replacing it with a special page interface. I do admit there that such a thing could handle wikitext blocks much better than any MediaWiki:Sidebar syntax we could come up with or any hook. -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]