Several users on nl.wiktionary create a background for the comments on their Discussion page by opening a div and not closing it. This results in each new comment being part of this div. For an example see . The parser migration tool suggests that this effect will be preserved in the near future, so a change does not seem urgent. But is there presently a HTML5 compliant way to get the same result?
Help talk:Extension:Linter/Flow
I think that someone like @Jonesey95 or @ Facenapalm could probably tell you if there is a good way to do this.
I think the only solution is to add a closing /div tag. I thought there was a CheckWiki error for this, but I do not see one. I do not know how they are detected on en.WP.
CheckWiki can't find this case, because it can't analyse page code after tempate substitution (and because that page is not in main namespace as well).
I see 2 possible good ways and both of them are not applicable to this case. First is CSS, applicable only to personal design. Second is using a subpage with topics, which will be included to this one using something like "<div style=[design]>{{/topics}}</div>", and custom buttons "add topic", leading to subpage.
Thanks for the information. So it seems there is no alternative for this trick. In that case my approach would be:
a. not doing anything to change these pages (at least in this respect: some other errors already have been resolved)
b. wait and see if and when a future change will break these pages, and then explain the users concerned that a solution is not available
c. if anyone asks at an earlier date, point to this discussion.
My reasoning: at Dutch Wiktionary only a handful of users used this trick on their Talk-page and none of them are very active at present. At the moment no one is having a problem. Even if this would change in the future, chances are there will be many things more important for our project to spend resources on.
I somehow missed this topic earlier since I didn't have this page on my watchlist till recently. But, yes, we are aware of this usage pattern on user talk pages on many wikis (not just nl.wiktionary). We might eventually break this pattern, but we will try to figure out reasonable alternatives that addresses the common use cases. For example, this could be a page property that specifies a wrapper / CSS that is automatically applied by the parser. This would address the common use cases like the one you refer to, but won't address use cases where editors add the unclosed <div> tag in the middle of the page. But, yes, we are aware of this use case and have discussed this in the past. We will do what we can to support this cleanly without relying on hacks like unclosed-div tags.
Supporting this use case makes very little sense. Extension:TemplateStyles looks like the best solution primarily because the lack of a personal stylesheet won't be a problem if / when templatestyles is deployed.
Such open html tags also cause loads of other issues, for example someone could easily break it by closing the div earlier than expected (e.g. using an unbalanced template). Beyond that, it can be quite confusing to newbies and even experienced users if someone adds something like the html below.
<div style="display:none">
Right, we won't support unclosed <div> tags. I indicated that we would support the use-case for styling using whatever clean / sane mechanism that might be.
Is there any progress on this issue? These are the only Lint errors that remain on nl.wiktionary for more than a few days...
I just wanted to inform you that in dewiki all old lint errors in all namespaces got fixed, the last ones today.
You're welcome to continue on other wikis.
Dutch wikibooks was "clean" almost three months ago.
Hurra, und danke an all die wunderbaren Mitwirkenden!
(Sorry, I haven't learned any Dutch.) That's great news for both wikis.
I want to echo the congrats -- well-deserved barnstar! :-)
It will be convenient to separate a category with a center tag from an obsolete category. All tags are relatively easy to update, but the center is widely used in image captions. Because of this (disputes over the design of articles), the center is more difficult to replace. But other tags can be updated much faster. In general, the center tag takes many lines in Linter/obsolete-tag and you have to go to the next page many times to find another tag.
If it's widely used in image captions, perhaps there should be a more structured way to specify that the caption should be centered.
I suggest going even further and separating all the tags, so that it will be possible to get a list of pages that use each tag.
I would like to know why wikitext for images does not provide for the alignment of image captions. Perhaps there were reasons for this.
Yes, categories missing-end-tag and obsolete-tag (and stripped-tag; for example, it is convenient to have a separate list for table tags) are huge and split them into smaller ones could be helpful. Small categories are easier to handle (and more enthusiastic) than such large (hundreds of thousands) ones with "infinite scrolling."
I don't think that it was intentionally not allowed. The people who designed the captions years probably just thought that aligning them to the same side where the paragraphs begin is what's needed. I actually haven't seen a lot of images with centered captions, but maybe they are common in the wiki where you write often.
In general, design of pages across different languages should be as similar as possible unless there is a particular reason to do something differently. If there is a reason to make captions centered in the Russian Wikipedia in some cases, then maybe they should also be centered in these cases in all other languages. Or maybe they shouldn't Can you give me some examples of centered captions?
You can read a little here . When I just deleted the center then they say "you broke my design", "I see it in that way". This is complicated by the fact that a center class is often adds to the gallery tag, in the infoboxes and panoramas the centered image caption, in books, reports on academic/university works pictures and captions often require to be centered. For examples you can use regexp in search >5k articles with a center tag (apart from what has been done through the template:center).
In Infoboxes and other templates it should be done by the template.
I read the pages and I'm still wondering why would anyone want to make usual image captions in articles centered. Is it systematic, or is it just a choice in certain articles?
It is already by the template and it is centered, which differs from the design of simple-wikitext images in the text.
They see it in the sources (e.g. 1 2), and in them it because of the layout requirements ("Справочник издателя и автора А. Мильчин", "Гиленсон Справочник художественного и технического редакторов", "ГОСТ 7.32-2001 6.5.4", I think something in this direction) for the books and the other.
Um... Well, it's up to the Russian Wikipedia to decide. I know Russian, but I don't write in the Russian Wikipedia much. I will add, though, that it really shouldn't be different in different articles, and there should be really good reasons to change the default design anywhere.
Sorry folks .. the linter UI needs some serious work at some point.
As for the center tag, we could suppress it, but the question is if this preference for center tag is specific to russian wikipedia or something that is common on multiple wikis. Do either of you know?
It's a question for @Sunpriat.
I'd say that it shouldn't be suppressed.
My tip to @Sunpriat is to bypass the special page and write a bit of JavaScript that reads the pages data from the API, and then filter out the tags you don't need. It should be easy for anyone who is familiar with using JavaScript on MediaWiki, but I can help if needed.
@Amire80 ok, for API, how can I get from https://ru.wikipedia.org/wiki/Special:LintErrors/missing-end-tag separately the data for one type (td) from the second column?
I couldn't find any instances of 'td' in the first 500 results, but here's something for 'center':
api = new mw.Api();
api.post( {
"action": "query",
"format": "json",
"list": "linterrors",
"lntcategories": "missing-end-tag",
"lntlimit": "500",
"lntnamespace": "0"
} ).done ( function ( result ) {
for ( i = 0; i < result.query.linterrors.length; i++ ) {
if ( result.query.linterrors[i].params.name === 'center' ) {
console.log( result.query.linterrors[i].title );
}
}
} );
You can run it in the browser JavaScript console while viewing a page in the Russian Wikipedia.
It's super-rudimentary, but works :)
As it seems to me, it is the WMF that should consult with the typographers and clarify point around alignment (and center) everywhere for us in the guideline https://design.wikimedia.org/style-guide/visual-style_typography.html . In the infocards, image caption centered even in en-wiki ( https://en.wikipedia.org/wiki/Tibial-fibular_trunk ).
I am used to Special:LintErrors on nl.wiktionary showing estimated numbers. But the line "missing end-tag" for the last weeks has been showing an increasing total, not reflecting that all new errors have been corrected. Has there been a change in the way the total is estimated? At present the page is becoming pretty useless.
There has been no change to how it is done. It is based on estimates provided by mysql.
But how is this estimate computed? I looks like the removal of errors has no or only a very slow effect on the estimate. If it is meant to encourage that errors are removed, this seems counterproductive. And even as a tool is has become useless: I have to look at the subpage to find out whether there are any new errors.
The estimation code is pretty wacky, see https://www.percona.com/blog/2011/10/13/when-explain-estimates-can-go-wrong/ and https://stackoverflow.com/questions/1037471/why-the-rows-returns-by-explain-is-not-equal-to-count, https://phabricator.wikimedia.org/rMW6261b4187a91099f4f2fd900562506cf2b3df984 . The hard part is probably fixing the estimate.
The stackoverflow link suggests that using analyse instead of explain will yield better results (at least with mariadb they seem to output different results).
Anyway, the alternative is pretty simple, whenever the number of rows returned by the estimate are less than 5000, simply run the full sql query, or instead of getting the estimate, just re-run the query clientside using javascript api once the special page loads.
https://nl.wiktionary.org/wiki/Speciaal:LintErrors/missing-end-tag currently estimates 26, and lists 12. I don't know what the numbers were when Marco looked at it yesterday.
If I remember correctly: estimate 23, listed 10 (8 of which are more or less permanent, the other 2 were resolved. Now we have 4 new errors on new pages, bringing the total back to 12. But the actual number remains most of the time close to 8. There has been a single time a few weeks ago when a single page once contained a larger number of errors, pushing the total over 20 for just one day. Somehow I get the feeling that the estimate keeps using this single instance as a basis.
The new errors were corrected this afternoon (local time 13:30), so the actual number became 8 again. At the moment (local time: 19:45) the total is back to 23.
All this is just the behavior of the database estimation tool.
As the anon user above indicated, the solution for this is for us to update the code to do an actual count when the # of results is estimated to be under some threshold that has acceptable performance from the DBA point of view.
Is there anything I can do to help bring this about?
It requires development to be done on the Linter codebase. We are currently heads down on the high-priority work of porting Parsoid to PHP and we are unable to pick up linting improvements till we are past that milestone.
But, if you are a developer or know someone who wants to work on linter improvements before then, I could probably squeeze in time to help with code review and guiding the work.
Consider the following wikicode:
{| style="background-color: #eb6841; style="text-align: center;"
It seems that with Tidy previously, the table would not be colored red, but with RemexHTML now it does. Should this be flagged by the linter?
This is more likely to do with, https://github.com/wikimedia/mediawiki/commit/59bb8864a23f3df120789c7619ef07acefa27b9c
Ah OK. But since this parsing change, a page's layout can break via an unrelated edit, so I would have expected a notice in Tech News to at least prevent confusion.
Sorry about that, it's my fault. There was a bit of discussion about the repercussions of the change at the bottom of, https://gerrit.wikimedia.org/r/c/mediawiki/core/+/471363
Do you think it's worth adding to the next edition of Tech News?
A broken page layout is not always noticed, and even then not always reported. So I think it would be good to let technical editors know which patterns are now treated differently.
Ok, I added in here, https://meta.wikimedia.org/w/index.php?title=Tech/News/2019/02&type=revision&diff=18722210&oldid=18709064&diffmode=source
Great, thanks. I'm glad that you watch this page! :)
Hey, I'm handling Tech News for this week.
How would you summarize that change in one sentence? How will in impact users? Do you have a tracking ticket on Phabricator about that?
Thanks!
Since I have no reply but I have to wrap-up and freeze the current issue, I've posted your previous explanation to next week issue.
Please provide there a shorter explanation. :)
@Bdijkstra, any updates?
Not from me. I assumed you were asking @Arlolra. I don't understand the change well enough to be able to figure out which wikicode patterns are now treated differently.
How about ...
Quoted attributes used to require being followed by a space, now they do not. Since this is a change to how a page is parsed it could cause unmodified portions of the page to render differently on edit.
Thanks! I simplified that a fair bit, for the benefit of non-native and/or non-technical readers. You can see the draft at m:Tech/News/2019/03.
Please see lintHint@PerfektesChaos with functionality:
- Analyse current page.
- Analyse arbitrary wikitext sequence or any page.
Greetings
@PerfektesChaos, hi, would you like to add a link about it on the actual page perhaps? It only needs a basic description.
This advertising is supposed to be added to the connected page.
However. that should be done by a higher polynomial degree, not by myself, and someone might declare it as harmless.
Even more, there is no Tools and Aides section yet on target page.
On doc page enough text material to be copied is available.
By all means, please do feel free to add where you see it fit, the wiki way.
Here's an example of how that's been done in the past.
That should remain business of someone with “(WMF)” terminated nick. I am not pushing myself to the front.
@Whatamidoing (WMF) sent a THX 11 days ago.
I guarantee this is not the case. Us being around does not mean we own these pages, by any means.
Do we have a curated list of tools available for semi-automatically fixing all these (linted) errors?
I don't think so. Would you like to start one? I am not aware of those which have not already been mentioned (Linter, NicoV's one, and the one from this thread).
When you say Linter do you mean Special:LintErrors or an editing tool?
That one.
Apparently not.
I might advertise WikiSyntaxTextMod@PerfektesChaos which happens to fix some automatically while editing for other reasons, and identifies some other problems and warns on manual source editing. Running since 2010, mostly on German WP.
I just want to acknowledge how lintHint gets praised by community members who aren't their creator :p (it's mentioned in this comment at it.wp). I don't mean to say the other tools aren't equally useful, but thought that this endorsement mattered as it comes from another community that also switched early.
Gracie.
G-Translator told me the it story.
Ah, Italian, since lintHint 3 is on alpha testing and close to be published, I would be happy to get a human translation in Italian for the following text fragments:
- Show LintErrors analysis live.
- Fill balanced wikitext into first input area and press adjacent submit button, or enter page name into second input field (might be followed by revision ID).
- select problem in source text
- Wikitext page not found
- Future problems detected.
- linter error analysis support
- Analyze previous revisions, too.
- Run analysis automatically in namespaces on visit rather than manually triggered by button.
- Convert all source edit links on LintErrors special page into ParserMigration tool edit.
- Suppress small label if no error detected.
- Space separated list of namespace numbers, for automatized analysis or - or *
Italian utenti will benefit from that.
- Mostra analisi degli errori di Lint in diretta.
- Inserisci il wikitesto nella prima area di input e premi il tasto di invio adiacente, oppure scrivi il titolo della pagina nel secondo campo (potrebbe essere seguito dall'ID della revisione).
- Seleziona un problema nel testo sorgente
- Pagina di wikitesto non trovata
- Futuri problemi individuati.
- Supporto per l'analisi degli errori di Lint
- Analizza anche le revisioni precedenti.
- Esegui automaticamente l'analisi nei namespace all'accesso, piuttosto che avviandola manualmente tramite bottone.
- Converti tutti i link di modifica sorgente presenti sulla pagina speciale Errori di Lint nello strumento di modifica ParserMigration.
- Nascondi l'etichetta in assenza di errori rilevati.
About the last one, I'm not sure what it refers to.
@PerfektesChaos Thanks for the tool :-) About the last one, if I understand correctly, it should be a label for a field containing a list of space separated namespaces where to perform an automated analysis, - for none or * for all. If so, a translation might be "Lista di namespace, in formato numerico separati da spazi, dove effettuare l'analisi. Usare - per la lista vuota e * per indicarli tutti"
Gracie, both of you.
I presume next weekend a pre-release of something like a version 2.9 ahead of 3.0 will be online, containing your texts. There you might do a last check.
If you change temporarily in the JavaScript call from /r.js into /d.js you will find your texts on these pages:
For the benefit of utenti italiano I prepared w:it:Utente:PerfektesChaos/js/lintHint. Currently this is just a redirect. After version 3 has been released and English documentation was updated you might translate some most important sections, linking to English base documentation where less interesting.
Tested it, everything seems fine, well done! And yeah, we'll provide some kind of translation there once ready. Thanks again!
Version 3 has been released now.
The German story shows what is basically needed on a translated user guide. However, the JavaScript section is not very important any longer, since the interactive customization has been introduced. The English mother documentation is adding full information for programmers and maintainers which is not needed for using.
Is there an tool in which to enter the name of the page and would show all the errors for it? (not a PerfektesChaos script) For ordinary users. For example on special:LintErrors it would be a search field and would show all categories for one page. So someone could just check out their "interesting" pages without scrolling through the list. Or if the page in remex is now shown as "broken" then it would be possible to quickly find the reason (for example, with unclosed s tag).
You could use Extension:Linter#API perhaps?
Once https://phabricator.wikimedia.org/T164006 is fixed (soon), you will also get a REST API endpoint which you can issue GET requests to for a specific title (or title & revision).
I can use it. But I would not want to constantly be a medium between script/api and the user responding to "why half the page is line-through". It would be nice to send users to the tool that they themselves would use.
I see .. you want this integrated into the LintErrors special page. Let us take a look.
I have made simple user script: ja:User:MawaruNeko/ShowPageLintError.js. I hope it could be helpful.
I see the tool is in the relevant section, can this thread be closed?
I edited pages in lint errors from wikipedia,simple english wikipedia,and 2 other wikipedias. But the update is not happening in the list. Not even a single edit made by me is getting updated from the linter category.
If the number of corrections is small, this is normal at the moment. It can take several days before the Special page is updated. I remove errors on a daily basis at nl.wiktionary.org and I am experiencing the same. Somewhere I read that updating small changes more often was causing technical problems.
Something might be temporarily broken with the update mechanism -- normally, it takes a little while for updates to propagate, but 24 hours is too long. Topic:U8oc5a9rj7me4qt0 has another report from an user on Turkish Wikipedia. We'll investigate this tomorrow.
For at least weeks now, in English Wikipedia, it has said "Multi colon escape (2 errors)", even though there are no such errors.
I've been trying to fix w:yue:Template:選舉資訊 but found that I couldn't delete the nested table tags without breaking the formatting specifications. Any suggestions on how to fix this template? It has hundreds of transclusions and make up a significant proportion of the errors on yue.wp.
Try deleting this line:
{| class="infobox_v2 {{#if:{{{選舉日期|}}}|vevent}}" style="width:22em; font-size:90%; width:{{#expr:{{{代表圖片尺寸|45}}}*{{#if:{{{候選人3|}}}{{{政治聯繫3|}}}|4|3}}}}px;"
I don't think that applies to the pages anyway. Or, have you tried it and find that it breaks something?
I haven't tried deleting the whole line because I was trying to preserve some of the CSS options on that line, not knowing they would've been ignored by MediaWiki anyway! (I didn't create the template.)
I tried your proposed change and checked a few pages. It seems to be okay. If it breaks anything I'll come back to let you know.
I fixed a self-closing tag error on August 2017, but on Special:LintErrors it still appears as not fixed. Here is the url: https://bg.wikipedia.org/wiki/Special:LintErrors/self-closed-tag.I fixed the same error in the same script, but from the User namespace (a contributor has created a version of it for personal purpose) and all is fine with it. Does anybody have an idea where could be the problem? I suppose that something is not updating properly in the DB.
We stopped linting non-wikitext content models. You must have fixed the error after we did that. So, that is very likely the reason this is not updating.
Shouldn't such non-wikitext content models be cleared from the reported errors? This is some kind of missynchronization. Can this be cleaned?
Yes, we'll take a look.