Wikipedia:SHEIC/Archief/2007-12

Datum/tijd laatste wijziging van een pagina weergeven

Is het mogelijk dat ik op pagina 'A' zeg "pagina 'B' is voor het laatst gewijzigd op '15 dec 2007 22:03 (CET)'"? Ik heb op extensions gezocht, maar kon zo snel niks vinden... CaAl (overleg) 15 dec 2007 22:03 (CET)

Voor zover ik weet is dit niet mogelijk. Annabel_(overleg) 16 dec 2007 10:41 (CET)

Naamgeving opmaaktalen webdesign

Naar aanleiding van diverse editwars en niet-zo-vriendelijke overlegpogingen tussen diverse gebruikers wil ik het volgende aankaarten. Er bestaan nl. artikelen HyperText Markup Language, Extensible Markup Language, Extensible HyperText Markup Language en Wireless Markup Language. Maar wat schetst mijn verbazing, het wordt niet geaccepteerd dat het artikel C-HTML wordt hernoemd naar het gezien de standaard correcte Compact HyperText Markup Language. Rara. Ik snap het niet meer. Gebruiker:Abnormaal stelt volkomen terecht voor het artikel te hernoemen maar wordt "teruggefloten" (da's een eufemisme) door Gebruiker:GijsvdL, Gebruiker:Erik Baas en Gebruiker:LimoWreck. Reden: het artikel heet al jaren zo en dan hoor je eerst te overleggen. Omdat de links dan verkeerd gaan staan, of zo. So what? Die links kun je corrigeren, eventueel met een botje, kleine moeite toch. Eenduidigheid is een must, op deze manier verwar je alleen maar de leek die wil leren over de opmaaktalen. Kwalijke zaak. Wie denkt er mee? Ik ben van plan om C-HTML te hernoemen naar Compact HyperText Markup Language maar heb weinig zin in een editwar te belanden. Laat het duidelijk zijn dat ik op Overleg:C-HTML geen enkel argument heb gelezen dat overtuigend aangeeft dat "C-HTML" de enig mogelijke correcte benaming is. Groet eVe ￨ Roept u maar! 15 dec 2007 15:46 (CET)

Er zal gekozen moeten worden voor één van beide vormen, dus óf allemaal voluit gescrhreven, óf allemaal afgekort (en dat laatste heeft mijn voorkeur). Verder: dat mijn naam in je lijstje opduikt is niet helemaal terecht, ik maakte alleen bezwaar tegen de vreemde manier van linken, waarbij soms bewust voor linken naar een redirect werd gekozen, en soms juist weer niet, met als enig doel (?) de volledige titel als popupje te kunnen tonen bij de link. - Erik Baas 15 dec 2007 17:09 (CET)

Sorry dat ik je naam noem waar hij niet thuishoort - ik zag dat jij, net als LimoWreck en Gijs, een bewerking van Abnormaal had teruggedraaid dus vandaar dat ik je in hetzelfde rijtje "schaarde". Ik ben het overigens met je eens dat een van beide vormen gekozen moet worden, en ik kan me goed vinden in het standpunt van Abnormaal dat het voor een leek prettig is de volledige naam in een popupje te zien. Ik zie er het nadeel ook niet zo van in om via een redirect in een artikel terecht te komen, als je maar goed terecht komt, toch. Dank voor het meedenken, ik hoop nog op reacties van anderen. Groet, eVe ￨ Roept u maar! 15 dec 2007 22:16 (CET)

(na bwc): Een uniforme naamgeving is zowieso nodig. Persoonlijk ben ik voor het gebruik van de voluitgeschreven naam van de opmaaktaal en redirects voor de afkortingen naar het artikel. De naam van de opmaaktaal is, zoals je aangeeft, niet C-HTML maar "Compact HyperText Markup Language", dus dat laatste zou ook de paginanaam moeten zijn. Annabel_(overleg) 15 dec 2007 22:18 (CET)

Ik ben het hier ook mee eens. Waarbij het mij lijkt dat C-HTML zelfs fout is. De externe link op de pagina C-HTML verwijst naar een document dat consequent Compact HTML gebruikt. En een korte zoekactie op google levert wel regelmatig cHTML en CHTML op, maar vrijwel niet C-HTML ([1]). Bij andere onderwerpen in de nederlandse wikipedia worden afkortingen meestal ook uitgeschreven (zoals NAVO en BBC). Dus waarom hier niet?

Een soortgelijke situatie is er overigens ook bij XSL Formatting Objects en XHTML Basic waar ook een afkorting in de naam zit. $\sim$ Wimmel 16 dec 2007 00:31 (CET)

In bijvoorbeeld Categorie:Computerstandaard en Categorie:XML-gebaseerde standaard (en er zijn meer categoriën) worden meerdere artikelen met afkortingen aangegeven. Ook de Sjabloon:Webdesign die op betreffende pagina's staat gebruikt afkortingen. Zoekend in zo'n categorie herken ik sneller een artikel bij zijn afkorting dan bij een voluit geschreven naam. Wat de voluit geschreven naam is die bij een afkorting hoort is meestal het minst bekend. Dus dan weet je al niet waar je naar moet zoeken. Ik zou dan ook graag alle betreffende artikelen met de afkorting in de titel zien. --VanBuren 16 dec 2007 11:12 (CET)

Voor een groep is XML duidelijk terwijl een andere groep Extensible Markup Language in de tekst begrijpelijker vinden. Het combineren van afkorting en verklarende tekst (zoals in beide links in voorgaande zin) kan de drempel voor beide groepen verlagen. AbNormaal 18 dec 2007 03:08 (CET)

Inderdaad. (Misschien kan een botje alle bestaande links aanpassen naar die manier). Als je zoekt naar een bepaalde term, vind je ook beide vanwege de redirect. Dus hoe het artikel heet, maakt dan dus op zich niets uit. Dan lijkt het me logisch om consequent te zijn met de naamgeving. $\sim$ Wimmel 18 dec 2007 19:53 (CET)

Zie commentaar van Van Buren. Een artikel als HTML kan je weliswaar voluit schrijven: daar heb je rechtstreeks de afkorting met zijn betekenis. Bij samenstellingen is het echter absurd om te blijven voluit spellen (en vaak zelfs onwerkbaar). C-HTML of cHTML of CHTML of hoe je het ding ook wil noemen [2], is gewoon "Compact HTML" (desnoods gebruik je dat als artikelnaam). De volle betekenis van het naamsonderdeeltje "HTML" is daar totaal van geen belang meer; zie dat als bestaand woorddeel. "XML-editor" ga je ook niet meer voluit schrijven. NAVO-codenaam heet ook niet Noord-Atlantische Verdragsorganisatiecodenaam. Air France-KLM of KLM Cargo worden ook niet voluit gespeld als Air France-Koninklijke Luchtvaart Maatschappij en Koninklijke Luchtvaart Maatschappij Cargo. EHBO-koffer noem je toch ook niet Eerste Hulp Bij Ongevallenkoffer ? Eenmaal de afkorting als entiteit er is, en als dusdanig slechts een onderdeeltje van een langere artikelnaam vormt (de betekenis van de afkorting is dan dus bijzaak), hoef je toch niet zo absurd de toen deze volledig open te trekken zeker? Dat is nóch informatief, nóch duidelijk, nóch de courante naam. --LimoWreck 19 dec 2007 00:02 (CET)

En ook eens met Erik Baas: links die via 1 redirect netjes terechtkomen hoeven helemaal "opgelost" te worden (staat ook ergens als advies in bepaalde richtlijnen/tips in de Wikipedia: naamruimte).--LimoWreck 19 dec 2007 00:07 (CET)

Uiteraard zijn de afkortingen bekende benaming daar is niets mis mee. Het oplossen van redirects is een vrij zinloze bezigheid. Wil echter het gebruik van bijvoorbeeld WTC stimuleren zodat iedereen die niet direct bij WTC aan World Trade Center denkt geholpen wordt met een hint. Deze hulp is voor bekende met het vakjargon overbodig maar bedoeld om het artikel voor een groter publiek toegankelijker te maken. Wie kent immers alle afkortingen op alle vakgebieden ?? Concreet is de vraag nu: wat is er mis met het toevoegen van verklarende tekst in de vorm van een hint aan een link ?? AbNormaal 19 dec 2007 01:19 (CET)

Het idee is niet verkeerd (!), maar de uitvoering door links "om te leggen" naar redirectpagina's is niet goed: er zijn (m.i. terecht) doorlopend mensen en botjes bezig om zulke "omleidingen" te corrigeren. En een lezer die wil weten wat een term betekent kan toch op de link klikken en er op de betreffende pagina alles over lezen? Voor afkortingen die geen link zijn heb ik het wel eens toegepast, omdat me dat weer wel nuttig lijkt. Eigenlijk zou een dergelijke optie voor links wel mooi zijn: een derde parameter die als "hint" getoond wordt, in plaats van de titel van de gelinkte pagina. Maar ja, dat vergt een (waarschijnlijk nogal ingrijpende) uitbreiding van de software, en dat ga ik dus niet voorstellen (al was het alleen maar omdat ik liever wil dat bug 1629 eerst eens wordt opgelost). - Erik Baas 19 dec 2007 03:17 (CET)

Als je aanneemt/afspreekt dat artikelen met een wat kriptischenaam (afk.) ook gewoon benaderbaar zijn met een meer verklarende naam (via redirect) dan zijn er twee voordelen. 1) In artikel mag WTC, World Trade Center, WTC of World Trade Center naar eigen inzicht gehanteerd worden. 2) Daarnaast kom je bij het artikel met de zoek term WTC maar ook met World Trade Center. Dit is volgens mij voor veel (duizenden) artikelen al zo. Een derde parameter is dan ook gewoon niet nodig. Het is voor mij een regulier gebruik van redirect en ook de juist de kracht van redirects, dit is geen nieuw concept. De hint is juist toegevoegd om de noodzaak van doorklikken weg tenemen. Het veranderen van een link die via een doorverwijspagina (GEEN redirect) loopt is uiteraard wel nuttig. AbNormaal 20 dec 2007 00:22 (CET)

Maar de "noodzaak tot doorklikken" wordt (meestal) niet weggenomen: wie, nieuwsgierig naar b.v. "C-HTML", de tooltip bekijkt, en daar "Compact HyperText Markup Language" ziet staan, wordt nog niet echt veel wijzer. De afkorting wordt verklaard, maar meer ook niet. Het doel wordt dus pas bereikt als je het complete artikel in de tooltip opneemt. - Erik Baas 20 dec 2007 00:31 (CET) (Verzoeke de laatste zin niet serieus te nemen)

Ok, de noodzaak van doorklikken verminderen (prettig lezen) is niet ongewenst en haalbaar.AbNormaal 20 dec 2007 00:39 (CET)

< in wiki tekst behouden

Als ik < tussen <pre><nowiki>..</nowiki></pre> is het resultaat <. Door er < neer te zetten, komt er wel het juiste te staan: <. Maar als het om javascript code gaat, wil ik de broncode niet aanpassen, om het in wikipedia er goed uit te laten zien. Weet iemand hoe ik dat voor elkaar kan krijgen?

Voorbeeld zo klopt de code in het bewerkingsscherm (maar is het fout in de wiki pagina):

el.innerHTML += "<a href='#test'></a></a>";

Zo ziet het in de wiki pagina goed eruit:

el.innerHTML += "<a href='#test'>&lt;/a&gt;</a>";

Door het te splitsen, lijkt het wel te werken; zowel in het bewerkingsscherm als de wiki pagina is nu dezelfde geldige code te zien:

el.innerHTML += "<a href='#test'>&" + "lt;/a&" + "gt;</a>";

Maar dit komt de leesbaarheid niet ten goede. Weet iemand een alternatief? $\sim$ Wimmel 9 dec 2007 20:08 (CET)

Met <pre><source lang="javascript"></source></pre> kan je automatisch de kleurformattering van broncode weergeven. Bedoel je dus zoiets als:

el.innerHTML += "<a href='#test'>&lt;/a&gt;</a>";

Ik heb deze source-tag op wikipedia ook onlangs ontdekt. Je kunt hetzelfde ook doen met andere programmeertalen door de lang-parameter aan te passen (voor matlabcode typ je dan matlab tussen de aanhalingstekens). Annabel_(overleg) 16 dec 2007 10:40 (CET)

Ik zie nu pas je reaktie. Het gaat mij niet om de kleurtjes, maar het is wel een leuke bijkomstigheid. Maar het probleem lijkt inderdaad hiermee opgelost. Alsnog bedankt! $\sim$ Wimmel 20 jan 2008 21:36 (CET)