All posts by Dessamator

<p>I just remembered a thread about a difficulty related to theming. Currently, it isn't possible to define conditional theming without using a hack of a "middleman" template as described in : </p><p>http://portability.wikia.com/wiki/Thread:2361 </p><p>While  this need may be possibly rare, the fact that n-th type must be used to style specific elements has come up over and over and over again.  One possibility is an easier way to make themes conditional. This is probably unwanted due to the fact that this could make a GUI (and infobox markup) incredibly complicated and cumbersome. Another alternative is a way of activating unique classes or IDs for each major infobox tag. </p>

<p>Unfortunately css doesn't allow such things. The easiest way to achieve what you want is to use the theme-source, e.g.: Template:infobox </p>

 <infobox theme-source="newtheme">

<p>Template:randomcol_infobox </p>

{{infobox|newtheme = {{#if:{{{image}}}|mythemewithoutimage|mydefaulttheme}}}}

<p>Page content </p>

{{randomcol_infobox}}

<p>Then create a css with "pi-theme-mythemewithoutimage" that will display when the image doesn't exist. </p><p>See also: http://portability.wikia.com/wiki/Thread:2361 </p>

<p>It is a known issue of category collation. Categories sort alphabetically not numerically, and it uses each character to make the comparison. Wikis here are probably out of luck, as this was only fixed in recent mediawiki versions: </p><p>https://phabricator.wikimedia.org/T8948 </p><p><span style="font-weight:normal;">It is also far more complicated than that, as different language scripts use different collations. </span>Although, it is theoretically possible to use sortkey hacks to try to sort it .. </p>

<div class="quote"><i>Cqm wrote:
@Nanaki, @Dessamator: Ordinarily I wouldn't mind inline styles, but this is the first time in years there's been any concession after claiming it's bad for performance and even going to the lengths of writing a blog about it. Why the sudden change of heart now?</i></div>
<p>Well, nothing is written in stone yet. This thread is probably meant to highlight the pros and cons of such an approach, and they may simply not implement anything at all, as indicated in the main post. </p><p>>  I'm not sure if the game guide apps are still a thing, but last I looked they offered both light and dark themes. This looks more like we're taking the portability out of infoboxes again. </p><p>It is not a portability issue, it is actually an accessibility issue.  To use an analogy, watching a new colored movie on an old black and white TV would not magically give it color nor would it prevent people from watching it. It is also quite common to see many desktop sites / wikis with horrible color combinations (Color combinations hell). In any case, it is entirely possible to have a GUI or backend that simply rejects color combinations that make it hard or impossible to read, e.g. (white text on white background).  </p><p>This was entirely impossible with wikitext based infoboxes. </p>

<div class="quote"><i>Cqm wrote:
So in essence, PI now supports inline styling [on mobile]? Whatever happened to inline styling being bad? Assuming I've understood this correctly, this is also the only way to get styles into mobile as site CSS is still stripped away.</i></div>
<p>Inline styling is bad, but there are degrees of badness. For instance using inline styling for changing width, height and other layout causes problems. Changing something as simple as colors will never be as bad as the other more extensive changes because one never really knows if the device will work properly with them. </p><p>For example, some feature phones may not display content with color yet still have access to the internet (unlikely). So the choice of color in that scenario is important as the user may not be able to read anything at all, and in this scenario the inline styling is still bad. Although it is likely that the device would strip or overrite the inline styling anyway. </p><p>> Assuming I've understood this correctly, this is also the only way to get styles into mobile as site CSS is still stripped away. </p><p>Indeed, that's also my understanding, unless they change their minds and inject this into the style sheet. There's also a chance that the OP used inline styling just to show an example of how it will work, as lots of users are not be familiar with site-wide css, and many infoboxes depend on inline styling. </p>

<div class="quote"><i>Shareif wrote:
Yeah, sorry for that. We got back on Infobox tracks and would like to hear your feedback on many things :)</i></div>
<p>Before making this change perhaps this will have to be communicated ahead of time because although it can be easily rectified some overlapping classes may cause unusual output. </p>

<div class="quote"><i>Speedit wrote:
<div class="quote"> <p>Dessamator wrote: As far as standards are concerned, they are the main reason wikis can exist. Most editors do not possess any knowledge of website design or website administration. Wikitext itself is a big mess because it lacks any standards. </p> </i></div>
<p>I would add that its indeed better to give people the freedom for a range of customization, so long as its within a standard that ensures its clean and maintainable by other users. </p> </div> <p>A standard that is too lax tends to cause a mess. SVG is a reasonable standard but is well known to cause a lot security and usability issues. Too much freedom of customization  creates a problem when people can't migrate away from it without losing data. Case in point, wikitext isn't particularly the same in every mediawiki version, and because it has no standards, bugs may be treated as features, and features may be treated as bugs. There are also different versions of wikitext that don't conform to the same rules as the "normal" mediawiki. </p><p>These portable infoboxes differ because one can easily import them to something like a word processor, and very quickly create a document that contains that information. This can be done without fighting with wikitext or worrying about hundreds of parser functions that alter its output. </p>

<p>Hmm, lots of posts today.  </p><p>The master and slave theme approach works. By why not simply save yourselves some hassle and add something like "themes": </p>

 
<infobox theme="template theme" theme-source="themevar">
{My Infobox|themevar=theme1;theme2;theme3;}}

<aside class="... pi-theme-template-theme pi-theme-theme1 pi-theme-theme2 pi-theme-theme3 ...">

<p>As long as one uses a delimiter that is invalid in a css class name it should work just fine... </p><p>Currently it doesn't seem likely that making your suggested change will have any negative consequences, in fact, it will allow users to remove some hacks to add this functionality. </p>

<div class="quote"><i>Bwburke94 wrote:
This definitely makes sense, but are we taking too much away from the editors by standardizing everything?</i></div>
<p>One can still change them using MediaWiki:Common.css, of course those changes will not apply on mobile devices. </p><p>As far as standards are concerned, they are the main reason wikis can exist. Most editors do not possess any knowledge of website design or website administration. Wikitext itself is a big mess because it lacks any standards. </p>

<p>The general idea seems fine, but perhaps it should be simpler to add colors to these separately: </p>

• header
• title color
• Other header - e.g. navigation
• text color
• general color -  headers, titles, background
• outer border

<p>As far as the syntax is concerned, I don't think it looks particularly intuitive because the infobox tag is already crowded with too many options. Perhaps like this: </p>

<infobox> 
    <style accent-color-text-source="headerfontcolor" accent-color-source="headercolor">   
    accent-color-default="#aaa" 
    accent-color-text-default="000" 
 </style>
</infobox>

<p>It is also worth considering the outer border because many wikis seem to want to change this for each page. </p><p>Overall, the more long term solution would be something like TemplateStyles. </p><p>Also, since the idea is generally to move away from inline styling, it would make sense to pursue a mechanism like templatestyles that can be generalized to many other page components. Basically, colors for the main classes:  </p><p>http://community.wikia.com/wiki/Help:Infobox/CSS#Main_classes </p>

<p>Apparently, Wikipedia is getting seriously screwed by constant account hacks this week and even its co-founder and Wikia's owner Jimmy Walles account got hijacked. Interestingly, it is allegedly the same group that hacked facebook's ceo account ( http://gadgets.ndtv.com/internet/news/mark-zuckerbergs-pinterest-account-reportedly-hacked-by-ourmine-1626151). Hopefully jimbo didn't use the same password here. </p><p>Perhaps the security measures wikia put in place will prevent them from raiding wikia, which is probably an easier target than wikipedia due to lack of HTTPS, and even lack of two factor authentication(2FA) for regular users. </p><p>This (2fa) seems to have been recently enabled for all admins, and bureaucrats on wikimedia. </p>

<p>Yes, it is possible to see all of them using the API: </p><p>See : https://www.mediawiki.org/wiki/API:Iwbacklinks </p><p>https://www.mediawiki.org/wiki/API:Iwlinks </p><p>https://www.mediawiki.org/wiki/API:Langbacklinks </p><p>Although, you'd have to craft a script that makes use of those. </p>

<p>Indeed, that was my point, a better solution would be investing in backporting the Cirrussearch as that seems to be actively addressing improvements to search but that will probably take even more time (if ever) due to the older Mediawiki version used here. </p><p>It seems that Ark25 has already reported this issue, and if not it is likely someone already did so years ago. </p><p>In any case the second issue I mentioned might be easier to fix, and has probably also  been reported before. </p>

<div class="quote"><i>Sannse wrote:
Have a look at the more recent technical update here. There's been some work on this that will be released later this week. <p>Once it's live, please let us know how it works for you, and what problems you still see. Thanks! </p> </i></div>
<p>Maybe they fixed a separate problem, as this update is live. I guess that in some situations certain characters resulted in 0 search results, and that's improved. </p><p>The problem is exactly as described on the opening post. One would expect that searching for "sanatatea romania" -> "Sănătatea în România". But it doesn't show up on the first search results page. Searching for "sanatatea in romania" on the other hand has better results. </p><p>A much worst problem is that searching for incomplete words yields 0 results, and it seems like this is a limitation of the search engine or more likely wikia's incomplete implementation of it, examples: </p>

•  http://pt.duolingo.wikia.com/wiki/Especial:Pesquisar?query=Introdu (no results)
•  http://pt.duolingo.wikia.com/wiki/Especial:Pesquisar? search=Introducao&fulltext=Search&ns0=1&ns14=1# (found)
•  http://dev.wikia.com/wiki/Special:Search?search=sweep&fulltext=Search&ns0=1&ns14=1# (no results)
• http://dev.wikia.com/wiki/Special:Search?search=sweeper&fulltext=Search&ns0=1&ns14=1# (found)

<p>It is quite hard because this requires a linguist. For example, the turkish I causes some issues: </p><p>https://en.wikipedia.org/wiki/Dotted_and_dotless_I#Implications_for_casing </p><p>In particular, languages such as German have other issues such as the character ß in lower case being "ss", and if you're searching for multilingual text, then the software must just be psychic. </p>

<div class="quote"><i>Andrewds1021 wrote:
I have not actually used the array extension before but I have looked into it because I was thinking of using it on a wiki I edit. If I recall correctly, the array can be stored in a variable but it is stored as the string. The extension does not provide many functions besides storing and retrieving value. That being said, you can always flatten a multi-dimensional array.</i></div>
<p>Yes, it is doable, but not without a lot of complications. Believe me, I once tried to do that, fortunately my trials happened around the time Lua was being introduced, and this was quickly changed before the markup got even more complex. </p><p>The OP seems to need these for a pseudo-database, and such a thing can never work properly using wikitext as that is not what it was designed to do.  </p>

<p>Your explanation makes a lot more sense now. You can try having a look at this and this module. They do more or less the same thing you want to do. The  page on converting will also help a lot.  </p><p>Still you'll have to learn how to use lua, and it does require some degree of programming knowledge. Although you seem to have it, as a "two-dimensional array" isn't something an average person even knows. </p>

<p>Wow, it is an incredibly complicated thing you are trying to build. Perhaps you should evaluate whether the complexity  is worth it, because at some point assuming your wiki is popular someone else might have to understand all this complicated stuff and maintain it. It is clear that most users wouldn't be able to grasp what the heck you're talking about. </p><p>If you truly want programming constructs then perhaps you should use Lua which does support two dimensional arrays,  loops,  variables, and much much more.Otherwise, you'll need a mix of the arrays extension, the variables extension, and Extension:Loops which isn't available on wikis here. An alternative might be some complicated templates that simulate loops, or using parallel arrays instead of two dimensional arrays. </p>

<div class="quote"><i>DEmersonJMFM wrote:
Sent in a request for this, and other, tag support back in April to get the following: <table style="background: transparent; border: none;"><tr><td class="dark_text_1" style="font-size: 3.3em; font-family: 'Times New Roman',serif; font-weight: bold; padding: 4px 2px 2px; width: 0.5em; vertical-align: top;"> “ </td><td> <i>We're currently discussing future updates to the VisualEditor - while I can't make any specific promises, I think this is entirely possible.</i> </td><td class="dark_text_1" style="font-size: 3.3em; font-family: 'Times New Roman',serif; font-weight: bold; padding: 4px 2px 2px; width: 0.5em; vertical-align: bottom;"> „ </td></tr><tr><td> </td><td style="text-align: right;"> <small>~ Kirkburn</small> </td><td> </td></tr></table><p>I'd recommend you Special:Contact/feedback. The more requests, the better. </p> </i></div>
<p>I think it would be more likely that they might add tag support that already exists in the form of plugins for VisualEditor, see:  </p><p>https://phabricator.wikimedia.org/tag/visualeditor-mediawiki-plugins/ </p><p>The current functionality only allows editing of the poem tags but not adding them to articles: </p><p>https://phabricator.wikimedia.org/T45120 </p><p>You can see how it currently works by editing any sandbox page on wikipedia with the poem tag. </p>

<p></p><blockquote>That link you gave me doesn't explain anything about the Special:Promote feature. Ironic that you tell me not to make assumptions when that's what you've done to me :/ I've made no assumptions here, simply worked on the facts that I have.</blockquote> <p>That's indeed the problem of working with data without the full context. To see how the old tool worked you can check out the old page archives, promote. Something you probably didn't know is that more than 1 image could be uploaded to represent and promote the wiki. </p><blockquote>What I want to highlight to staff is that even when unlawful use was brought to their attention, they were happy to allow it to remain unlawfully on the wiki.</blockquote> <p>Not sure what means you used to indicate that issue, but the appropriate one is this:http://community.wikia.com/wiki/Special:DMCARequest . Although that's generally used by the actual authors of the content or their representative. If  one staff member fails to address the problem then you can escalate the issue to their supervisors or higher management, which is likely indicated on their staff page or possibly in the email footer. </p><p>If nothing else works you could always contact the legitimate owner and tell them about the infringement, and they'll address Wikia formally if they really care. </p><p>Not all authors really care about chasing down everyone who misuses their content. </p>