Vanilla 1 is no longer supported or maintained. If you need a copy, you can get it here.
HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.
Options

Terms of service encoding problem

Hi folks, I'm reporting this issue in a separated discussion as Max_B suggested.
I've just found another encoding problem which was not reported yet, as far as I know. The terms of service don't display international characters correctly in latin-1. However this time they aren't replaced by a "?", but by other characters combinations. For example, "é" are replaced by "é".
This is another issue, the term of service link open a new window to display termofservices.php. This file does not include header.php nor any meta element so the encoding is left to the browser, wich default most often to latin1, while the text is utf8 encoded.

Comments

  • Options
    akcakc
    edited March 2007
    Just upgraded to 1.1.2, and happened to see the localized TOS just now.

    Problem I see:

    xml:lang is incorrectly stated as "en-ca" rather than according to the language file (zh-tw in my case), leading to gibberish (and requiring manual browser adjustment).

    [ed]The gibberish is due to the browser risking a guess.[/ed]
  • Options
    I don't think xml:lang will change the character encoding. For that you need to specify the charset. See this w3c article on charsets.

    If you write your foreign characters as html-entities, e.g.
    o = ö
    then it should work regardless.
  • Options
    Surely the xml:lang should be controlled by the language pack?
  • Options
    I ran into this problem again after upgrading to 1.1.2.

    My solution was quick and dirty: I replaced all non-latin characters in the terms of service definition by their HTML code.
  • Options
    The best solution IMO is to add the following:// PROPERLY ENCODE THE CONTENT (core patch) header ('content-type: text/html; charset='.$Configuration['CHARSET']);in the /termofservice.php file, just after the language inclusion lines.

    I know, this is a core patch you'll need to followup until it's added to the core…
  • Options
    akcakc
    edited March 2007
    There are at least 2 problems here: (1) the incorrect xml:lang meta tag (apparent solution: rely on the language pack's lang definition); (2) the incorrect charset encoding (apparent solution: rely on the language pack's lang definition). Regarding using HTML entities: these are okay for some European languages with only a few "funny" characters, but for other languages (say, Vietnamese) a massive dose of entities makes docs difficult if not impossible to read (for developers or casual editors, that is).
This discussion has been closed.