MediaWiki-diskusjon:CustomEditButtons.js

message: Hei. Ser det skrives veldig mange tall med feil formatering og tenkte det kanskje kunne hjelpe med en knapp i redigeringsboksen som satte inn et Narrow No-Break Space   (U+202F) som gir et bedre utsende enn  . Dessverre er det ikke noe perfekt ikon på commons men evt. kan ,  eller  brukes. Kan ikke legge koden inn selv, men det er vel ikke svære jobben for deg som kan det? 
PS: noen som kan forteller meg hvorfor «nowiki» ikke fungerer på   pg   (dvs. dersom ; og nowiki er tilføyet tolkes det fremdeles som wikikode slik at det kommer et mellomrom i teksten istedet for) Mvh Prillen 13. jan 2009 kl. 11:08 (CET)
replies: text: Fikk å høre at   ikke fungerer for alle og endrer derfor mitt ønske/forslag: Det skrives veldig mange tall med feil formatering og tenkte det kanskje kunne hjelpe med en knapp i redigeringsboksen som satte inn et  . Dessverre er det ikke noe perfekt ikon på commons men evt. kan  brukes. Kan ikke legge koden inn selv, men det er vel ikke svære jobben for den som kan det?

text: PS: noen som kan forteller meg hvorfor «nowiki» ikke fungerer på   og   (dvs. dersom ; og nowiki er tilføyet tolkes det fremdeles som wikikode slik at det kommer et mellomrom i teksten istedet for) Mvh Prillen 14. jan 2009 kl. 09:28 (CET)
replies: text: : Jeg vil helst ikke anbefale   – jeg syns den gjør kilden uleselig.  Selv bruker jeg  for rene tall og  for tall med enheter og annet.  På Bruker:Sidhekin/monobook.js har jeg knapper for disse; se det gjerne som et forslag.  — the Sidhekin (d) 21. jan 2009 kl. 12:09 (CET)
replies: text: :: Tja, det er jo også en mulighet. Synes bare selv at   er mer anvendelig (synes i grunnen både   og  gjør kilden mindre leselig (skulle veldig gjerne hatt en editor  med fargekoder som i programmering). Men med   trenger en jo bare en knapp og jeg tenker dette primært er for nye brukere. Erfarne brukere kjenner jo til dette problem (i hvert fall delvist...). Uansett er jeg for det ene eller andre – bare det blir noe (men nå kan du (Sidhekin) jo snart fikse her på siden så da blir det kanskje  og . Mvh Prillen 21. jan 2009 kl. 12:25 (CET)
replies: text: ::: Hva vi enn velger å bruke, blir kilden mindre lesbar.  (Det måtte i så fall være et «ekte» non-breaking space, men det kan vel de færreste skrive på sine tastaturer, og om så var, tror jeg ikke HTTP overfører dem som annet enn vanlig space.)  Noe må vi likevel bruke ...

text: ::: En ting jeg glemte å nevne er hvor mye enklere det er å oppdatere tallene (klipp-og-lim) hvis det ikke må klippes-og-limes html-entiter mellom hvert tredje siffer i hvert tall hver gang ... alt du behøver å gjøre er (om nødvendig) å sørge for at der er brukt desimalpunktum og ingen tusenskilletegn (ved formatnum) eller desimalkomma og blanke som tusenskilletegn (ved nowrap):
Størrelse 	med nbsp                               	med nbsp                   	med formatnum/nowrap      	med formatnum/nowrap
3500      	3 500                         	3 500                 	      	
1234567,89	1 234 567,89         	1 234 567,89     		
1350 km²  	1 350 km²            	1 350 km²        	      	
kr 1250000	kr 1 250 000	kr 1 250 000	

text: ::: ... og så skal vi hverken ta tekniske muligheter for gitt eller tro at det bare er de som mangler. ;-)  Hvis du vil ha disse, kan du selv legge dem i Bruker:Prillen/monobook.js – men hvis du vil at alle skal ha dem, tror jeg flere bør uttale seg. — the Sidhekin (d) 21. jan 2009 kl. 15:57 (CET)
replies: text: :::: Jeg har ikke selv noe problem med å skrive nbsp (sikkert raskere enn å ta tak i musen til verktøylinjen), men derimot er det svert få ferske brukere som kjenner til nbsp, formatnum og nowrap – og det er dem jeg primært ønsker å nå. Derfor er Bruker:Prillen/monobook.js ikke løsningen i dette tilfelle.    Men jeg ser jo dit poeng med klipp-og-lim er enklere med formatnum, det hadde jeg ikke tenkt på. Imidlertid synes jeg nbsp er enklere å lese enn nowrap. Uansett skal jeg ikke stå på nbsp, bare det kommer en løsning på at tall deles, enheter kommer i neste linje, bindestreker slutter i «løse luften» osv. osv. Prøvde også å sette inn et nbsp ved klipp-og-lim og som du antyder fungerer dette ikke. Så vi kommer nok ikke uten om et av forslagene over tror jeg. Mvh Prillen 23. jan 2009 kl. 11:04 (CET)
replies: text: ::::: Kan du virkelig se på den tabellen og si at andre kolonne er mer lesbar enn fjerde?  :-\  Vel, uansett hvilken variant det blir, bør flere se på dette.  Annonsere diskusjonen på Torget, for så å flytte til Tinget om (1) noen syns den hører bedre hjemme der eller (2) ingen svarer? :)  Eller har du bedre ideer? — the Sidhekin (d) 23. jan 2009 kl. 16:16 (CET)
replies: text: ::::::Formatnum bør absolutt foretrekkes som knapp, det gjør det lettere (les: mulig) å lese og endre tall i kilden, bruke maler som verdi, mm. Btd 23. jan 2009 kl. 16:25 (CET)

text: :::::: (red.konflikt) Nei det kan jeg ikke si. Men jeg synes 1234 km er like enkel å lese som , men enklere å forstå (for en som ikke vet hva en mal er) og tenkte jo at formatnum skulle brukes på store tall. Men jeg ser jo nå man ofte vil bruke nowrap. Ja, eneste grunn til å bruke formatnum er vel kommaproblematikken eller? Her har du kanskje oversikt over om det skaper problemer for sortering i tabeller mv.? Hvis det er mulig å komme omkring evt. problemer med komma kunne det jo bare brukes nowrap (dersom det rettes opp i de tall som er skrevet med «.» og ikke «,». Mht til å flytte siden er jeg enig, men synes det kan være en fordel å utarbeide et (bra) forslag for siden å legge det frem. Så kan folk alltid gå hit og se på argumentene dersom de ønsker. På denne måte blir folk minst plaget av støy fra evt. uvedkommende diskusjon. Annonsering på Tinget eller Torget er bra (når vi kan legge frem et forslag som holder.) Mvh Prillen 23. jan 2009 kl. 16:38 (CET)
replies: text: ::::::: er sorterbar :-) Btd 23. jan 2009 kl. 16:42 (CET)
replies: text: :::::::: Hvilken forskjell er det da på  og formatnum (bortsett fra kommakorreksjonen)? Mvh Prillen 23. jan 2009 kl. 16:47 (CET)
replies: text: :::::::::  har sine begrensninger, men er vel først og fremst en mye tyngre operasjon.  Vær snill med serverne: Don't use it if you don't mean it. ;-) — the Sidhekin (d) 23. jan 2009 kl. 17:04 (CET)

text: :::::::::konfl.  er en mal som returnerer en skjult, maskinlesbar utgave av tallet før den kaller formatnum. Siden det maskinlesbare tallet kommer først kan oppføringen sorteres i dynamiske tabeller Btd 23. jan 2009 kl. 17:09 (CET)
(undent) Når både formatnum og nowrap kan brukes (altså med et tall uten enheter og ikke fra mal), foretrekker jeg formatnum fordi:
# Lesbarhet: SWYM (say what you mean) – poenget var formateringen av nummeret, ikke å unngå linjeskift.  Linjeskiftene er bare en bivirkning av en naïv nummerformatering: Den som leser teksten tar straks poenget om det står formatnum; står det nowrap må h*n lese innholdet for å finne meningen.
# Lesbarhet: Luft – formatnum gjør ingen forskjell på luft, så nummeret blir ikke klistret i piper og krøllparenteser.  Mer lesbar: «» («»); mindre lesbar: «» («»); dessverre ikke et alternativ: «» («»).
# Brukerfeil: KISS – med formatnum slipper brukeren å sørge for tusenskilletegnene, og vi slipper dermed også muligheten for tall som . :)
# Maler vs parserfunctions: KISS – en mal (som nowrap) kan utsettes for vandalisme; en parserfunction (som formatnum) kan ikke.  Maler kan også trenge oppdateringer av og til; det blir en tung jobb i jobbkøen om noen fikser en bug i nowrap – er der behov for en oppdatering av formatnum, holder det med en ny versjon av programvaren (tungt nok, forsåvidt, men det skjer fra tid til annen).  Og selv i vanlige situasjoner, er nowrap litt mer komplisert og vil trolig alltid være tyngre enn formatnum.
Ikke akkurat overveldende, men jeg ser heller ingen tungtveiende grunner til å foretrekke nowrap i denne situasjonen.  Vi trenger uansett begge. — the Sidhekin (d) 23. jan 2009 kl. 17:40 (CET)

text: :Til opplysning (nå et halvt år i etterkant): Se Wikipedia:Torget#Non-breaking_space_som_knapp_over_redigeringsvinduet (permalenke). —Kjetil_r 24. jul 2009 kl. 12:20 (CEST)
thread_title:  Tallformatering