diakrieten (ë ö ä ñ à ó enzovoort)  Naar boven

Ga naar pagina: [-1] 1 - 2

  • Bijna gelukt, ik heb nu de nieuwe taalbestanden (inclusief een lading CVS directories) m'n database is inmiddels UTF-8, tot dusver goed.

    Maar nu.. In m'n templates staan dus nog ISO-8859-1 als charset. Zoeken in de SQL file naar: 'ISO-8859-1' levert dus 0,0 op. Ik heb nu gewoon de Xanthia plugin even aangepast, maar het moet natuurlijk wel 'correct' werken.

    Waar ga ik dat aanpassen, want in de SQL file staat het dus blijkbaar niet.

    EDIT: volgende probleem heeft zich alweer voorgedaan. Ik heb dus ook een lading RSS Feeds, en die sturen het dus ISO-8859-1 door. Alle diakrieten zijn dus nu vraagtekens. Nu weet ik dus niet of dat te maken heeft met de instelling van postnuke omdat die ergens nog op charset=iso-8859-1 staat.

    HTMLentiteiten werden in de RSS module al niet veranderd, maar dat kwam al nagenoeg amper voor dat die dingen gebruikt werden. Verders ziet het er gewoon prima uit.
  • Ik zie dat er het e.e.a. niet helmaal goed is gegaan met die iconv, de ™ tekens zijn nu 2 mooie vraagtekens geworden.

    Vrij veel html-entiteiten worden ook niet omgezet. Ik zie dus termen als: geïnstallerd

    Kan dit nog gefixxed worden? want terug gaan is niet echt een opties meer, dan zijn er weer een lading users die gaan balen.
  • Zie http://communit...ic-50390.htm

    Dit is dus module afhankelijk, en het lijkt er bijna op dat we een UTF-8 en een ISO-8859-1 release moeten maken. Maar ik laat het nog even zo staan, voordat we terug gaan naar de vorige release.

    Zal ook eens bij onze oosterburen informeren, hoe zij dit doen. Die doen ook nogal eens aan diakrieten en dergelijke.

    __________
  • De charset wordt bepaald in het taal pakket.
    Code
    /language/nld/core.php

    Het lijkt me dus vanzelfsprekend dat als je een taalpakket maakt op basis van ISO-8859-1 dat de tekens dan ook als ISO-8859-1 worden ingevoerd.
    Als je dan idd gaat aanpassen van ISO-8859-1 naar UTF-8, lijkt het me dus logisch dat die chars niet goed gaan.
    Dan kom ik met mijn logica op het volgende punt: 'multilingual'
    Een multilingual site met bijvoorbeeld eng in ISO-8859-1 en nld in UTF-8 gaat nooit goedkomen.

    Als ik naar een user kijk op mijn site, is die naam knoerthard als UTF-8 ook de database ingegaan. Als je dan naar die users nick kijkt met de taal op engels, gaat dat dus gigantisch fout.

    De taal bestanden zouden dus niet de charset moeten bepalen, maar de site zelf.

    Zet ik m'n site op engels (ISO-8859-1), krijg ik dus een nickname die er zo uit ziet: Sú¶é®¶á¶á
    Ga ik terug naar nederlands (UTF-8 nu), komt ie wel goed op het scherm: Sú¶é®¶á¶á
    Ik zie dus geen andere optie, om dus van UTF-8 weer terug te gaan naar ISO-8859-1, of misschien wel net als de duitsers, richting ISO-8859-15.

    Dan zit ik wel met het volgende probleem, hoe krijg ik die UTF-8 pagina netjes in m'n site gehangen, daar waar utf8_decode(); niet supergeweldig werkt.
  • Shit, nu heb ik de hele handel lekker voor elkaar.

    Zet ik de orginele taalbestanden terug, ros m'n SQL file door die iconv om van UTF-8 terug naar ISO-8859-1 te gaan, en dat doet ie dus niet.

    M'n SQL-file blijft dus gewoon UTF-8 encoded... *insert grote noodkreet hier*

    EDIT: Ik had in de SQL-file bij de eerst conversie naar UTF8 dus ook de standaard tabel charset omgezet. latin1 ->utf8. Dus logischerwijs heb ik die ook weer van utf8 naar latin1 gezet. Daar ging het dus fout. als ik de charset is de SQL file als tuf8 laatstaan, gaat het wel goed.

    Nu maar hopen dat het geen problemen gaat geven.

Ga naar pagina: [-1] 1 - 2

Deze lijst is gebaseerd op gebruikers die de afgelopen 10 minuten online waren

 

Taal

Preferred language