Wikipedia:Redactielokaal/Archief/2018-10

Verkeerde interwikikoppeling

De pagina Hans Blom is gekoppeld aan en:Hans Blom, maar het betreft twee verschillende personen. De eerste heeft de juiste portretfoto, de tweede dus niet (het zijn overigens twee verschillende bestanden: juist gekoppeld en onjuist gekoppeld). Hoe kan dit probleem worden opgelost? Jürgen Eissink (overleg) 11 okt 2018 21:52 (CEST).

Bij Wikidata is het Nederlandstalige artikel gekoppeld aan item d:Q1860624. Het Engelstalige artikel over de filosoof was daar ten onrechte ook aan gekoppeld. Op Wikidata heb ik de koppeling tussen item Q1860624 met dat en-wiki artikel verbroken en daarmee is dat probleem opgelost. - Robotje (overleg) 11 okt 2018 22:24 (CEST)

Ik zal de verkeerde foto ontkoppelen en gewag maken van de vergissing op de Engelse wikipedia. Met dank, Jürgen Eissink (overleg) 11 okt 2018 22:26 (CEST).

NB Ik hen inmiddels het Engelse artikel vertaald, dus de huidige koppeling is wel goed. Jürgen Eissink (overleg) 11 okt 2018 23:53 (CEST).

Harde spatie in referentie

In deze wijziging wordt 17 keer een harde spatie toegevoegd in referenties en voetnoten. Daarmee worden taalelementen bijeen gehouden, zoals "p. 125" (pagina), "Willen II", "100 000" (spatie = ISO-norm). Is dat wenselijk, of zelfs zeer wenselijk, of juist niet? We willen in de hoofdnaamruimte zo min mogelijk codes, maar bij de referenties is dat misschien net anders. En argument is dat afkortingen in referenties vaak wenselijk zijn wegens ruimtegebrek en het bewaren van overzicht, duidelijkheid of uniformiteit.  —  „Jaspər Kloekmoed”  ^[ ! ? ]  20 okt 2018 22:41 (CEST)

@Jasper Kloekmoed: Een wat late reactie: in een enkel geval is de no-break space/non-breaking space (" ") prima, maar in het algemeen verdient het de voorkeur om het sjabloon {{nowrap|Willem II}} te gebruiken, omdat dat de wiki(bron)tekst dan (meestal) beter te lezen is, en je dan gewoon gebruik kan maken van normale spaties in de brontekst, en het (zo effectief mogelijk) parsen ervan aan de server-zijde overlaat. Het is wel zo dat de html-code ( ) 6 karakters in beslag neemt (per 'no-break space'), tegen tenminste 11 (4 accolades (2x '{' en 2x '}'), de pipe ('|') en het woord 'nowrap') wanneer het {{nowrap}}-sjabloon gebruikt wordt; bij 2 of meer spaties is het daarmee wel al efficiënter. Ik heb wel gemerkt dat het nowrap-sjabloon op sommige plekken niet of niet goed werkt (ik meen binnen sommige andere andere sjablonen; ik heb geen voorbeeld voor handen, maar ik meen dat in sommige infobox- of citeer/citaat-sjablonen niet (altijd) werkt zoals verwacht/geen effect heeft of tot merkwaardige resultaten leidt; in die gevallen kan men terugvallen op de html-code voor de 'harde spatie'. In enkele zeldzame gevallen kan het ook voorkomen dat het {{nowrap}}-sjabloon binnen andere sjablonen de brontekst juist minder makkelijk leesbaar maakt (maar hangt meestal samen met het gebruik van spatiëring en regelafbreking binnen sjablonen tussen de parameters en de '=' en '|' karakters (regelafbreking achter elke parameter maakt ingevulde sjablonen beter leesbaar, maar maakt de brontekst weer 'langer' en dan is minder duidelijk welke alinea's en paragrafen wel en niet bij elkaar horen, etc.). Groeten -- martix (overleg) 7 dec 2018 11:43 (CET)

@martix Dankjewel voor je uitleg. Het hele {{nowrap}}-sjabloon kende ik niet. Maar blijkbaar wordt de "vaste spatie" op Wikipedia waar wenselijk ook gefaciliteerd op onze eigen manier. En ja, werkt dat niet goed, dan kies je de beste uit de overige opties.  —  „Jaspər Kloekmoed”  ^[ ! ? ]  8 dec 2018 18:20 (CET)

@Jasper Kloekmoed: (voor dat '@<gebruikersnaam>' hebben we overigens ook het {{ping|gebruikersnaam}}-sjabloon ), nog even terugkomend op de bewerking waarnaar je in de eerste zin naar verwees: in dat geval denk ik dat het vanwege de meerdere spaties in groep van bij elkaar horende tekens/gegevens, het wel wenselijk is om – voor zover/alleen indien het daar werkt – dáár wel wenselijk is om het {{nowrap}}-sjabloon te gebruiken. In infoboxen is het soms (wanneer je bij een veld meerdere namen/gegevens wilt opgeven, of niet ontkomt aan lange zinnen) aan te raden om van geforceerde regelafbreking (<cr />) en harde spaties te gebruiken (hetzij met nowrap, hetzij met de html-code), om te leesbaarheid en het effect te bekijken, bij voorkeur bij verschillende schermresoluties en zoom factors om te zien of en hoe het er met die verschillende (scherm=-/browser)instellingen uitziet zonder en met geforceerde opmaak. Datzelfde geldt voor captions/onderschriften en zoals je al opmerkte, ook bij referenties. Het is wel zo dat als je gebruik gaat maken van {{Citeer web}} en andere citeer-sjablonen, en daarin veel parameters invult (lees: de lezer van meer informatie over de bron voorziet), een referentie al snel niet meer op één regel past en je niet ontkomt aan een regelafbreking (en daarmee ook de noodzaak voor harde spaties, in welke vorm dan ook, wenselijk kan zijn). Soms kun je (zie info- en taxoboxen) invulling van sjablonen leesbaarder maken door elke parameter op een nieuwe regel te beginnen; ik doe het met uitvoerig ingevulde {citeer}-sjablonen wel eens, maar dat kan wel eens vragen of verwondering oproepen. Je kan bij/binnen de parameters infoboxen eventueel ook gebruik maken van <div> en </div>-tags (zie bijvoorbeeld het artikel Spirit Airlines, waar ik dat heb gedaan – probeer maar eens met een bewerkingsvoorbeeld (alleen) de (regels met de) div's en /div's weg te halen voor het effect) om meerdere waarden te groeperen tot 1 html-entity als parameter; dat soort dingen blijven volgens mij altijd 'stuivertje wisselen' t.a.v. het uiteindelijke effect bij de lezers (onder verschillende scherm(resolutie)-, browser-, en zoom-instellingen) en/of de leesbaarheid en schrijfgemak van wiki-brontekst. Dat alles speelt natuurlijk in de VE een stuk minder.

Tot slot: "100 000" mag dan wel een ISO-standaard zijn, maar omdat het een Nederlandstalige Wikipedia is, is er helemaal niets op tegen om ook de cijfer- en getallennotatie (alsmede datum- en tijdnotatie) zoals voorgeschreven door de Taalunie of (wanneer deze niet voorziet), advies van Genootschap Onze Taal te gebruiken; De computer- of software-instellingen geven weliswaar de mogelijkheid om taal- en regio-instellingen los van elkaar (en zijn dus niet onlosmakelijk met elkaar verbonden) in te stellen, maar volgens mij voorzien de taalregels van het (standaard)Nederlands alleen in een Nederlandstalige notatie (en staan die regels ISO-notaties aanvullend, maar niet noodzakelijk met preferentie, toe). De vraag is of en waar dat zinvol is en/of de voorkeur heeft. Groeten, -- martix (overleg) 8 dec 2018 22:36 (CET)

Insomnia update, 9 dec 2018 04:07 (CET) @Jasper Kloekmoed: N.B.: Met behulp van harde spaties/non-breaking space kun je ook overigens ook (zeker bij beperkte horizontale ruimte, of eigenlijk het altijd wel gewenste fenomeen) van een soort "weduwen- en wezen"-bescherming (maar dan meer op 'woord'- niveau i.p.v. regelniveau) forceren/simuleren door voor de allerlaatste spatie in een paragraaf of alinea altijd een harde spatie te gebruiken (of de laatste twee woorden of de laatste woordgroep – zeker bij vaste verbindingen – te groeperen in een {{nowrap}}-sjabloon. Ik heb dat bijvoorbeeld in de tabel in dit kopje gedaan (omdat in de praktijk in de opmaak relatief vaak het laatste woord van een passage of de zin(nen) in een tabelcel als een enkel woord zielig alleen op de laatste regel kwam te staan (als een soort woord-hoerenjong. Veelal is dat een optie in tekstverwerkers die je aan of uit kan zetten, en voorkomt de software dan dat een enkel (het laatste) woord op een nieuwe regel komt. Strikt genomen verwijzen 'weeskind', "weduwe' en/of "hoerenjong" naar begrippen die op de eerste of laatste zinnen betrekking hebben – in relatie tot pagina's –, maar je kunt je de context, op woord-niveau – in relatie tot regels – ook wel voorstellen (al zal dat mogelijk anders heten; als het een (andere) naam heeft, ken ik het (nog) niet in die context (en ik verkeerde altijd in de veronderstelling dat het verschijnsel dezelfde naam heeft, maar er wordt in onze artikelen niet over gerept).

Het is goed mogelijk dat er (net als in tekstverwerker-software) tweaks, tags, andere sjablonen of gebruikers instellingen in Wikipedia zoiets automatisch kunnen voorkomen, maar (zoals hieronder ook blijkt), weet ik niet overal alles van, en ken ook beslist niet alle mogelijke sjablonen en/of aan te vinken features en instellingen van Wikipedia, en leer ook nog dagelijks bij. Groeten -- martix (overleg) 9 dec 2018 04:07 (CET)

De Taalunie stelt hier als bijzonderheid: Getallen en bedragen mogen niet worden afgebroken. Om te voorkomen dat dat bij het gebruik van spaties toch gebeurt, is het raadzaam in computerbestanden gebruik te maken van zogeheten 'harde spaties'. Mvg, Trewal 8 dec 2018 22:49 (CET)

@Trewal: kijk, dat wist ik dan weer niet, en dat is weer het nieuwe feitje voor vandaag – dank voor de verwijzing! (Eerlijk gezegd verbaast het me een beetje dat de Taalunie zo courant is hiermee). Maar is het dan/toch niet zo dat een punt als scheidingsteken voor duizendtallen nog voorkeur heeft in de voorschriften of taaladviezen? (Volgens mij zal een punt – er even vanuit gaande dat deze (met of zonder prevalentie) nog is toegestaan als scheidingsteken van duizendtallen – in het gemeen immers ook niet zal leiden tot regelafbreking, vermits alle cijfers, de decimale komma en de punt ('.') als het scheidingsteken volledig aan elkaar geschreven zijn, en er voldoende horizontale ruimte is? (Bij gebrek aan horizontale ruimte kan afbreking op onverwachte plekken geschieden natuurlijk, of mogelijk zal zelfs "de zin het beeld uitlopen", afhankelijk van de – interpretatie van de – interface). Of heeft geen van tweeën voorkeur over de ander? (In feite is dan natuurlijk sprake van de harde spatie als scheidingsteken van duizendtallen; schrijft de ISO-standaard eigenlijk al niet specifiek de non-breaking space voor, of wordt de vorm van de (horizontale) spatie in het midden gelaten? Groeten -- martix (overleg) 8 dec 2018 23:41 (CET)

De Taalunie schrijft expliciet dat getallen en bedragen niet mogen worden afgebroken. Of ISO er ook wat van zegt is dan irrelevant. Mvg, Trewal 9 dec 2018 00:20 (CET)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘Dat is niet helemaal een antwoord op mijn (waarschijnlijk te vaag/te omslachtig geformuleerde) vraag ("Welk teken/karakter wordt geprefereerd als scheidingsteken voor duizendtallen?"). Dat (regel)afbreking van getallen niet mag en voorkomen dient te worden is (immers) de aanleiding van de oorspronkelijke vraag hier. Maar ik heb het antwoord/advies van de Taalunie inmiddels in hetzelfde taaladvies gevonden. Groeten -- martix (overleg) 9 dec 2018 01:11 (CET)

Resumerend kun je in elk gevallen stellen dat de "vaste spatie" in courante tekst wel eens wenslijk kan zijn olgens de Talunnie, en dus hier ook gebruikt zou kunnen worden in hoofdnaamruimte, met waar mogelijk een wikisjabloon dat gebruikers met enige ervaring wel begrijpen of op kunnen zoeken voor uitleg. Ik zal er iets scheutiger mee zijn, en ik blij met de helderheid en nieuwe "feitjes".  —  „Jaspər Kloekmoed”  ^[ ! ? ]  9 dec 2018 13:22 (CET)

@Jasper Kloekmoed: Klopt helemaal; over het {{nowrap}}-sjabloon valt overigens verder nog wel op te merken dat het op alle karakters binnen het sjabloon werkt, dus ook op (afbreek)streepjes/koppeltekens, het karakter "-" dus, die zonder ingrijpen ook tot een regelafbreking na het streepje kunnen leiden(!). Het alternatief daarvoor (i.p.v. het nowrap-sjabloon) is de 'non-breaking hyphen' ('‑'): html-codes ‑ (decimaal) of ‑ (hexadecimaal), of via directe invoer onder Windows ALT+2011 (of SHIFT+CTRL+U <loslaten> 2011 <spatie> onder de meeste linux/*nix consoles en desktops). Niet gecodeerde invoer van de NBSP kan met ALT+000A0 (Windows), SHIFT+CTRL+U, 00A0, <spatie> (op linux/unix platforms; de terminating space (<ENTER>, werkt meestal ook, maar kan problemen opleveren bij invoervelden) is om het einde van de (hexadecimale) cijferreeks te markeren, waarna het teken verschijnt). Het nadeel van directe ingave van deze karakters in de wiki-brontekst is dat dat visueel het verschil tussen de reguliere en non-breaking varianten niet (altijd) (gemakkelijk) zichtbaar is). -- martix (overleg) 9 dec 2018 18:07 (CET)