ESP Wiki is looking for moderators and active contributors!

User talk:Steelpillow

info tidying

Hi. Glad to hear you like tidying info. That's a bit of a hobby of mine too, on Wikipedia. Ciaran 17:42, 25 May 2009 (EDT)

Discussion on per-country articles moved to Discuss this wiki. Steelpillow 04:22, 26 May 2009 (EDT)

I've moved Discuss this wiki to Talk:Discuss this wiki, just letting you know in case that causes any glitches. Ciaran 20:47, 5 June 2009 (EDT)

New front page style

I'm done fiddling with Main Page for today. If each box sticks to having 5 entries in their list, I think that layout makes slightly better use of space. The links in the "overview pages" box aren't great, but I'm going to make some new pages that will suit that box. Ciaran 07:14, 8 August 2009 (EDT)

Simple categories

Could you comment on my suggestion at Talk:Discuss this wiki#Category_suggestions? Ciaran 16:45, 10 August 2009 (EDT)

Notification of new categories

When I make new categories, would it be helpful if I add them to a list somewhere? Maybe en.swpat.org/Categories so their chronological order would be visible, I could add a comment about the purpose/plans, and you (and others, now or future) could see what the latest categories are which might fit into the category hierarchy. Useful? (in the mean time, the Special:Uncategorizedcategories is the closest thing to doing that already) Ciaran 10:04, 20 August 2009 (EDT)

I think a page with some sort of topic ordering/hierarchical breakdown of the main categories would be useful, but I'm not sure of the best way to implement it. Some possibilities:
  • Text lists and sub-lists. Easy to maintain, but limited to simple hierarchies.
  • ASCII art (just start each line with a space character) provides a more graphical way to show trees. Also somewhat limited and a bit basic in appearance.
  • Family Tree templates from Wikipedia. More flexible and stylish, but effectively have their own coding language and would need one or more software extensions to function. Limited to (I think) 80 entries, which we might hit one day.
  • Graphic diagrams, preferably SVG vector graphics. Would need image uploading enabled on ESP Wiki, and basic skills with vector graphics software such as Inkscape.
We could start with a plain text list and then see how far we get with the other options.
Personally I don't like sub-pages if they can be avoided. I'd suggest the page goes in the ESP Wiki: namespace, say at ESP Wiki:Category tree.
steelpillow 14:53, 20 August 2009 (EDT)
For the breakdown of the main categories, could this be done on Finding things on en.swpat.org? I've been meaning to list the main categories there anyway, and if we can integrate administrative things into pages that users use, they'll be more likely to be maintained in the long run. (but that doesn't solve the original question of where I should make a note when I make a new category ...I'm still thinking about that)
I agree about subpages. I was thinking of : when I typed /. Ciaran 17:30, 20 August 2009 (EDT)

judges comment deletion

Hope you don't mind that I undid your revert on i4i vs. MS.[1]

The reason is that I recently linked to that article from a patently-o.com blog comment, so there's a good chance that that new visitor is clueful. If they're not familiar with wiki culture (at least on MediaWiki sites), they mightn't guess that us humans do actually read edit summaries :-) Now that I think of it, it was a jury trial, so the judge wasn't called to understand the patent or not, so that editor was right to delete it.

There's an interesting article at guardian.co.uk / article which discusses a study. The journalist makes some points that I don't agree with (I don't think Wikipedia's underlying problem is a deletionist vs. inclusionist war), but what I do take from the article is that as reverting of first-time and occasional contributors has increased, the rate of growth of new contributors has started to contract. So I always tend toward keeping non-vandalism edits from new contributors, even if they're moderately negative (for a week or a month anyway). Ciaran 20:59, 26 August 2009 (EDT)

No problem. I read a similar write-up on the research in the New Scientist. It came across as very shallow - no understanding of the natural lifecycle of a wiki and its community. For example once the main contributors have had their say, the articles will by now be of a high standard making further improvement difficult and there are bound to be fewer new arrivals with anything useful to add. The increased reversion rate is a direct result of this fall off in expansion, not a cause. I agree about keeping non-vandalism edits though. In the present case, the deletion appeared arbitrary and I did suspect vandalism. Happy to be corrected. steelpillow 17:09, 27 August 2009 (EDT)

New language templates and categories

I made some templates for marking links as being in a language other than English, as used here:

I've tried to make the templates as useful and as automatic as possible. Here's an example template, plus the two templates that they're each based on:

The particular way they're set up is the result of lots of trial and error rather than delicate planning, so if you think there's something illogical in their construction, feel free (as always) to make whatever changes you think are worthwhile.

I've used the English name of each language for the template text. This is partly because Wikipedia initially used the ISO code and later switched to the English name, and partly because from my own experience the ISO codes aren't meaningful to many people. Also, like Wikipedia, I've left the template texts as simple text, not links. Making them links would probably over-complicate the links sections of pages.

Each template makes a category which should be useful for general navigation. E.g. if you're looking for info on a consultation, or a ruling, or a campaign, and all you remember is that a core document was in German, then this category might be useful (when it's more filled-out): Category:Pages linking to documents in German.

Ciaran 01:33, 11 January 2010 (UTC)

The mechanism looks OK. There is a convention for putting template documentation on the sub-page Template:Template_name/doc, but it needs a few templates importing to create the infrastructure, and I can't see any point right now. Your system is good enough.
One thought, would it be better to show (en francais), (in Deutsch), etc. rather than (in French), (in German), etc.?
steelpillow 10:37, 11 January 2010 (UTC)
One problem is that if a reader saw something in Hebrew, Bulgarian, or Greek, they won't know that it's warning them about the pointlessness of following that link. A more practical problem is that I don't know how to write "in Hebrew" in Hebrew :-) Ciaran 15:09, 13 January 2010 (UTC)

Adding Google translations to language links

I'm changing the language warning templates to automatically add links to automatic translations (just Google for now, others to follow).

I don't like the user complexity I'm creating (the syntax that contributors will have to follow), and I'm not a fan of making functionality that depends on Google, but when I thought about how useful this would be for languages like Japanese, I decided it has to be done. Here's the first implementation: Germany#FFII_pages. Ciaran 16:56, 13 January 2010 (UTC)

First problem: For the European Patent Convention, the English, French, and German texts are all linked from the article. I would like the German text to have a warning, and I would like that page to be automatically put in Category:Pages linking to documents in German, but that link obviously shouldn't have automatic translations added. Do we need two templates {{warn de}} and {{link de|URL|TEXT}}? Or is there a way for the template to display (in German) if no parameters are passed to it, and to display that text plus the link plus the automatic translations if there are parameters? Ciaran 17:02, 13 January 2010 (UTC)

Thinking aloud here. If Google links are optional, there are several possible approaches:

Option 1

Just have two different templates for the user to choose - say Template:Lang de and Template:Lang de+g. These both invoke Template:language template template, but one inserts the google trans link while the other does not.

Option 2

To avoid the user having to choose templates, add an extra parameter to Template:Lang de. For example the user would enter something like: 

{{lang de|full_url|visible_text|next_template}}

It then goes something like this:

  1. Template:Lang de passes all the parameters, plus its German-specific stuff, to say Template:Intermediate.
  2. Template:Intermediate passes the German stuff and the two main parameters to Template:next_template, as named by the user's final parameter. If the next_template parameter is not passed, then Next_template defaults to say Notrans.
  3. We have two such "next" templates, say Template:Gootrans and Template:Notrans - they both invoke Template:language template template, but one inserts the google trans link while the other does not.
Option 3

To avoid this cascade of templates, individual templates may be made more programmatic and powerful. This needs the programmatic features adding to the wiki software, for example by installing the ParserFunctions extension. This reduces the template headcount, but makes the remaining template(s) more esoteric.

Whatever you do, the user still has to enter all the values in a single template call.

It would be cool to set up option 2 to pass the language as well, so that every option has the same format. Due to the number of parameters, they need names rather than numbers. So the user enters something like: 

{{link|lang=de|url=http://www.full_url_here|text=visible_text_here|translate=no}}

or 

{{link
|lang=de
|url=http://www.full_url_here
|text=visible_text_here
|translate=no
}}

The template cascade can then be revised/extended to process it.

However, if a given language is not provided for, the template will barf and the user may not know why. At least with individual language templates the template link will show red so the user can see it doesn't exist yet.

Phew! Any thoughts? steelpillow 18:11, 13 January 2010 (UTC)

I think you've covered all the options! thanks.
I'll get ParserFunctions installed. (I thought it was installed already but it's not - that must be why citations like cite_web aren't working.)
I think this {{link|lang=de|url=http://www.full_url_here|text=visible_text_here|translate=no}} can be simplified to this: {{link|de}}, which in real use would be {{lang|de}} [http://www.full_url_here visible_text_here] - if Template:lang doesn't receive a URL, then it would just spit out the relevant language name: (in German). If it does receive a URL, then do all the translation stuff. The logic would be a little simpler and it looks less jargonish for new contributors.
One complication for the Template:Lang idea is that for some languages we'll have no translation, for others we'll have Google, and for others we'll have Google and, say, Babelfish. ...for some reason, this sounded messy at first, but now that I think about it, putting the clauses for 20 languages into one template is no more complicated or messy than having 20 single-clause templates.
I presume ParserFunctions will let us take ISO 2-character language codes and use that to pull the English name of the language from a list and to grab some true/false values for whether or not to do translations with Google, Babelfish, etc. depending on the language.
While waiting for ParserFunctions to be installed, I'll work on a (in German) template which always uses Google, and only Google. The downside is a few superfluous translations being offered, but at least it's going in the right direction. Ciaran 19:46, 13 January 2010 (UTC)
Another minor thing to keep in mind: the template has to be useable for documents that Google can't translate, like images, slide shows, and it doesn't seem to handel pdfs either. Ciaran 20:23, 13 January 2010 (UTC)
Another thing: templates seem to barf when there's a question mark in a parameter passed to them: Argentina :-/ I'll fix that tomorrow morning. Ciaran 20:33, 13 January 2010 (UTC)
My mistake, it's not the question mark but the equals sign and the pipe. I found the documentation about this, but there are no solutions that don't burden the user: http://meta.wikimedia.org/wiki/Help:Template#Restrictions_on_parameter_values
This leaves us two options. The first is to to require that the user replaces equals signs with = and pipes with &124;.
Of course, that's totally non-intuitive, but, for the equals sign maybe we can teach the user quickly by blurting out a big red error message if that parameter doesn't start with http/https/ftp, then we can assume the first part has been read as the name of the parameter because there's an equals sign. The "big red error message" is how Wikipedia teaches contributors to close their <ref> tags, and it seems to work. Detecting a pipe-caused error is harder. By displaying a big red error whenever there're too many parameters and ask the user if there might be a pipe in the URL, maybe that will catch it.
The second option, is to name the parameters, like you suggest {{land de|url=URL|text=TEXT}}. But this only solves the equals sign problem, not the pipe.
I've checked just now on wikipedia and the pipe problem exists there too. Having added maybe hundreds of citations, I've never encountered that error - maybe we can assume that pipes in URLs are really rare. Ciaran 05:55, 14 January 2010 (UTC)
SUMMARY: sorry about the running commentary :-) What I've decided to do is to make a set of can't-go-wrong templates {{lang de}} that just spit out (in German), and a set of tranlator templates {{trans de|url=URL|title=TEXT}} which do complex stuff (and which barf on getting a pipe in the URL, but that's life, I'll try to document it in a findable place). And when ParserFunctions is installed, we can look into it again. Thanks for the comments above. If you've comments on this part, they're very welcome, but they might be too late since I'm going to go ahead now while I have the mental energy :-) Ciaran 06:43, 14 January 2010 (UTC)
All done now, I think. For this pre-ParserFunctions phase anyway. Ciaran 10:17, 14 January 2010 (UTC)
Wow, all that while I blinked. The Pipe is not a reserved character for urls, but it is pretty rare. I think all we can do is to document the issue, and suggest that users who can't fathom it add the broken link template. steelpillow 10:44, 14 January 2010 (UTC)

collapsible boxes need some css

To look good, they need some CSS stuff but I haven't found that yet. Shouldn't be difficult. Ciaran 21:59, 1 March 2010 (UTC)

Administrator

I found how to give you rights to delete and protect pages, and to do rollbacks and maybe a few other things: you're now in the "Administrator" group, aka "sys-ops". I think you can block users now too. Anyway, use these things as you like. Ciaran 19:03, 28 May 2010 (UTC)

Wow, thanks! Don't expect fireworks - I'll take what little time I have to read up on things to begin with, I'd hate to mess up! steelpillow 18:54, 30 May 2010 (UTC)
I'd been keeping an look out for how to enable those things for a while now. IIRC, for all the new things you can do, you can also undo them ...with the exception of hurt feelings if they accidentally clobber a well-intentioned contributor :-) I remember being surprised by how rollback works, but it's nothing a few tests in a sandbox won't solve. With any luck ParserFunctions will finally get installed one of these days (not sure what the hold up is), then there'll be a lot of new stuff to play with. Ciaran 00:15, 1 June 2010 (UTC)

Just wondering, can you now edit pages such as MediaWiki:Common.css?

I've asked for CategoryTree and re-asked for ParserFunctions to get installed. Ciaran 19:21, 3 June 2010 (UTC)

Yes I can. I'll run any changes by you first! steelpillow 21:08, 3 June 2010 (UTC)
The style will always be in (slow) flux, since I'm trying to develop a common style for endsoftwarepatents.org, news.swpat.org, and this site, so I might overwrite changes you make (apologies in advance), but in general it's safe to just go for it. Everything's undo-able. Ciaran 19:18, 4 June 2010 (UTC)

We now have ParserFunctions and CatergoryTree installed!

I'm going to look into getting Cite_web working. Ciaran 19:18, 4 June 2010 (UTC)

Category Trees

Hmm, does CatergoryTree work for you? It doesn't seem to work as expected for me. I don't see any of the [+] or [x] clickies for the AJAX funcationality. Here's more what I expected: Wikipedia's cat tree for "Earth". I'll look around for config options and ask the sysadmins. Ciaran 19:44, 4 June 2010 (UTC)

Not working as it should. Some functionality is definitely there. I guess http://www.mediawiki.org/wiki/Extension:CategoryTree is the place to start. steelpillow 20:16, 4 June 2010 (UTC)
The sysadmins fixed it:

http://en.swpat.org/wiki?title=Special%3ACategoryTree&target=countries+and+regions&mode=categories&dotree=Show+tree

Ciaran 00:49, 8 June 2010 (UTC)
That's great. I notice it doesn't give the full depth of sub-categories in one place, so do you think my manual Category tree is still worth maintaining or not? steelpillow 19:49, 8 June 2010 (UTC)
Ah, looks like the same bug as before. On Wikipedia (cat-tree), the tree keeps expanding. I'll tell the sysadmins that that their fix for the toplevel has to be applied to subtrees too.
What's next'd be your call. As the number of pages grows (and it's been growing pretty [http://ciaran.compsoc.com/swpat-pages.svg linearly for >1 year now), we're going to need to give readers more and more help to find what they're looking for. Does the manual tree have advantages over the AJAX tree (when it's fully working)? Could the manual tree from now own be made from expanding all the branches of CategoryTree and running the output through a script?
(I've no current intentions for CategoryTree - I just got it install so you could see if it's useful.) Ciaran 20:18, 8 June 2010 (UTC)

The manual tree still has a few advantages:

  • The user doesn't need to enter "Top level category" in a search bar. I wonder if this can be created as a default value for the AJAX Category: field?
  • The levels have different text styles. I'm guessing this would need a sophisticated hack at the AJAX to do there.
  • It can be transcluded in other pages - this would be good if it could be made collapsible, but the non-javascript user would be stuck with the whole huge tree.
  • It's still the only way non-javascript users can see the whole hierarchy. However, as the tree grows the view becomes too long and complex to absorb and its value diminishes.

Its main disadvantages are of course time overhead and human error.

On balance, I think that maintaining it will not be worth the effort. Better to put that into other navigation tools.

steelpillow 11:09, 9 June 2010 (UTC) [updated steelpillow 11:12, 9 June 2010 (UTC)]

Special:CategoryTree now fully working

Hey,

Hope everything's going well for you.

The CategoryTree problem is finally fixed (sorry it took so long). It was a MediaWiki bug and got fixed when we did an upgrade.

Are there any specifics on how to do the transition to CategoryTree, or do we just de-link Category tree from Finding things on en.swpat.org and put links in prominent places to [2] ?

I've put it in the navigation box on the left of the page for now (via MediaWiki:Sidebar).

Was there more work to be done to make sure all categories are in the tree and everything's findable via top_level_category? Or were there other organisational restructurings we were discussing? Ciaran 09:49, 15 November 2010 (EST)

Retrieved from "https://wiki.endsoftwarepatents.org/w/index.php?title=User_talk:Steelpillow&oldid=29361"