Moduldiskussion:Formattal

Jeg har gjort koden mere forståelig for udenforstående

Jeg har netop gjort koden mere forståelig for udenforstående. En ren refaktorisering, uden nogen funktionsændring.

Jeg oprettede først, som det sig jo hør og bør ved refaktoriseringer, en række testcases på Moduldiskussion:Formattal/testcases, som alle bestod. Jeg testede også koden i min "modulsandkasse" på Modul:Sandbox/Jhertel/Formattal og dens testcases Modul:Sandbox/Jhertel/Formattal/testcases. Og efter ændringen bestod alle testene i Moduldiskussion:Formattal/testcases stadig. Jeg vil derfor konkludere, at funktionaliteten ikke er ændret med mine ændringer i koden – hvilket underbygger, at det faktisk var en ren refaktorisering som påstået. Og nu har vi unittests til at tjekke fremtidige ændringer. Yderligere testcases er naturligvis velkomne. --Jhertel (diskussion) 24. okt 2017, 01:40 (CEST)

Det er godt at du gør koden mere forståelig. Så kan det være at flere begynder at hjælpe med lua-programmering, og jeg har også selv tit problemer med at forstå koden. Det er også godt at du fandt fejlene. De skyldes vel at der er mere end to decimaler. Sider med disse fejl kommer med i Kategori:Sider med tal hvis format ikke kendes af formattal, men det ville også være godt hvis tallene ikke blev ændret.--Weblars (diskussion) 21. nov 2017, 23:00 (CET)

Tak for din opbakning, Weblars. Og tak for henvisningen til Kategori:Sider med tal hvis format ikke kendes af formattal, som jeg af en eller anden grund aldrig nåede til faktisk at tage et kig på. Der er jo en del sider dér. Det kunne være interessant at prøve at finde ud af, hvad der faktisk er galt med dem. Jeg prøvede med den første, Abia, men kunne ikke umiddelbart se brugen af Formattal dér – måske den bruges af infoboksen på en eller anden måde.

Jeg tænkte lidt på, om vi skulle gøre den slags fejl mere synlige end blot en tilføjelse til en kategori, for det viser jo ikke, hvor fejlen faktisk var. Det behøver ikke nødvendigvis være en stor fed rød fejlmeddelelse, men bare en eller anden, gerne diskret, angivelse af, hvor fejlen er. Måske bare en rød, hævet asterisk lige efter tallet (0.1234^*), som, hvis man holder musen over den, fortæller nærmere om, at der er en fejl (prøv det), og gerne endda mere præcist, hvad fejlen er (0.1234^*). Der kunne også være et link, som førte til et eller andet smart sted, som kunne hjælpe. Der skal selvfølgelig stadig tilføjes til en kategori. Jeg skal gerne implementere det, hvis du også synes det kunne være en god idé. Eller kender du til en lignende funktionalitet, som måske allerede er i brug i andre skabeloner?

Det ville i øvrigt være oplagt at indbygge funktionaliteten i sin egen skabelon eller eget modul, da den kunne være generelt anvendelig som diskret fejlangivelse i alle skabeloner, som kan fejle, men hvor fejlen ikke nødvendigvis skal give en stor rød fejltekst. Den kunne fx hedde {{Diskretfejl}}.

Hvad mente du i øvrigt med "men det ville også være godt hvis tallene ikke blev ændret"? --Jhertel (diskussion) 22. nov 2017, 21:07 (CET)

Ah, nu er jeg med: Tallene bliver jo ændret til noget ukorrekt, når input ikke er på en form, som er forståelig for modulet. Ja, det skal rettes. --Jhertel (diskussion) 22. nov 2017, 21:08 (CET)

Jeg har ledt og ledt efter formattal, men har som dig heller ikke kunnet finde ud af, hvor præcis den bliver brugt. Men jeg gætter på at det er i en af Geobox-skabelonerne. De lader i hvert fald til at være fællesnævner for de forskelliger sider i fejl-kategorien. I Abia findes en infoboks hvor feltet med indbyggertal er udfyldt med 2.833.999 <ref>[http://www.nigerianstat.gov.ng/index.php ''National Bureau of Statistics'', Nigeria], provisorisk resultat fra folketællingen 21. marts 2006.</ref>, altså ikke et rent tal pga referencen. Det er nok det som gør at Abia kommer med i fejlkategorien, og det tror jeg også gælder for de fleste (måske alle) de andre sider. Jeg ved ikke rigtig med den fejlmedelelse du foreslår, heller ikke selvom den er meget diskret, for de fleste folk bliver nok bare forvirrede af det. Måske hvis det var noget man kunne slå til kortvarigt, mens man søger efter fejlen, men mon ikke det bliver for svært? Du gættede rigtigt mht hvad jeg mente med "tallene ikke var rigtige". Men mon ikke vi kan finde ud af det, for skabelonen burde jo kunne håndtere decimaltal med mere end to decimaler, hvis tallet starter med 0 (eller punktum).--Weblars (diskussion) 22. nov 2017, 21:49 (CET)

Jeg tror det med de op til to decimaler skyldes, at Formattal prøver at gøre lidt mange ting: Den prøver nemlig at kunne håndtere input på både engelsk og dansk. Og tallet 1.234 bliver dermed tvetydigt: Er det 1,234 (lidt over 1) eller 1234 (lidt over tusind) på dansk? Derfor begrænsningen til 2 cifre, ifølge mit gæt. Men hvis man begrænsede den til kun at tage input skrevet på dansk (eller kun engelsk), så kunne den udvides til et vilkårligt antal decimaler. --Jhertel (diskussion) 23. nov 2017, 01:29 (CET)

Selv om jeg ingen forstand har på "sagerne" blander jeg mig. Såvidt jeg kan forstå, er formnum indbygget i Skabelon:Infoboks provins på "| indbyggere=". Hvis formnum skal være indbygget i infoboksen bør der indsættes en ekstra linje til ref "| indbyggere ref=". Så snart jeg fjernede ref fra "| indbyggere= 2833999" blev antal indbyggere korrekt vist som 2.833.999 og artiklen røg ud af Kategori:Sider med tal hvis format ikke kendes af formattal. Alle infobokse bør efter min mening udstyres med "| indbyggere ref=" for "| indbyggere =" og evt andre tal, der kan have været anvendt formnum på. Det har de faktisk på en wiki. mvh Per (PerV) (diskussion) 22. nov 2017, 22:14 (CET)

Ok, tak for din info. Det bekræfter min mistanke. Jeg tror dit forslag vil løse problemet, men den nye parameter skal så indsættes på alle de mange sider i fejlkategorien. Det vil være et stort arbejde. Jeg synes bare vi skal leve med de mange sider i fejlkategorien indtil videre, for jeg har ikke fundet nogen "forkerte" kommaer eller punktummer i indbyggertallene.--Weblars (diskussion) 22. nov 2017, 23:00 (CET)

Der er vel en anden udvej. At sætte formnum ud af funktion i infoboksen. Det er vel udelukkende et layout spørgsmål at den er der. Hvis formnum sættes ud af funktion i infoboksen vil man kunne se om der er nogle artikler med alvorlige problemer med formnum. mvh Per (PerV) (diskussion) 22. nov 2017, 23:15 (CET)

Fornemt, Per! Kom ikke og sig du ikke har forstand på det. :-) Jeg giver dig helt ret i at tal og referencer bør adskilles som du beskriver. Og ja, det er et stort arbejde, men det kan jo gøres stille og roligt. Det er en slags opgave jeg ikke har noget imod at sidde og meditere med - hvis blot jeg husker det. Alternativt kunne Formattal sådan set godt udvides til at håndtere referencerne (det kunne jeg godt implementere), men jeg kan bedre lide den anden løsning. Det kunne dog også være en kombination. --Jhertel (diskussion) 23. nov 2017, 01:29 (CET)

Tak for de pæne ord Jhertel. Jeg synes, vi i første omgang burde gå ind i Skabelon:Infoboks provins og slå {{formnum}} fra på "| indbyggere=", så vi får alle de "falske fejl" ud af Kategori:Sider med tal hvis format ikke kendes af formattal. Derefter burde vi kunne lave en subst af Skabelon:Infoboks provins → Skabelon:Infoboks provins/ny, hvor der er taget højde for problemerne, der eksisterer nu. Da vi overgik fra Skabelon:Infoboks land → Skabelon:Infoboks land2 lavede Steen en subst, som jeg efterfølgende indsatte i samtlige Skabelon:Infoboks land, der var godt 100. Det tog 2-3 uger, hvorefter vi kun havde een lande infoboks; men skal vi igang med den proces, bør vi nok inden gennemføre en seriøs diskussion om kravene til Skabelon:Infoboks provins. Det er sikkert ikke bare "| indbyggere ref=", der er behov for. Bør vi så ikke satse på også at hente data fra wikidata? For mig er Skabelon:Infoboks by blevet en "drøm" efter den store indsats af Lars, Gorbi og Jhertel! Vi kunne med rimelighed sætte os målet at automatisere Infoboks provins på samme måde. mvh Per (PerV) (diskussion) 23. nov 2017, 08:56 (CET)

Jeg har endnu ikke meget erfaring med skabelonerne, herunder Infoboks by, så her lytter jeg bare til de erfarne udi disse og bakker op om dit forslag, PerV. Uden helt at have sat mig nærmere ind i det. :-) --Jhertel (diskussion) 23. nov 2017, 09:56 (CET)

Ja, det er nok en god idé at få de falske positive væk fra fejlkategorien. Jeg har klikket på flere af siderne og har opdaget en side (Menabe), hvor formattal burde have virket, men ikke gjorde det. Jeg har også opdaget at det ikke kun er infoboks provins, men flere andre skabeloner, der er involveret. PerV, du nævner skabelon formnum, men det er ikke det samme som den skabelon vi snakker om her (formattal), selv om de vist kan nogenlunde det samme. Det ville da være godt at alle skabelonerne blev lige så gode som infoboks by, men det har nok længere udsigter. Den nemmeste måde at få de falske positive væk er nok at sørge for at formattal kan håndtere referencer og andet, der ofte står sammen med tallet i infoboksene. Forresten kan jeg stadig ikke finde ud af, hvor formattal er brugt i forhold til flertallet af siderne i fejlkategorien. Jeg har lavet en søgning, der burde vise de skabeloner der bruger formattal.--Weblars (diskussion) 23. nov 2017, 10:33 (CET)

Hej Weblars. Tak for søgningen, den ser nyttig ud. Jeg er kun kort forbi; skal i seng nu. Håber snart at kunne se nærmere på det. Tænker at Formattal kan sættes til blot at håndtere det førstkommende tal i strengen og samtidig lade alt hvad der kommer derefter være uberørt. Dermed vil referencer og sågar enheder ikke længere kunne slå den ud. Tænker det vil være relativt enkelt at implementere, og jeg gør det gerne. --Jhertel (diskussion) 25. nov 2017, 01:08 (CET)

Det lyder som en god ide. Du kender det måske allerede, men nederst på siden, når man redigerer modulet, findes en "Fejlsøgningskonsol", hvor man kan skrive noget. Hvis man f.eks. oppe i modulet lige efter den nuværende linje 54 indføjer en linje med teksten "mw.logObject(decimaler,'decimaler')" og man derefter går ned og skriver "print(p.formattal(mw.getCurrentFrame():newChild{title='Formattal', args={'2,833.67'}}))" i konsolvinduet og man til slut trykker enter (mens cursoren er i konsollen), så fremkommer under konsolvinduet: decimaler = "67" og resultatet 2.833,67. Det har jeg læst i Hjælp:Lua-fejlretning. Måske kan det hjælpe dig.--Weblars (diskussion) 25. nov 2017, 16:49 (CET)

Jeg kendte slet ikke den fejlsøgningskonsol og havde sjovt nok ikke engang selv opdaget at den var der. Tak for tippet! Den kan sikkert være nyttig, især til at forstå i detaljer, hvordan Lua og dens biblioteksfunktioner opfører sig. --Jhertel (diskussion) 25. nov 2017, 20:22 (CET)

Nu kan den håndtere referencer

Nu har jeg, svarende til diskussionen ovenfor, omprogrammeret Formattal, så den kan håndtere referencer sat efter tallet. Ja, faktisk håndterer den nu hvad som helst efter tallet. Den ser blot på, om argumentet starter med et tal på en af de former, den genkender. Hvis den gør, så omformaterer den tallet, men lader resten være, som det er. Dog fjernes HTML-kommentarer og indledende og afsluttende blanktegn (det er vist ment som en positiv funktionalitet, men det kan sagtens ændres). Jeg har lavet en ret lang liste af testcases til at teste, at den opfører sig ordentligt. Jeg har stadig ikke ændret den gamle fejl, at den i visse tilfælde af fejlagtigt input omformaterer tallene til ukorrekte tal; det er næste skridt. Men det med at håndtere referencer og andet efter tallet har tilsyneladende reduceret fejlraten til næsten nul; der er kun én reel fejl tilbage i kategorien Kategori:Sider med tal hvis format ikke kendes af formattal: Orsja; resten er testtilfælde, som vitterligt skal "fejle", eller som optræder i en brugers sandkasse. --Jhertel (diskussion) 26. nov 2017, 15:51 (CET)

Eftersom Formattal nu også kan sætte en stjerne med nøjere forklaring efter tal, der fejler, hvis man altså slår det til, vil jeg tillade mig at slå det til et øjeblik for at finde fejlen i Orsja. --Jhertel (diskussion) 26. nov 2017, 15:52 (CET)

Og det er slået fra igen, da det hurtigt og nemt viste fejlene:

1) Der var mellemrumstegn i tal som "- 12", hvilket jo blot var en ukorrekt skrivemåde (det er rettet i artiklen nu), og

2) manglende information var angivet med "-", hvilket Formattal opfatter som et negativt tal, som mangler cifre. Dette bør rettes i {{Infoboks vejr}}, så der er en veldefineret håndtering af, hvordan man angiver ukendt information – p.t. skriver den "- °C" eller "Ukendt °C", hvis man angiver "-" eller "Ukendt", hvilket jo er ukorrekt (det skal blot være "-" eller "Ukendt"), og den laver en manglende tabelcelle, hvis man efterlader værdien tom, hvilket ikke ser godt ud. {{Infoboks vejr}} bør slet ikke kalde Formattal, hvis der er angivet en parameterværdi svarende til "ukendt". --Jhertel (diskussion) 26. nov 2017, 16:10 (CET)

Jeg har nu udvidet Formattals kompetence til at acceptere mellemrumstegn mellem fortegn og resten af tallet. Den fjerner det dog i output, da det jo er ukorrekt skrivemåde. --Jhertel (diskussion) 26. nov 2017, 16:38 (CET)

Forslag til ændring, 3 eller flere decimaler

Jeg kommer hertil fra Andorra, hvor jeg undrede mig over at landets vandareal var angivet til 1.214 km2. Det skyldes at {{Infobox land}} sender arealet igennem {{formattal}}, som opfatter det fuldstændig korrekte decimaltal 1,214 som et engelsk heltal med tusindadskiller.

Jeg er klar over, at funktionaliteten er beskrevet i skabelonen - men det kan ikke forventes at brugeren af infoboks-skabelonerne kender til denne begrænsning. Og der er ikke nogen nem workaround - man kan ikke angive Andorras søterritorie korrekt, når det skal gennem formateringen.

Jeg vil derfor foreslå, at funktionen ændres med følgende funktionalitet:

• 1,234 -> 1,234
• 1,2345 -> 1,2345
• 1.2345 -> 1,2345
• 1234.567 -> 1.234,567
• 1.234 -> 1.234

mens nedenstående bibeholdes:

• 1,234.567 -> 1.234,567
• 1.234,567 -> 1.234,567
• 1,234,567 -> 1.234.567
• 1.234.567 -> 1.234.567

Logikken er: Hvis vi får et korrekt tal på dansk, så skal det fortolkes på dansk. Er det ikke korrekt på dansk, men på engelsk, så fortolkes det på engelsk.

Det "store problem" er selvfølgelig, hvor mange steder vi ødelægger eksisterende funktionalitet ved at ændre i fortolkningen af "1,234". Det ligner dog noget, man ville kunne løse med en bot (når først problem-skabelonerne er identificeret.

Kommentarer? NisJørgensen (diskussion) 6. okt 2018, 15:38 (CEST)

Jeg synes at det er problematisk at ændre den dokumenterede virkning af kode som bruges mange steder, og derved risikere at ødelægge eksisterende korrekt brug. Begrænsningen på højst 2 decimaler er nødvendig for at kunne se forskel på decimaltegn og tusindadskiller.

Kan du give nogle eksempler hvor det er nødvendigt med 3 eller flere decimaler? For Andorras vedkommende er kilden til vandareal en liste med søer hvis areal er angivet med 0,1 hektars nøjagtig (0,001 km²). Der står ingen steder at listen er komplet eller et samlet tal for vandareal. Selv hvis listen er komplet, og selv hvis floder og andre vandløb ignoreres (hvilket vil være en fejl i sig selv), kan man ikke bare addere over 50 tal og forvente at resultatet har samme store nøjagtighed som addenderne. Så et vandareal i Andorra på 1,214 km² er overdrevent nøjagtigt og udtryk for dårlig førstehåndsforskning. --Kartebolle (Dipsacus fullonum) (diskussion) 7. okt 2018, 00:41 (CEST)

Jeg kan godt følge problemet med at ændre i eksisterende funktionalitet. Det lader ikke til at der er mange steder hvor funktionen bruges ved decimaltal - endnu. Tilsvarende kan jeg heller ikke umiddelbart finde nogen steder, hvor der er brugt angelsaksiske tusindadskillere ved {{formattal}}, så jeg tror en funktionalitetsændring vil have lille betydning - i dag. Der er til gengæld masser af steder, hvor der er 3 decimaler på andre tal - fx BNP-tal, der er opgivet i "mia USD".

Efter at have tænkt efter, tror jeg at jeg er uenig i beslutningen om at tillade 2 kolliderende talformater i samme skabelon. Det vil uvægerligt føre til, at nogen bliver overrasket på et tidspunkt. Jeg er klar over, at begrænsningerne er dokumenteret. Men dokumentationen bliver ikke nødvendigvis læst af den der bruger {{formattal}} i en skabelon, og næppe nogensinde af dem der udfylder data i {{Infoboks land}} og lignende (før de kommer til Andorra ...). NisJørgensen (diskussion) 7. okt 2018, 09:21 (CEST)

Der findes Kategori:Sider med tal hvis format ikke kendes af formattal, hvor Andorra lige nu er med som den eneste artikel. Vi kan vel bare nøjes med at holde øje med den kategori. Jeg går ud fra at Andorra forsvinder fra kategorien, hvis vi skriver vandarealet som 1,21 km².--Weblars (diskussion) 7. okt 2018, 18:10 (CEST)

Jeg har rettet vandarealet for Andorra i Special:Diff/9694537 som foreslået af Weblars, og ja, artiklen er nu ude af fejlkategorien. Som jeg opfatter det, er {{Formattal}} beregnet til at indsætte tusindadskillere i store tal hvor der enten ikke er decimaler (som f.eks. indbyggertal) eller højst få decimaler (som f.eks. arealtal for et land), og lavet til også at fungere hvis de er indsat i tallet i forvejen. Hvor der er kan forventes flere end 2 decimaler, bør man ikke bruge skabelonen, men bruge de angivne tal direkte. Det vil være meget sjældent at der er mange decimaler i et tal større end 1000 (og som derfor kan bruge tusindadskillere) da det som regel vil betyde et urealistisk stort antal betydende cifre. --Kartebolle (Dipsacus fullonum) (diskussion) 8. okt 2018, 09:57 (CEST)