the plantum author arnaud roques thinks about a greenfield approach to rewrite plantuml in haxe : https://github.com/plantuml/haxe00 . mindmaps are working. haxe's closed relate is lua. haxe can be transpiled into javascript, lua, php7 amongst others, its main usage is in games.

@AlexisJazz can you point to the page where consensus was reached about the current display, so we can refer to it?

here, the line with cc-3.0 should be removed.

this is ok ...

@AlexisJazz @Aklapper , community consensus to help avoiding legal trouble for wikipedia users? really. which page you want community consensus to come from - i can make an entry there?

you are right, @AlexisJazz lets leave aside the correct license for chilean government works, apart from that the fact that the upload wizard should not list it, otherwise we have hundreds for every country.

a couple of reports of copyright / copyleft trolling, which could be avoided by such metadata:

• cory doctorow, 2022, A Bug in Early Creative Commons Licenses Has Enabled a New Breed of Superpredator, https://doctorow.medium.com/a-bug-in-early-creative-commons-licenses-has-enabled-a-new-breed-of-superpredator-5f6360713299.
• 2018 reported by martin steiger, cc switzerland: https://steigerlegal.ch/2018/10/15/wladyslaw-sojka-wikipedia-abmahnungen/, image in question, as most cases cc-by-sa 3.0: https://commons.wikimedia.org/wiki/File:Aerial_View_-_Goetheanum1.jpg

@AnneT , related to here, the former european director of creative commons, cory doctorow, got targetted by a copyleft troll, see his post: A Bug in Early Creative Commons Licenses Has Enabled a New Breed of Superpredator. he recommends now to use cc-by-sa-4.0 and higher. to reliably get rid of such trolls, two actions should be taken imo. first, require cc 4.0+ and second, embed the link to the license and/or source with the license into the images metadata. INTO the file. so if somebody downloads and uses it the correct metadata is there. @Tgr i saw your comment about this beeing scary in your comment T250317#6178173, on T5361 ... but this one single link to the source should suffice to extinct trolls. everything else can be fixed via license, or viewers.

siehe T183689.

as additional info:

@Samwilson who would be able to judge if WMF hosting such a service would be an option, or, in general, if, calling a service and caching the service calls result to render something is desireable?

re-reading your 2nd remark, you mean a proposal to improve the voting for wishlist survey should be posted to wishlist survey? how ironic :) for this year it is too late, and for next year i will have already have forgotten about the proposal until voting pops up on the main page.

@Aklapper let me rewrite it. i now found how this is called. ordering via ranked pairs, or schulze method or whatever lets you sort a list via comparing 2 pairs, or a low number of entries.

nowadays there is an extenstion https://www.mediawiki.org/wiki/Extension:Diagrams , would enabling it be a step into the right direction?

there is another extension looking interesting: https://www.mediawiki.org/wiki/Extension:Diagrams , what you think about enabling that one @Tgr ?

thank you @Aklapper, so you say this is a bug not a not yet implemented feature :) here you go:

1. on a laptop with chrome or firefox, open https://en.m.wikipedia.org/wiki/Cristiano_Ronaldo#/editor/35
2. click into a cell marked with a long dash "-"
3. the cell is not marked and there is no obvious way to press "split"

In T294707#7470354, @Jc3s5h wrote:

One of the chief arguments against date autoformatting was that the only way to make it work was for the user to set a preference. Since the vast majority of readers were anonymous (not using an account) the change would only serve a small minority of readers. The main effect would be to conceal poor choices, which would be visible to most readers but invisible to the editors who would be in a position to fix the poor choices.

In T294707#7470311, @Aklapper wrote:

for height there is no one million possibilities

There are a bunch: https://en.wikipedia.org/wiki/Unit_of_length . Next preferences then could be Celsius vs Fahrenheit vs Kelvin, stones and pounds vs kilograms, lakhs and crores vs millions, etc. I don't think adding more such preferences outweighs the additional maintenance costs and code complexity for years to come.

In T294707#7470263, @Izno wrote:

This won't and shouldn't be done. It's basically equivalent to the auto-date formatting that was already removed a decade ago.

This can be resolved onwiki with some sort of user script or gadget.

@tstarling - as promised on facebook, here a task for measurements.

it is enwp specific ... as other languages do not tend to have ft in ?

the javascript libary date-fms looks kind of nice to address the data formatting challenge:
https://github.com/date-fns/date-fns

since 2016 there is a nice library which should prevent this lots of code:
https://github.com/date-fns/date-fns

when using on laptop screens it stops beeing responsive from 50% of the laptop screens witdht on and does not use the available space any more:

• a lot of white space left and right
• items stil with 2 clicks like "my contributions"
• same is valid for editing - the edit area is tiny
• the font is not the operating system default font and default font size

ah really, you r right. it is responsive from 0 to 50% of a small laptop screen. then it stops adapting. attached an editing window screenshot. looks same with firefox and chromium. if i click "legacy vector" it uses the whole screen width. adding ?safemode=1 does not affect the width as well.

cool - i saw how this works, thanks for the hint! this is not the most intuitive fried i saw in my life i must admit :) :)

duplicate.

ah, i see, @TheDJ, @Jdlrobson, thank you so much! that is it, the narrow and widescreen gadget is enabled by default, can i close this task or you prefer to leave it open and change the title?

@Jdlrobson just out of interest, why did you opt to have "skin versions" or "vector uses two internal skins", instead of just having a new vector21, make it default whenever you like, and drop "vector" whenever you like?

@Jdlrobson i saw in the techn news your name to ping ...

another instance with the location, on pt wiki

another instance of similar here:

In T200052#4443200, @Tbayer wrote:

In T200052#4443196, @Reedy wrote:

In T200052#4443049, @ThurnerRupert wrote:

duplicate of T32574 - there is a patch which implements password lenght attached to T32574. this does not display yet a password meter.

I'm not sure how this is a duplicate of T32574: Display a password strength bar..

Indeed, it seems this was closed based on an erroneous assumption.

the title "password meter" would not suggest a duplication. but the contents is a full ducplicate - and - has a lot more value. there is already an expert discussion in T32574: Display a password strength bar which includes password strenght. the patch attached to T32574: Display a password strength bar uses a password meter algorithm. it implements to configure a minimum strenght in the config file. it does not (yet) implement anything to show the complexity of the password to the user beforehand. having a second ticket only for the lenght of the password based on a paper of such weak quality which is not even public for everybody seems not ok. what mediawiki currently offers is already far better than described in that paper:

• https://www.mediawiki.org/wiki/Manual:$wgPasswordPolicy - password lenght 8 for different user groups already there
• limit the rate of retry in online attacks
• hash the passwords for offline attacks (not sure though if it is still in line with what NIST says ...)

yes, exactly, many thanks for the copy out, reedy! there is T32574 as well which partially covers what is mentioned in this ticket (aaaaaaa)

an example password strenght meter:

• demo: https://cups.cs.cmu.edu/meter/
• mentioned in this article: https://phys.org/news/2017-05-unveil-password-meter-users-passwords.html.
• source is here: https://github.com/cupslab/password_meter

duplicate of T32574 - there is a patch which implements password lenght attached to T32574. this does not display yet a password meter.

this is against recent NIST research, and should be closed as "not implement":
https://pages.nist.gov/800-63-3/sp800-63b.html

this paper is quite outdated or even incorrect, except for "usability" - i.e. present a password strenght meter. to be more detailed, it says that a password is sent via email. but - this is only a temporary password which only allows to reset the password. so comparable to a link with some arbitrary number. it also suggests to use different character classes, which is discouraged by recent NIST research. it also thinks that a minimum password lenght should be set which is also against the NIST recommendations - which are clear that the type of the service offered, or the information to be protected, should determine the password strenght. also, NIST discourages policies that force to set a new password (regular password change eg) and suggests that the strenght should be measured against a list of breached passwords while the study says reusing an old password is bad - no matter if breached or not.

the library used seems excellent. the usage i am not so sure, it is a mandatory check, and not a hint to the user:

		if ( $score < $policyVal ) {
			$status->error( "passwordpolicies-policy-passwordstrength", $score, $policyVal, $maxScore );
		}

the upload wizard could guide the user in adding the information. or require the user to add it herself? so we have not the problem of "original photo does not contain the license information, but then it is added". what you think?

another case which could have been solved by this:

• https://de.wikipedia.org/wiki/Wikipedia:Urheberrechtsfragen#Hilfe_-_Rechnung_f%C3%BCr_Commons-Foto_erhalten
• here the glitch: https://web.archive.org/web/20170821133848/https://2017.langertagderstadtnatur.de/angebote/details/2732 - no link to the license

hahah, andre, i find it now painful in phabricator that it seems to be impossible to create a ticket towards better control of new pages :) what i want is clear: give a new page time to ripe. and for this, give the persons checking new pages technical means to do this appropriate. as you are experienced with all software components could you list the components involved and their purpose, so we could make tichets which can be implemented? mabe flag pages, or not. maybe display edits after X hours? maybe a flag "not done" or "help wanted" when storing? not sure what means were discussed up to now ...

i cannot recall the exact message, and i would appreciate to concentrate on the root cause: somebody doing new pages control feels that it is necessary to move an article into the users namespace because the person thinks the article is not good enough. such a move should never be necessary or permitted. if not good enough not flag it. if not flagged for long enough (a week or so) just delete it.

i stumbled on https://gerrit.googlesource.com/plugins/github/+/master/README.md - is this something you envision here?

removing myself, to express my wish that administrative bloat and organisation busy with itself should be avoided, while writing software and helping patches from others go into software should be encouraged ...

i got 2 emails for this:
https://de.wikipedia.org/w/index.php?title=Benutzer_Diskussion%3AThurnerRupert&type=revision&diff=154711247&oldid=154711238

interesting point, what exif fields would be necessary to get the copyright ok? or add the copyright related fields of xmp?

why not starting with something easy? if making a thumbnail for wikipedia, leave exif in place?

@wctaiwan , interesting feature, did not notice it before, but i like it. this solves the problem, thank you!!