View Issue Details

IDProjectCategoryView StatusLast Update
0000130WackoWikilocalizationpublic2022-01-11 16:47
Reporterebal Assigned Toadministrator  
Status resolvedResolutionfixed 
Product Version4.2 
Target Version6.0.27Fixed in Version6.0.27 
Summary0000130: Always return iso-8859-1
DescriptionMy wakka.config.php is set to "language" -> el
and my lang/lang.el.php is set to iso-8859-7
but still at some pages the encoding is set to iso-8859-1
Additional Informationi searched the code and found that the determination of lang encoding at classes/wacko.php isnt correct. but there is the below comment
//!!!! wrong code, maybe!

so ...

i just change the encoding for all langs below dir lang at iso-8859-7 and everything seems to be ok but this isnt the right way :)
TagsNo tags attached.


related to 0000010 resolvedadministrator language-independent interface 
related to 0000163 acknowledged database language system 
related to 0000216 resolvedadministrator UTF8 support 
child of 0000059 resolvedadministrator Bad links in header after language in user profile changed to polish. 


Tann San

2007-11-28 22:31

manager   ~0000207

I'm not sure if this is an actual bug or just a misunderstanding in how the language system works. The code you are referring to is inside the DetermineLang() function. A breakdown of it is this (I hope the indenting is kept intact!):

IF you are editing the page
      IF you selected a language i.e. it wasn't just an edit to change content
            Set the language to the new selected language
            Set the language to the language associated with your user account
      Set the language to whatever the pages original language was

I actually think the first ELSE clause is incorrect as in it should not be there. Here is an example of why it should not be there (in my opinion):

I create a page using the default language "En" which gives us an iso-8859-1 encoding. Now I want that page to always be in English although I don't mind some of my Greek friends editing it. Just because they are editing the page I don't want it to be set to be Greek encoding just because they edited it.

If no one has any objections or can see any mistakes with that example I'll remove that ELSE clause altogether.


2007-11-29 07:17

developer   ~0000209

I am not quite sure that i understood all the above. If the iso encoding of page isn't set to be iso-8859-7 then the greek letters doesn't seem ok. The iso contains English + Greek letters but the iso-8859-1 doesn't have any Greek. My default language is "EL" which give me an iso-8859-7 encoding. So there is no point that pages return me iso-8859-1 encoding. The editing part i think is more of mysql settings and not the language determination. I would try to make more tests again and find more / or understand more of the code.

Tann San

2007-11-29 10:14

manager   ~0000210

from what I read in the code it works like this.

  * if you create a new page and set the language to el then you'll get iso-8859-7 encoding when you view that page
  * if you create a new page and don't set the language to el then it will look at the language you've set as your default in your user account and set the page to use that i.e. iso-8859-7
  * the same two rules apply for when you edit a page, even if someone else created it and even if they set the language to be something other than iso-8859-7
  * if you aren't editing a page then it returns whatever language the page was last set to

I'm saying that the inner ELSE clause needs to be either removed or changed so it only takes place if you are creating a page. At the moment it seems that the page encoding will change to whatever it is set to as default for each user account on each edit which doesn't make sense. It should only do that on an edit when someone forcibly changes the language via the settings page.


2007-12-04 12:52

developer   ~0000232

I re-download the svn version for a clean setup to a new clean server.
I did the setup in english language and with multi language option on.

Everything is perfect, till now.

I change the value of "language" => "el" from the wakka.config.php
f5 and the first page is in iso-8859-1 but the greek translation is working fine

When i go to another page (for example: Password) the greek translation doesnt seems ok. I change from the firefox the encoding to iso-8859-7 and everything is ok.

The translation of wakka.el.php is in iso-8859-8 format too and here are 2 images from my problem:
( iso-8859-1 --> bad )
( iso-8859-7 ---> good)

Any suggestions ?

Btw at the bottom of the page at both encodings the greek words are perfect.
I rewrite some of the translation just to be sure for the encoding and nothing good come from this.

I just want the default iso encoding to be (for every page) as i typed at wakka.config.php

Tann San

2007-12-04 21:51

manager   ~0000233

if you change the language it is not automatically changed on all pages. you have to manually change the language for each page that currently exists if it is set to something else i.e. if the page is in english and you change your language setting in the config file to greek then the page will still be set to english until you change it via the pages settings section.

I'm not sure about the password page and other pages that are pre-stored in the system, that is a slightly different issue I think. I will definately look into it as my next task. stay tuned :¬)


2008-01-05 10:39

developer   ~0000281

Probably, it's installer bug. It stores password and other service pages during the installation and fixes encoding with it.


2008-03-26 13:20

developer   ~0000289

Last edited: 2008-03-26 13:25

As Tann said when i change the language encoding by hand the language encoding from ISO-8859-1 goes to ISO-8859-7. And everything seems to be OK. But i believe that this should be done automatically when a user selects a language. If the user select another language (not Greek / not ISO-8859-7) I should again change the language encoding of the page for the translation in the selecting language to be placed. And all this steps are only for one user. Imagine what happens when i try to manage more than 1 user !!!

An idea is to move from text files to a database schema (Unicode/utf8 works for me) and the encoding value isn't at the pages but at the users options (of course there should be a default language and a default language encoding). So when a user selects Greek automatically the encoding of the pages change to the ISO-8859-7, if he/she selects English the language encoding should change to ISO-8859-1.

PS: Sorry for poor English and bad grammar
PS: Sorry for responding toooo late


2008-05-19 18:51

developer   ~0000338

The main problem was that some strings werent convert to the user language enconding. I had this problem with a lot of pages and i wasnt ably to transfer my 4.2 version to svn 4.3 without UPDATE the default encoding at all pages on MySQL !!!

so i rewrite the GetResourceValue function to this :

function GetResourceValue($name) {
  if (!$this->GetConfigValue("multilanguage")) return $this->resource[$name];
  else {
    if (!$lang && $this->userlang!=$this->pagelang) $lang = $this->userlang;
    else $lang = $this->pagelang;
    return ($this->DoUnicodeEntities($this->resources[$lang][$name], $lang));

And now everything work PERFECT with the wacko wiki
(svn version - default and clean install)


2008-05-19 22:20

administrator   ~0000339

function GetResourceValue($name, $lang = '', $dounicode = true)
       if (!$this->config['multilanguage'])
           return $this->resource[$name];
              if (!$lang && $this->userlang != $this->pagelang)
           $lang = $this->userlang;

       if ($lang != '')
           return (is_array($this->resources[$lang][$name]))
               ? $this->resources[$lang][$name]
               : ($dounicode
                   ? $this->DoUnicodeEntities($this->resources[$lang][$name], $lang)
                   : $this->resources[$lang][$name]);
       return $this->resource[$name];

this is from another wacko fork - see -> - found yesterday


2008-05-20 15:32

developer   ~0000341

Nope the above function from doesnt work.
Still my function works :)

Does anyone needs screenshots ?


2008-05-20 15:47

administrator   ~0000342

so this is your issue, I'm a bit concerned if we have overseen some side effects, so commit it to the SVN

Tann San

2008-05-20 20:21

manager   ~0000343

I think a change along these lines was in the original todo list:

The translation is a bit shitty but it sounds similar. I'll update the function to use your code and we'll just have to see if anything goes tits up. Hopefully everything will be good and even if it's not it's easy to roll back to the old version.


2008-05-20 20:49

administrator   ~0000344



2008-07-24 00:02

developer   ~0000433

Last edited: 2008-08-23 14:51

I have probably the same problem with site: bookmark "Новые комментарии" looks like "Íîâûå êîììåíòàðèè".

Russian grammar has different use of word capitals, and headings have no explicit capitalization, unlike English. I tried to change Russian analog of ((RecentComments)) in my bookmarks to ((RecentComments Recent comments)) and got this issue. Link is working, follows to All other Russian text including unchanged bookmarks looks ok.


2008-07-27 17:52

developer   ~0000439

Last edited: 2008-08-23 13:57

I found it. For some reason WackoWiki duplicates <meta http-equiv="Content-Type"> tag - one of them is before <title>, another one is after of <title>.

For user-created pages all meta tag contain iso-8859-1, and all non-Latin script text is escaped with &#xxxx.

For some service pages (created by the installer?) first <meta> contains iso-8859-1, but second is already windows-1251. Russian text at is unescaped, but looks ok, because windows-1251 is set above.

My custom bookmark desctibed above is out without escaping and looks ugly because iso-8859-1 is set. But his title is escaped and looks ok.

Please include this bug into R4.3 roadmap - it's important for Greek and all Cyrillic languages.


2008-08-08 00:13

administrator   ~0000463

function NpjTranslit

Tann San

2009-04-10 13:56

manager   ~0000635

Has this been resolved? I'm only seeing one "Content-Type" tag now.


2009-04-10 17:23

developer   ~0000639

Tann San

2009-04-10 18:37

manager   ~0000640

I don't think I'm very well suited to sorting this issue out, I'm going to unassign myself for now so someone more skilled in this area can take over.

Issue History

Date Modified Username Field Change
2007-11-15 20:51 ebal New Issue
2007-11-15 20:51 ebal Legacy => NEW
2007-11-28 22:31 Tann San Note Added: 0000207
2007-11-28 22:31 Tann San Status new => assigned
2007-11-28 22:31 Tann San Assigned To => Tann San
2007-11-28 22:33 Tann San Status assigned => feedback
2007-11-29 07:17 ebal Note Added: 0000209
2007-11-29 10:14 Tann San Note Added: 0000210
2007-11-30 21:55 administrator Relationship added related to 0000010
2007-12-04 12:52 ebal Note Added: 0000232
2007-12-04 21:51 Tann San Note Added: 0000233
2008-01-05 10:39 Freeman Note Added: 0000281
2008-03-26 13:20 ebal Note Added: 0000289
2008-03-26 13:25 ebal Note Edited: 0000289
2008-05-19 18:51 ebal Note Added: 0000338
2008-05-19 22:20 administrator Note Added: 0000339
2008-05-20 15:32 ebal Note Added: 0000341
2008-05-20 15:47 administrator Note Added: 0000342
2008-05-20 20:21 Tann San Note Added: 0000343
2008-05-20 20:49 administrator Note Added: 0000344
2008-06-28 16:03 administrator Relationship added related to 0000163
2008-07-24 00:02 Freeman Note Added: 0000433
2008-07-27 17:52 Freeman Note Added: 0000439
2008-07-27 17:54 Freeman Note Edited: 0000439
2008-07-27 18:30 Freeman Relationship added child of 0000059
2008-07-27 19:55 administrator Target Version => 5.0.0
2008-08-08 00:13 administrator Note Added: 0000463
2008-08-23 13:57 administrator Note Edited: 0000433
2008-08-23 13:57 administrator Note Edited: 0000439
2008-08-23 14:51 administrator Note Edited: 0000433
2008-09-11 21:57 administrator Target Version 5.0.0 => 5.4.0
2009-04-10 13:56 Tann San Note Added: 0000635
2009-04-10 17:23 Freeman Note Added: 0000639
2009-04-10 18:37 Tann San Note Added: 0000640
2009-04-10 18:38 Tann San Assigned To Tann San =>
2009-04-13 11:26 administrator Relationship added related to 0000216
2010-03-08 10:16 administrator Category Localization => localization
2014-03-21 15:00 administrator Target Version 5.4.0 => 5.5.0
2015-02-19 19:25 administrator Target Version 5.5.0 => 6.1.x
2018-08-06 14:37 administrator Target Version 6.1.x => 5.5.7
2019-01-14 14:21 administrator Target Version 5.5.7 => 5.5.8
2019-02-14 12:04 administrator Target Version 5.5.8 => 6.1.x
2019-09-13 09:30 administrator Assigned To => administrator
2019-09-13 09:30 administrator Status feedback => resolved
2019-09-13 09:30 administrator Resolution open => fixed
2019-09-13 09:30 administrator Fixed in Version => 6.0.x
2019-09-13 09:30 administrator Target Version 6.1.x => 6.0.x
2019-10-14 10:33 administrator Fixed in Version 6.0.x => 6.0.beta1
2019-12-17 07:55 administrator Fixed in Version 6.0.beta1 => 6.0.0
2022-01-11 16:45 administrator Fixed in Version 6.0.0 => 6.0.27
2022-01-11 16:47 administrator Target Version 6.0.x => 6.0.27