Wikikids:Clubhuis: verschil tussen versies
(Gearchiveerd) |
(→even een vraagje: nieuwe subkop) |
||
| Regel 42: | Regel 42: | ||
Met vriendelijke groet, |
Met vriendelijke groet, |
||
{{Gebruiker:Hippogryph/Handtekening}} 15 mei 2023 21:38 (CEST) |
{{Gebruiker:Hippogryph/Handtekening}} 15 mei 2023 21:38 (CEST) |
||
| + | |||
| + | == even een vraagje == |
||
| + | |||
| + | is het misschien handig om wikikids:opleten waar je mensen kan in toetsen die in de gaten worden gehouden door de computer |
||
Versie van 16 mei 2023 11:09
| Welkom in het Clubhuis! | |
 |
Welkom in het Clubhuis van WikiKids! Hier kun je als (vaste) gebruiker of volwassene overleggen over onderwerpen die over WikiKids gaan. Wil je een nieuw bericht plaatsen? Klik dan op "nieuw bericht" bovenaan de pagina of klik hieronder.
|
Wiki regels
Is het niet handig om bij de regels te zetten bij erge overtredingen doen we aangifte bij de politie
- Dat doen we voor zover ik weet niet, dus nee, dat is denk ik niet nodig. Groempdebeer • Vragen? Sur Fr:Vikidia 11 mei 2023 07:31 (CEST)
- Er zal nooit aangifte worden gedaan bij de politie voor zware overtredingen op WikiKids. Het ergst ik hier heb gezien is dat iemand porno uploadde naar WikiKids maar meestal is dat gewoon meteen een permban + ip ban voor een jaar (dit is tevens maar 3 a 4 keer gebeurd en al snel verwijderd voordat het veel ogen kon doen bloeden). Een paar keer is er gemail met ouders/schoolleiding maar verder dan dit gaat het ook niet.
DeGroteEmojii 11 mei 2023 08:29 (CEST)
- Inderdaad. WikiKids doet geen aangifte bij de politie. Dus het is niet nodig. Mvg,
Mike1023 11 mei 2023 11:53 (CEST)
- maar als er dan een drijgement komt Thijmen4🍐EindelijkWeerThuis😀 11 mei 2023 11:58 (CEST)
- Dat gaat dan gewoon ongedaan gemaakt worden en de gebruiker geblokkeerd. Daarnaast is het nog nooit gebeurd dat iemand een serieus dreigement op WikiKids heeft gezet. Je kunt zeggen dat de "aangifte bij de politie" mensen kan laten afschrikken, maar zo'n sfeer lijkt me niet voor iets als een wiki. DeGroteEmojii 11 mei 2023 12:17 (CEST)
- Inderdaad. Hetgeen wat het dichtst in de buurt komt van "een bedreiging" is als een gebruiker zegt dat hij/zij gewoon doorgaat als hij/zij meerdere keren gewaarschuwd is. Dat is zeker vervelend, maar niet strafbaar volgens de wet. Ik denk ook dat een blokkade al genoeg afschrikt voor de meeste gebruikers. Mvg, Mike1023 11 mei 2023 12:23 (CEST)
- Inderdaad. Hetgeen wat het dichtst in de buurt komt van "een bedreiging" is als een gebruiker zegt dat hij/zij gewoon doorgaat als hij/zij meerdere keren gewaarschuwd is. Dat is zeker vervelend, maar niet strafbaar volgens de wet. Ik denk ook dat een blokkade al genoeg afschrikt voor de meeste gebruikers. Mvg,
- Dat gaat dan gewoon ongedaan gemaakt worden en de gebruiker geblokkeerd. Daarnaast is het nog nooit gebeurd dat iemand een serieus dreigement op WikiKids heeft gezet. Je kunt zeggen dat de "aangifte bij de politie" mensen kan laten afschrikken, maar zo'n sfeer lijkt me niet voor iets als een wiki.
- maar als er dan een drijgement komt Thijmen4🍐EindelijkWeerThuis😀 11 mei 2023 11:58 (CEST)
- Inderdaad. WikiKids doet geen aangifte bij de politie. Dus het is niet nodig. Mvg,
- Er zal nooit aangifte worden gedaan bij de politie voor zware overtredingen op WikiKids. Het ergst ik hier heb gezien is dat iemand porno uploadde naar WikiKids maar meestal is dat gewoon meteen een permban + ip ban voor een jaar (dit is tevens maar 3 a 4 keer gebeurd en al snel verwijderd voordat het veel ogen kon doen bloeden). Een paar keer is er gemail met ouders/schoolleiding maar verder dan dit gaat het ook niet.
Eerste keer laden Portalen
Ff centraler geplaatst: De eerste keer laden van de (meeste) portalen duurt veel te lang (soms wel meer dan 30 sec). Portalen Amerika, Mexico en Canada sowieso in Android. Dit geldt ook voor Chrome en Edge. Staan veel plaatjes op deze portalen. Eenmaal in cache, gaat het wel snel. 2 sec. schijnt voor de gemiddelde bezoeker al veel te zijn, daarna klikken ze weg. Het lijkt wel of de capaciteit van de server tekort schiet. Misschien is dat mede de reden dat portalen slecht bezocht worden. Vraag me af of het ook iets te maken heeft met de foutcodes die ik deze week langs zag komen. Gr. Hanssain (overleg) 12 mei 2023 08:48 (CEST)
- Wanneer ik met de verschillende webpagina URL's test op https://pagespeed.web.dev/?hl=nl, dan krijg ik vaak de volgende tip: Bestandsindelingen zoals webP en avif bieden vaak betere compressie dan png of jpeg. Dit zorgt voor snellere downloads en minder dataverbruik. Dit geldt vooral voor mobiel. In de rapporten kun je ook zien waar de plaatjes vandaan gehaald worden: Merendeel een src opdracht naar Commons en een deel naar wikikids zelf. Mijn conclusie is dat als er kleinere bestanden worden gebruikt dat dit echt scheelt (dat is ook al gebleken bij het PIM-systeem). Het kleiner schalen van een afbeelding in de opmaak staat hier dus los van. Ook wordt er gesproken van tekst compressie. Gr. Hanssain (overleg) 12 mei 2023 11:53 (CEST)
- Het is niet alleen een kwestie van bestandsgrootte, maar kennelijk maakt het ook verschil of dat de afbeelding bij Commons vandaan komt of bij WikiKids zelf. Ik ben geen computertechneut, maar het trage laden zou ook kunnen komen door een slechte verbinding met commons (verkeerde poort of zo). De landen van de wereld had Rots61 'teruggezet'. Ze laden weer langzamer, maar sneller dan eerst. Had Rots61 al die vlaggen via zijn gebruikerspagina zeg maar lokaal (bij wikikids) staan? Zou het iets te maken hebben met dat cURL? Iets met geen host kunnen vinden? Gr. Hanssain (overleg) 12 mei 2023 21:38 (CEST)
- Nee, het enige dat ik aanpaste was dat je de afbeeldingen gebruikte in de tekst ipv met een sjabloon. Die vlaggen waren precies dezelfde als die op het artikel stonden, dus afkomstig van Commons. Het heeft waarschijnlijk niets te maken met die foutmeldingen rondom dat cURL. De pagina's laadden al eerder traag.
Rots61 Overleg· (MOD) 12 mei 2023 22:28 (CEST)- Even voor alle duidelijkheid; @Rots61, je had de vorige keer de beeldbestanden in groente verkleind. Ik zie dat ook aan de bestandsnaam, want dat gaat b.v. Vooraf met 640px ... Klopt het dat die kleine bestanden nog wel bij commons staan? Het eerste keer laden van groente duurt n.l. nog steeds lang. De hamvraag is of dat we voor de portalen in ieder geval de kleinst mogelijke bestanden moeten gaan gebruiken en of deze dan lokaal (wikiserver) moeten plaatsen of bij commons kunnen laten staan (maar dan wel 'geforceerd' de kleine versie laten ophalen). Ik heb b.v. bij Kunst en cultuur afbeeldingen op 300px in de opdrachtregel qua opmaak staan. Qua bestand zou dan 320 of 640 px genoeg moeten zijn. Sommige waren zelfs meer dan 3000px. 7 afbeeldingen heb ik de kleine versie nu lokaal neergezet. Wat is de beste aanpak en wat kunnen we zelf doen? Is er evt. een tool voor? Nu heb ik voor portaal kunst en cultuur de kleine versies gedownload en via "eigen werk" de kleine versies geupload (maar het is idd geen eigen werk). Gr. Hanssain (overleg) 13 mei 2023 13:35 (CEST)
- Ik heb niets gedaan met de afbeeldingen op groente. Het wikisysteem werkt zo dat de afbeeldingen automatisch kleiner worden voor de bezoeker en gebruiker (iedereen). Afbeeldingen van Commons worden op volle grote gedownload op de computer (server) van WikiKids. Pas als alle afbeeldingen van een pagina gedownload zijn op de computer van WikiKids, wordt de pagina getoond aan de gebruiker. Alle afbeeldingen van WikiKids staan al op de server van WikiKids, en hoeven niet gedownload te worden. Hierdoor werken afbeeldingen van WikiKids 'sneller' dan afbeeldingen van Commons. Doordat je de afbeeldingen (kleiner) upload op WikiKids wordt het laden dus sneller voor de bezoekers (iedereen). Dat komt vooral doordat je ze upload op WikiKids. Het is lastig om uit te leggen doordat je alles moet typen. Misschien is het mogelijk om een keer met een geluidsverbinding te communiceren. Zo heb je veel minder ruis op de lijn, en kun je alles in een keer uitleggen. Rots61
Overleg· (MOD) 13 mei 2023 18:21 (CEST)- Je uiteenzetting is helder en eigenlijk had ik het zo al wel begrepen. Maar wat me zeg maar dwars zit is het enorme tijdverschil tussen beide wegen. Ook de praktijk laat zien dat de kleine icons die lokaal staan zoals je beschrijft veel sneller laden.
- Ik heb niets gedaan met de afbeeldingen op groente. Het wikisysteem werkt zo dat de afbeeldingen automatisch kleiner worden voor de bezoeker en gebruiker (iedereen). Afbeeldingen van Commons worden op volle grote gedownload op de computer (server) van WikiKids. Pas als alle afbeeldingen van een pagina gedownload zijn op de computer van WikiKids, wordt de pagina getoond aan de gebruiker. Alle afbeeldingen van WikiKids staan al op de server van WikiKids, en hoeven niet gedownload te worden. Hierdoor werken afbeeldingen van WikiKids 'sneller' dan afbeeldingen van Commons. Doordat je de afbeeldingen (kleiner) upload op WikiKids wordt het laden dus sneller voor de bezoekers (iedereen). Dat komt vooral doordat je ze upload op WikiKids. Het is lastig om uit te leggen doordat je alles moet typen. Misschien is het mogelijk om een keer met een geluidsverbinding te communiceren. Zo heb je veel minder ruis op de lijn, en kun je alles in een keer uitleggen.
- Even voor alle duidelijkheid; @Rots61, je had de vorige keer de beeldbestanden in groente verkleind. Ik zie dat ook aan de bestandsnaam, want dat gaat b.v. Vooraf met 640px ... Klopt het dat die kleine bestanden nog wel bij commons staan? Het eerste keer laden van groente duurt n.l. nog steeds lang. De hamvraag is of dat we voor de portalen in ieder geval de kleinst mogelijke bestanden moeten gaan gebruiken en of deze dan lokaal (wikiserver) moeten plaatsen of bij commons kunnen laten staan (maar dan wel 'geforceerd' de kleine versie laten ophalen). Ik heb b.v. bij Kunst en cultuur afbeeldingen op 300px in de opdrachtregel qua opmaak staan. Qua bestand zou dan 320 of 640 px genoeg moeten zijn. Sommige waren zelfs meer dan 3000px. 7 afbeeldingen heb ik de kleine versie nu lokaal neergezet. Wat is de beste aanpak en wat kunnen we zelf doen? Is er evt. een tool voor? Nu heb ik voor portaal kunst en cultuur de kleine versies gedownload en via "eigen werk" de kleine versies geupload (maar het is idd geen eigen werk). Gr. Hanssain (overleg) 13 mei 2023 13:35 (CEST)
- Nee, het enige dat ik aanpaste was dat je de afbeeldingen gebruikte in de tekst ipv met een sjabloon. Die vlaggen waren precies dezelfde als die op het artikel stonden, dus afkomstig van Commons. Het heeft waarschijnlijk niets te maken met die foutmeldingen rondom dat cURL. De pagina's laadden al eerder traag.
- Het is niet alleen een kwestie van bestandsgrootte, maar kennelijk maakt het ook verschil of dat de afbeelding bij Commons vandaan komt of bij WikiKids zelf. Ik ben geen computertechneut, maar het trage laden zou ook kunnen komen door een slechte verbinding met commons (verkeerde poort of zo). De landen van de wereld had Rots61 'teruggezet'. Ze laden weer langzamer, maar sneller dan eerst. Had Rots61 al die vlaggen via zijn gebruikerspagina zeg maar lokaal (bij wikikids) staan? Zou het iets te maken hebben met dat cURL? Iets met geen host kunnen vinden? Gr. Hanssain (overleg) 12 mei 2023 21:38 (CEST)
Mijn indruk is dat juist het dataverkeer met de (grote) afbeeldingsbestanden vanaf commons zoals jij het beschrijft de vertragende factor is. En daar willen we nou juist iets aan doen. Dus wat is wijsheid? Ik heb een voorstel: laten we Groente als voorbeeld nemen. Die hebben al de bestanden met lage resolutie, maar die staan op commons. We kijken wat de prestatiecijfers zijn op https://pagespeed.web.dev/?hl=nl met de huidige vorm. Dan maken we (tijdelijk) een kopie in de wikiruimte met de titel groente 2. Hiervan downloaden we dezelfde bestanden naar WikiKids en zetten er het achtervoegsel KL bij in de bestandsnamen en veranderen dat in de brontekst van groente 2 en meten hiervan ook de prestaties. Lijkt je dat wat? Gr. Hanssain (overleg) 13 mei 2023 22:16 (CEST)
- Dat kan inderdaad. Als ik nu Groente bekijk heb ik direct resultaat (86 ms). Ook als ik een andere browser gebruik (geschiedenis en cache van de browser geleegd) heb ik ook amper vertraging (74 ms). Ook op de mobiele telefoon krijg ik bij twee 3 browsers (Chrome, Firefox, Brave) binnen 1 seconde de pagina na het legen van de cache van de browser. Terwijl dat eerder (40.000 tot 80.000 ms (40 tot 80 seconden) was). Dat komt omdat dit probleem vanaf nu enkel eens in de 7 dagen een probleem is voor 1 persoon, Fab heeft dat aangepast. Daarom denk ik dat het niet nodig is om alles up te loaden op WikiKids. De tijdswinst die je er mee boekt, is bijna nul. Ook op de website geeft hij een redelijk normale score, niets om je druk over te maken. Ook op verschillende browsers getest, komt hetzelfde resultaat uit. Rots61
Overleg· (MOD) 13 mei 2023 22:56 (CEST)
- Dat kan inderdaad. Als ik nu Groente bekijk heb ik direct resultaat (86 ms). Ook als ik een andere browser gebruik (geschiedenis en cache van de browser geleegd) heb ik ook amper vertraging (74 ms). Ook op de mobiele telefoon krijg ik bij twee 3 browsers (Chrome, Firefox, Brave) binnen 1 seconde de pagina na het legen van de cache van de browser. Terwijl dat eerder (40.000 tot 80.000 ms (40 tot 80 seconden) was). Dat komt omdat dit probleem vanaf nu enkel eens in de 7 dagen een probleem is voor 1 persoon, Fab heeft dat aangepast. Daarom denk ik dat het niet nodig is om alles up te loaden op WikiKids. De tijdswinst die je er mee boekt, is bijna nul. Ook op de website geeft hij een redelijk normale score, niets om je druk over te maken. Ook op verschillende browsers getest, komt hetzelfde resultaat uit.
Het blijft vreemd. Zou je voor mij eens het volgende willen proberen: om vanaf het PIM-systeem verschillende portalen op te vragen. Zitten er bij jou dan traag ladende bij? Op mijn Android wel namelijk. Gr. 13 mei 2023 23:18 (CEST)
- Zojuist 5 portalen geprobeerd: 4 ervan laden traag (5 tot 10 seconden). Als ik daarna die portalen laad op een andere browser, laden die portalen snel (1 tot maximaal 2 seconden). Probeer het maar eens bij de portalen Economie, Sport, Dierentuin, Woordenschat of Wonen. Deze laden nu snel. Dat komt omdat ik ze heb bezocht. Daardoor zijn alle plaatjes op de server van WikiKids opgeslagen voor 7 dagen. Alle bezoekers in die 7 dagen hebben dan een snelle verbinding, en na 7 dagen is er weer 1 iemand met een trage verbinding. Rots61
Overleg· (MOD) 13 mei 2023 23:40 (CEST).
wikikids regels
kunnen de regels worden aangepast om geen chat gpt te gebruiken Thijmen4🍐EindelijkWeerThuis😀 12 mei 2023 12:52 (CEST)
- Dag Thijmen, enkele weken geleden is deze regel ingevoerd. Op WikiKids:Regels staat al "Het is niet toegestaan om teksten (deels) te laten schrijven door ChatGPT of andere AI (kunstmatige intelligentie)." onder het kopje "Kopiëren". Dit staat tevens op het Portaal:Kids uitgelegd. Mvg, Mike1023 12 mei 2023 12:55 (CEST)
Grote schoonmaak
Artikelen in de onderstaande categorieën moeten worden verbeterd, samengevoegd, aangepast of correct worden opgemaakt:
- Categorie:Wikikids:Verbeteren (17)
- Categorie:Wikikids:Moeilijk (14)
- Categorie:Wikikids:Opmaak (7)
- Categorie:WikiKids:Samenvoegen (8)
- Categorie:WikiKids:Splitsen (1)
Met vriendelijke groet, Hippogryph ♦ Overleg · (MOD) 15 mei 2023 21:38 (CEST)
even een vraagje
is het misschien handig om wikikids:opleten waar je mensen kan in toetsen die in de gaten worden gehouden door de computer