Wikipedia:De kroeg/Archief/20111004

Naamgeving Chinese steden

Wikipedia volgt meestal de Nederlandse Taalunie. De Taalunie stelt dat Peking de voorkeur heeft op Beijing (bekijk hier het taaladvies), maar noteert ook dat het endoniem steeds vaker voorkomt in de Nederlandse taal.

Het is in dit voorbeeld nog redelijk omdat Beijing en Peking toch wel wat gelijkend zijn, en voor deze stad het regeltje van het taaladvies gekend is. Het is veel erger voor Kanton dat door de rest van de wereld Guangzhou genoemd wordt, en voor Tsjoengking dat gewoon Chongqing is. Om de lijst volledig te maken worden ook de endoniemen Xinjiang in de plaats van ons Sinkiang en Nanjing in de plaats van ons Nanking expliciet vermeld als meer en meer gebruikelijk.

Laat ons eerlijk zijn, daar waar de Taalunie zelf expliciet stelt dat "ook het endoniem komt in Nederlandse teksten in toenemende mate voor", is dat een eufemisme voor hun erkenning dat ze hun verlies toegeven. Laat het nu aan Wikipedia zijn, om uniformisatie te brengen en die namen ook stelselmatig door te voeren.

Want ook Wikipedia wankelt, was het niet dit voorjaar dat in een peiling voor de naamgeving van Franse gemeenten een overgrote meerderheid er voor koos om niet zonder meer de NTU lijsten te volgen? In Frans-Vlaanderen spelen er dan nog historische en taalgevoelige elementen. Die verbondenheid is er helemaal niet met de Volksrepubliek China bij mijn weten. Weg met Peking, Kanton en het vreselijk Tsjoenking, lang leve Beijing, Guangzhou en Chongqing.

Als ik naar de andere taaledities van Wikipedia kijk (tenminste die met Latijns schriftsysteem, die waar het dan ook eenvoudig zichtbaar is), constateer ik bij voorbeeld dat het Nederlands nog een van de weinige talen is die afwijkt met Kanton als naam van het Chinese Guangzhou. Nu de Chinese censusgegevens van 2010 beschikbaar raken, wordt het stilaan pijnlijk dat we het land van een klein vijfde van de wereldbevolking met rare naampjes beschrijven.

Men zou er voor kunnen kiezen voor die plaatsen waar de Nederlandse Taalunie zelf stelt dat het endoniem in toenemende mate voorkomt (steden in hun lijst met @ aangeduid), daar de lemmatitel en inhoud wordt aangepast, en dit voor alle andere gevallen (nog) niet te doen. Dan gaat het om vijf stadsnamen die we aan het reeds bestaande uitzonderlingslijstje van WP:BGN toevoegen. 94.225.56.252 25 sep 2011 20:00 (CEST)

De Sinificatie slaat toe zie ik. Het lijkt mij geen goede zaak om namen die al eeuwen worden gehanteerd zo snel in te ruilen. Zo hebben we ook andere namen voor Keulen en Luik dan hoe ze het in resp. Duitsland en Wallonië noemen... Daar zie ik geen reden in om deze namen te veranderen. NeoRetro (overleg) 25 sep 2011 22:06 (CEST)

Ikzelf zou eigenlijk geen reden zien om Peking Beijing te noemen, maar als iemand anders vind kan die persoon altijd nog een peiling starten. Bonaber (overleg) 25 sep 2011 22:10 (CEST)

Zolang de TaalUnie aangeeft dat beide spellingen goed zijn, zijn beide spellingen goed. Wat betreft "Xinjiang" ligt de zaak iets ingewikkelder, dat is nl. geen endoniem. Woudloper _overleg 26 sep 2011 07:24 (CEST)

Als er een peiling opgezet gaat worden, lijkt het me beter om die niet te beperken tot Chinese geografische namen. We hebben hier op de Nederlandse Wikipedia de Wikipedia:Transliteratie- en transcriptiegids waar soms van wordt afgeweken voor bepaalde geografische namen die voorkomen op de NTU-lijsten. Als de NTU aangeeft dat een andere variant voorkomt die conform onze transliteratieregels is, zou die variant wat mij betreft de voorkeur moeten krijgen. Voor Japan staat op hun lijst [1] dat naast Tokio en Kioto ook de 'endoniemen' (Tokyo en Kyoto) steeds vaker voorkomen. Volgens onze eigen transliteratieregels zouden we Tokyo en Kyoto horen te schrijven maar omdat momenteel de NTU-lijsten de prioriteit hebben zijn we nu niet consequent in de omzetting. Het kan nu dus gebeuren dat we in een en dezelfde zin きょ ('kyo') zowel als 'kyo' als 'kio' omzetten en dat staat wel erg knullig. - Robotje (overleg) 26 sep 2011 08:56 (CEST)

Als we Kioto of Tokio schrijven, translitereren we helemaal niet. Ook niet als we Moskou schrijven, of Cairo, of Casablanca. We gebruiken een exoniem, dat is alles. Fransvannes (overleg) 26 sep 2011 09:06 (CEST)

Het artikel transliteratie begint met "Transliteratie is het omzetten van het ene alfabet of schriftsysteem in het andere. ... " Zonder translitereren zouden we 東京 en 京都 schrijven in plaats van Tokio/Tokyo en Kyoto/Kioto. - Robotje (overleg) 26 sep 2011 09:20 (CEST)

Analoog: zonder translitereren blijft het Москва. Waar komt Moskou dan vandaan? Ook daar geldt: daar wordt niet getranslitereerd. In exoniemen gebeurt meer: er kan van alles worden aangepast (klanken, klemtoon, noem maar op, soms wordt de betekenis van de naam vertaald). Tokio is gewoon een exoniem, net als Moskou, Casablanca en Cairo. Dat is helemaal niets bijzonders.Fransvannes (overleg) 26 sep 2011 09:28 (CEST) Om deze discussie niet helemaal over te hoeven doen: zie Wikipedia:Buitenlandse_geografische_namen/Expertise_Wolters-Noordhoff#Japanse geografische namen. Zelfde onderwerp, zelfde deelnemers, zelfde standpunten.

We hebben niet zo lang geleden een peiling gehad over trashmetal vs. thrashmetal, waarbij de TaalUnie duidelijk gewoon een fout had gemaakt in hun advies. Toch was de meerderheid er voor om de TaalUnie te blijven volgen en te hopen dat ze binnenkort met een geactualiseerd advies komt. In het geval van de Chinese steden geeft de TaalUnie geen fout advies: het maakt een keuze tussen twee (of meer) mogelijke alternatieven. De keuze is misschien wat oubollig en achterhaald, maar zeker niet 'fout'. Ik zie dan ook geen enkele reden om van het TaalUnie-advies af te wijken. Als we dat hier gaan doen, is het hek van de dam en zitten we straks weer met een peiling voor elk Fries (sorry, Frysk) gehucht met drie inwoners en twee kippen ;-). CaAl (overleg) 26 sep 2011 09:27 (CEST)

Precies, we volgen de taalunie. Hierboven wordt gesteld dat Wikipedia wankelt, maar dat is klinklare onzin. Ook het duwtje in de rug dat de Taalunie nodig zou hebben, komt niet van Wikipedia. Ik geloof niet dat de mensen van de Taalunie met argusogen kijken wat wij hun adviseren, en ik raad het ze ook af. Wikipedia, een verzameling malloten zonder duidelijke kennis of richting of leiding, heeft juist iets externs als de TaalUnie nodig om niet te gaan zwalken. Als die TaalUnie dan steken laat vallen, moet je de TaalUnie er op aanspreken, en niet via Wikipedia proberen je zin te krijgen, omdat je denkt dat je hier sneller/gemakkelijker/goedkoper je gelijk krijgt dan via de officiele weg. edO_verleg 26 sep 2011 11:47 (CEST)

Ik kan het hier alleen maar hartgrondig mee eens zijn. Fransvannes (overleg) 26 sep 2011 12:03 (CEST)

En ik begrijp de argumentatie ook niet: Het zou "pijnlijk" zijn om "rare" namen te geven omdat Chinezen "een klein vijfde van de wereldbevolking" vormen? Fransen zijn zwaar in de meerderheid t.o.v. Nederlandstaligen, toch blijven wij "pijnlijk" dat "rare" Parijs schrijven waar de rest van de wereld zich behelpen moet met Paris, Parys of Pariz. W.D. Sparling (overleg) 26 sep 2011 13:28 (CEST)

Over Fransen gesproken; die schrijven nog steeds fr:Pékin, net als de Duitsters de:Peking schrijven. Aangezien er meer Duitsers dan Nederlands rondlopen, zouden we dus gewoon Peking moeten schrijven toch? M.vr.gr. brimz (overleg) 26 sep 2011 14:08 (CEST)

Eerlijk is eerlijk: de steen des aanstoots was ditmaal niet zozeer "Peking", maar bijvoorbeeld wel "Kanton". Maar ook daarvan wordt een gechargeerd beeld geschetst. Het Nederlands is hier, afgaand op de verschillende Wikipedia's, in het gezelschap van het Spaans, het Portugees, het Frans, het Pools en het Hongaars. Allemaal talen die hun rare naampjes nog niet hebben opgeborgen. Het is best mogelijk dat het Nederlands dat eerdaags gaat doen, maar laten we daar maar niet op vooruit willen lopen. Activisme moet Wikipedia vreemd zijn. Fransvannes (overleg) 26 sep 2011 14:54 (CEST)

Hartelijk dank voor deze nuttige discussie en goede argumenten. Hier zijn zinvolle tegenargumenten gegeven. Mijn aanzet tot activisme begraaf ik bij deze. 94.225.56.252 26 sep 2011 20:13 (CEST)

Dat geldt net zo goed voor conservatief activisme, en de Taalunie geeft zelf aan dat beide vormen in het Nederlands gebruikt worden. Dat we in een dergelijk geval het door de Taalunie aangegeven exoniem gebruiken, is onze regel, niet die van de Taalunie, en "we volgen gewoon de Taalunie" is wat mij betreft dus een non-argument. - André Engels (overleg) Hulp gewenst? Neem een coach! 27 sep 2011 09:25 (CEST)

Het geldt ook voor conservatief activisme, maar dat kom ik hierboven niet tegen (elders wel). Misschien ook omdat WP:BTNI per definitie conserverend werkt: waar de door ons benoemde scheidsrechter twee mogelijkheden biedt waar het er eerder één was, "wint" bij ons de oudste. In het geval van Peking (en ook Tokio) beveelt de Taalunie overigens expliciet het exoniem aan. Fransvannes (overleg) 27 sep 2011 09:48 (CEST)

Peking is zo raar nog niet van de TaalUnie, voor beide schrijfwijzen van de Chinese hoofdstad valt zeker iets te zeggen. Tsjoengking, Nanking en het Russische Insterburg echter zijn voorbeelden van toponiemen die vele jaren geleden al uit de atlassen verdwenen zijn en (grotendeels) in onbruik raakten in het Nederlands. Leo V (overleg) 29 sep 2011 01:43 (CEST)

Upgrade of downgrade

Ik heb begrepen dat er weer een "update" van de wikisoftware is geweest. Meestal wordt je blij van de verbeteringen. Maar nu blijkt dat allerlei zak niet meer werken. Maak je bijvoorbeeld een ##Doorverwijzing aan als nieuwe pagina, dan kun je dat niet als kleine bewerking markeren. Waarom niet? De extra bewerkingsknoppen zijn verdwenen. Shoot.
Voor mods onhandig: De instellingen voor een blokkade die in een sjabloon zijn voor-ingevuld worden niet meer overgenomen. En heb je daardoor een blokkade gedaan met een foutje, dan kun je niet opnieuw instellen zonder te deblokkeren. Onhandig. Zucht.
Dit is een downgrade en ik heb vast niet alle probleempjes ontdekt. Lymantria _overleg 28 sep 2011 11:10 (CEST)

Eens - moderatoren lopen nu regelmatig vast want voor je het weet heb je de foute blokinstelling gekozen voor een softblok (bijvoorbeeld voor een ongewenste gebruikersnaam) of bij een school waar nu niet meer staat dat het een school is die geblokkeerd wordt. Is echt niet plezierig werken zo. MoiraMoira _overleg 28 sep 2011 11:33 (CEST)

Bij blokopties is er ook iets fout ingevoegd. Als je een ip-adres wil blokkeren krijg je te zien "Automatisch de IP-adressen van deze gebruiker blokkeren" - dat slaat nergens op... MoiraMoira _overleg 28 sep 2011 11:35 (CEST)

Bedankt Lymantria om dit even onder de aandacht te brengen. Na invoeringen van vector, dat ik nu noodgedwongen en dik tegen mijn zin moet gebruiken (omdat de linkerzijbalk volledig uit elkaar getrokken wordt in monobook), is dit alweer een jammere mislukking. Ik wil mijn extra bewerkingsknoppen asap terughebben. En ik snap überhaupt geen jota van wat die nieuwe software verbetert met betrekking tot de encyclopedie. Wat mij betreft wordt de boel nu teruggezet. - C (o) 28 sep 2011 11:35 (CEST)

Het javascript tooltje waarmee je kan hercategoriseren is ook grotendeels stuk. Anderzijds: Ik ben wel benieuwd of er misschien iets voor de "gewone"(niet-mod) gebruiker verbetert is? (Buiten dat: komt me bekend voor) Milliped (overleg) 28 sep 2011 11:44 (CEST)

Ook vervelend: het knopje "rangebijdragen bekijken" in de toolbar van de waarschuwingsjablonenserie doet het ook niet meer. Dat is bij vooral scholen waarvandaan vaak doorgaand geklieder vanaf de diverse IP-adressen van hun (deel-)range komt onmisbaar voor controle. MoiraMoira _overleg 28 sep 2011 12:03 (CEST)

Het is inderdaad niet handig werken zo... zie overigens #MediaWiki 1.18 deployment voor meer informatie. Mathonius 28 sep 2011 12:18 (CEST)

Aanvullend: ik denk dat er heel wat wijzigingencontroleurs met knopjes nu zitten te balen omdat de blokredenen niet meer ingevuld worden als je vanaf het schoolsjabloon gaat blokkeren. Ik heb het vandaag al een aantal malen vergeten zelf. En dan werkt het herblokkeren met reden ook niet, moet je eerst een deblokkade uit gaan voeren, dan handmatig alles invoeren en dus wordt het ons totdat dit allemaal gefixt is hopelijk vergeven... MoiraMoira _overleg 28 sep 2011 14:03 (CEST)

Ik heb het zojuist ook ondervonden, en het werkt zeer onprettig. Graag zo snel mogelijk terugdraaien deze update. Mezelf14 _overleg 28 sep 2011 14:31 (CEST)

De update heeft vooral een probleem met lokale settings, dingen als een andere opmaak voor tabellen zorgden er bijvoorbeeld voor dat deze niet meer werkten, daarnaast zijn er inderdaad wat handige functies verloren gegaan, zoals de mogelijkheid op 2 kolommen te sorteren (eerst A dan B) Mvg, Bas (o) 28 sep 2011 14:46 (CEST)

Ik verwacht overigens dat terugdraaien toch nooit gaat lukken, is denk ik een kwestie van de instellingen op deze wiki finetunen met de update (zal wel wat in het scholensjab anders moeten om het te laten werken). Bas (o) 28 sep 2011 18:37 (CEST)

We moeten ons realiseren dat dit Wikipedia-project onderdeel uitmaakt van een veel groter project waarin in honderden talen op vele honderden projecten van allerlei soorten en maten waarop we vrije informatie ter beschikking stellen aan het publiek. Dat grotere project, de Wikimedia Foundation met alles er op en er aan, heeft als doelstelling om steeds meer kwalitatieve vrije informatie te verzamelen en beschikbaar te maken in zo veel als mogelijk talen. De website draait echter niet op lucht, niet automatisch en zeker niet vanzelf, maar daarvoor zijn servers, software en infrastructuur nodig om de boel draaiende te houden. Daarbij komen er van de vele verschillende projecten verzoeken tot aanpassingen, verzoeken tot verbeteringen, en om al de goede ideeën ten uitvoer te brengen vereist dat dat de software aangepast wordt, omdat anders de software vast kan lopen, bepaalde functies die op de projecten "als vanzelf" lijken te bestaan niet meer functioneren, bovenal gerapporteerde problemen opgelost moeten worden, et cetera. Al met al zijn er met de nieuwe MediaWiki-versie (1.18) meer dan 400 wijzigingen aangebracht in de MediaWiki-software, juist ook om ons, de bewerkers van de projecten, in staat te stellen om te werken op een stabiel project met alle mogelijkheden die we wensen en al gerealiseerd zijn. We moeten ons ook realiseren dat zonder steeds al die verbeteringen we nooit dit project zoals het nu is gehad hebben kunnen hebben als er sinds de start niets was verbeterd.

Verbeteringen in de MediaWiki-software die met een nieuwe versie worden uitgerold, kunnen door onvoorziene zaken problemen geven en worden daarom snel gerapporteerd, maar die verbeteringen vereisen wel dat bepaalde gebruikersvoorkeuren, bepaalde gadgets, en bepaalde generieke instellingen die wij op dit project ingesteld hebben, ook upgraded moeten worden! Die upgrades dienen door de technische gebruikers van een project te worden uitgevoerd. Zolang die gebruikersvoorkeuren, gadgets, en generieke instellingen nog niet zijn upgraded om aan te sluiten op de nieuwe MediaWiki-versie, zijn een deel van die ingestelde zaken incompatibel door de achterhaalde techniek die er achter zit. Om de nog niet-upgrade zaken snel upgraded te krijgen dienen we zo snel als mogelijk duidelijk uit te leggen en te beschrijven, eventueel met screenshots, en de technische gebruikers van dit project vragen naar die problemen te kijken.

Verschillende problemen heb ik aan de ontwikkelaars al gemeld, maar de zaken die moderator-gerelateerd zijn kan ik niet bekijken, kan ik de problemen niet van opsporen en buitengewoon moeilijk een melding van maken aan de ontwikkelaars omdat ik er geen zicht op heb. Het spijt me zeer, ik kan daar niet echt bij helpen, dat zal iemand anders moeten doen. Ik heb de indruk dat een aantal technische gebruikers al enige tijd erg inactief is geworden overigens. Groetjes - Romaine (overleg) 28 sep 2011 20:30 (CEST)

Een verhelderende uitleg, waarvoor dank! Josq (overleg) 28 sep 2011 20:32 (CEST)

Het conflict tussen mens en machine was jaren geleden SF, maar nu angstaanjagend dichtbij. De «hersenen» van zo'n mediawiki 1.18 verschalken onze bewerkershersenen. Het gros van de mensen wil draaien op routine en goeie gewoonten en helemaal niet zo vaak veranderen als in de ontwikkelaarswereld gebruikelijk is. Mogelijk gevolg: alweer een sterke daling van het aantal wikipedianen wegens het niet volgen van het KISS-principe. Ik zal een kopie van Romaine's vector.js nu maar aanpassen aan mijn eigen noden, maar het is een studie van codes waar ik niet bepaald naar uitzie. Maar liever zo dan in vector een bèta-bewerkingsbalk met uitrolmenu's waarvan je altijd moet onthouden onder welke uitrol die functie of dat teken staat. Ik vind een uitgebreide bewerkingsbalk met direct aanklikbare icoontjes overduidelijk meer "KISS" (en tijdsparend) dan uitrolmenu's. De onmiddellijke toekomst lijkt er zo uit te zien dat nu elke wikipediaan een "ruim minimum" van css en js zal moeten beheersen, wil hij/zij nog een aangenaam gevoel van vlot werken op de wikipedia behouden dankzij het "spelenderwijs" aanpassen van de eigen bewerkingsruimte. Ik merk wel dat de aanpassingsreactie na een klik op Toon bewerking ter controle met een hoop milliseconden is versneld.--Dartelaar [geef een gil!] 29 sep 2011 01:07 (CEST)

Beste Romaine, Het probleem met het blokkeren is als volgt: Wanneer een gebruiker geblokkeerd wordt, dan moet je een aantal vinkjes zetten voor het type blokkering, en een blokkeerreden opgeven. Vanuit sjablonen was het altijd mogelijk hiervoor een standaard te maken (voor een ongewenste gebruikersnaam bijvoorbeeld anders dan voor een vandaliserende school). Dat gaat niet meer, zo lijkt het. Er staat altijd een door de ontwikkelaars ingestelde default. Daarnaast is het herblokkeren met andere instellingen als je een foutje hebt gemaakt niet mogelijk. Je komt op de blokkeerpagina, daar staan de vinkjes e.d. zoals die bij blokkade zijn ingesteld. Je kunt daar wat in veranderen, en dan staat daar heel uitnodigend een grote knop "Deze gebruiker opnieuw blokkeren met deze instellingen". Maar die knop werkt niet. Je moet eerst deblokkeren en dan weer blokkeren. Heus niet onoverkomelijk, maar wel reuze irritant. Ik vind het i.i.g. geen vooruitgang. Groet, Lymantria _overleg 29 sep 2011 16:38 (CEST)

In de meeste gevallen dat het lijkt dat er een functionaliteit niet meer bestaat/werkt, komt dat omdat er door verbeteringen in de software het op een iets andere manier is gaan werken, waarop de betreffende sjablonen nog aangepast moeten worden. Dat is volgens mij in ieder geval het geval met die vinkjes. Romaine (overleg) 29 sep 2011 17:21 (CEST)

Ter informatie, de onmogelijkheid om een blokkade aan te passen, heb ik inmiddels op meta aangekaart. Mathonius 29 sep 2011 17:23 (CEST)