Unicode normalization considerations/nl

Wat is dit?

Sinds 1.4 past MediaWiki normalisatievorm C (NFC) toe op Unicode-tekstinvoer. Er zijn goede redenen om te normaliseren:

• Vermijd tegenstrijdige paginatitels die dezelfde tekens hebben maar een andere opdeling van de samenstelling.
  • Een aanhoudend probleem waren de mediabestanden die vanaf Safari werden geüpload; de bestandsnamen en dus de paginatitels waren in opgedeelde vorm, terwijl de meeste andere hulpmiddelen tekst leverden in een samengestelde vorm
• Laat de zoekopdracht volgens verwachting werken, ongeacht de samenstelling van de tekst.

Vorm C is gekozen omdat:

• De overgrote meerderheid van de invoergegevens is al in vorm C, met behulp van vooraf samengestelde tekens.
• Vorm C moet relatief verliesloos zijn, met de enige veranderingen die onzichtbare transformaties tussen basis karakter + combinatie van karaktersequenties en vooraf ingestelde karakters zijn. In theorie zou de tekst nooit zijn uiterlijk moeten veranderen omdat het is genormeerd naar vorm C.
• En verder: de W3C beveelt het aan.

MediaWiki past geen normalisatie toe op zijn uitvoer, bijvoorbeeld cafe<nowiki/>́ wordt "café" (toont U+0065 U+0301 achter elkaar, zonder dat er vooraf samengestelde tekens zoals U+00E9 verschijnen).

Wanneer MediaWiki een interne link toont, wordt de paginatitel ook genormaliseerd naar vorm C – zelfs als deze is gecodeerd met HTML-entiteiten, referenties of de meeste andere oplossingen die de respectievelijke transformatie in de broncode ontwijken. Maar er vindt geen NFC-transformatie plaats (vanaf MediaWiki 1.35.0) op tekens die in de paginatitel zijn ingebed in percent encoding, zoals %E1%BD%B5.

Het probleem

Maar na verloop van tijd zijn er een aantal problemen ontstaan.

• sommige Arabische, Perzische en Hebreeuwse klinkermarkeringen combinaties zorgen voor verkeerd sorteren.
  • Sommige hiervan zijn gewoon buggy lettertypen of renderers en treffen alleen bepaalde platforms.
  • Enkele gevallen kunnen echter onjuiste tekst opleveren, omdat de gedefinieerde classificaties niet genoeg onderscheidingen bevatten om semantisch correcte ordening te verkrijgen. Dit treft vooral oudere teksten zoals het Bijbels Hebreeuws.
• Een verrassende compositie-uitsluiting in het Bengaals.
  • Het resultaat wordt niet goed opgebouwd met sommige hulpmiddelen, waarschijnlijk weer een platformspecifieke bug
  • Sommige hulpmiddelen van derden voor het zoeken weten blijkbaar niet hoe ze moeten normaliseren en slagen er niet in teksten te vinden die genormaliseerd zijn.

De rendering (opbouw) en zoekproblemen van derden zijn irritant, maar als we ons op ons hoge paard kunnen houden, proberen we het te negeren en de andere partijen hun gebroken software met de tijd laten repareren.

De canonieke ordeningsproblemen zijn een moeilijker vraagstuk; Men kan deze simpelweg niet goed krijgen door de huidige specificaties te volgen. Unicode zal de ordeningsdefinities niet veranderen omdat het hun compatibiliteitsregels zou overtreden, dus tenzij ze *nieuwe* tekens met de juiste waarden introduceren... Nou, het is niet duidelijk of dit gaat gebeuren.

Wat kunnen we eraan doen?

We kunnen het ofwel negeren en hopen dat het overgaat (gemakkelijk, maar dat betekent dat we voortdurend klachten van bepaalde taalgroepen moeten behandelen), of we kunnen ophouden met een omvattende normalisatie en de manier waarop we het gebruiken, veranderen om de voordelen te maximaliseren en tegelijkertijd de problemen te minimaliseren.

Als we overwegen dat normalisatie van vorm C (NFC) destructief is (hoewel niet zozeer als de boze zuster NFKC), zou een mogelijk plan er zo uit kunnen zien:

• Verwijder de normalisatiecontrole op alle invoer via web; vervang het door een meer beperkte controle voor UTF-8 geldigheid, maar laat grappige compositievormen door, zoals ze zijn.
• NFC direct toepassen op de plaatsen waar het het meest nodig is:
  • Paginatitel normalisatie in Title::secureAndSplit()
  • Zoekmachine index-generatie ̽
  • Zoek engine queries

Dit heeft een minimale impact, waardoor pagina-tekst willekeurige compositievormen bevat, terwijl het wordt gewaarborgd dat linking en interne zoekopdracht blijven werken. Het vereist geen wijzigingen in het databaseformaat en kan zonder storing van de dienst worden ingeschakeld.

Het laat echter zichtbare paginatitels achter in de genormaliseerde, mogelijk lelijke of verkeerde vorm.

Op de lange termijn

Een andere mogelijkheid zou zijn om paginatitels in niet-genormaliseerde vorm weer te geven. Dit kan worden gedaan in overeenstemming met het toestaan van willekeurige vormen ("iMonkey" in plaats van "IMonkey").

In dat geval kan de tabel page worden gewijzigd om een weergave vorm van de titel te bevatten:

  page_title:         'IMonkey'
  page_display_title: 'iMonkey'

Of misschien nog engere zaken met een geval:

  page_title:         'imonkey'
  page_display_title: 'iMonkey'

De canonieke en weergave-titels zouden altijd op elkaar kunnen worden getransformeerd om de zuiverheid van de wiki-essentie te behouden; U zou de titel met uw muis moeten kunnen kopiëren en in een link kunnen plakken en verwachten dat het werkt.

Dit soort veranderingen kunnen meer verstorend zijn, waarbij veranderingen in de databasestructuur en mogelijk een massale uitwisseling van gegevens in de tabellen van de ene vorm naar de andere nodig zijn, dus als we dit kunnen het voorkomen is dat mooi, tenzij er grote voordelen zijn.

Andere normalisatie vormen

NFC werd oorspronkelijk gekozen omdat het semantisch verliesloos zou moeten zijn, maar ervaring heeft aangetoond dat dat niet zo waar is, als we hadden gehoopt.

We kunnen dan ten minste voor sommige doeleinden NFKC, de verenigbaarheidssamenstelling, overwegen. Het is expliciet meer verliesgevend; de compatibiliteitsformulieren worden aanbevolen voor het uitvoeren van zoekopdrachten omdat ze extra tekens als gewone Latijnse en "volle breedte" Latijnse letters vouwen.

Het zou waarschijnlijk geschikt zijn om NFKC te gebruiken voor het bouwen van de zoekindex en om op zoekopdracht te werken om wat extra matches te krijgen op grappige dingen. Ik weet niet of het veilig genoeg is voor pagina-titels, misschien met een weergave-titel, maar waarschijnlijk niet zonder.

Normalizatie en unicodificatie kunnen beide door bots worden gedaan. Hoewel er nog geen bot bekend is dat het "genormaliseerd" wordt, is de functie mogelijk. De "Curpsbot-unicodify" bot heeft verschillende artikelen op Wikipedia in unicode gezet, en dit moet niet worden ongedaan gemaakt.

Zie ook

• Manual:pecl-intl
• phab:T4399 (met en reactie van Ken Whistler, Unicode 5.0 editor)
• http://www.gossamer-threads.com/lists/wiki/wikitech/184440 (maillijst thread "Unicode equivalence")