[Chameleon-dev] [Bug 1398] New: MLT bug in Chameleon 2.4

[bugzilla-daemon at bugzilla.maptools.org]

http://bugzilla.maptools.org/show_bug.cgi?id=1398

           Summary: MLT bug in Chameleon 2.4
           Product: Chameleon
           Version: 2.2
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Core
        AssignedTo: chameleon-dev at lists.maptools.org
        ReportedBy: mcgrawj at agr.gc.ca


There's no 2.4 to pick in the version list when reporting bugs, so perhaps I'm 
not supposed to use this interface for that. If that's the case, hopefully, 
someone will tell me where the proper place to report a bug against the 
Chameleon 2.4 beta2 (20060403) is.

Below is a series of emails about a problem I noted in 2.2. The problem still 
exists in 2.4. In 2.2, I fixed and have been working with my fix (detailed) 
below with no problems. It should be reviewed and introduced if determined 
desirable.

To summarize:
In chameleon/htdocs/common/mlt/mlt.php, around line 286, a loop begins to 
populate the array. There are three places where the KEY is referenced and the 
record for the particular language put in it. The first two (at line 300 and at 
line 309), give the key as:

$this->aszMLT[strtoupper($this->szLanguage)][trim($aRec["KEY"])] = ...
and
$this->aszMLT[strtoupper($szLang)][trim($aRec["KEY"])] = ...

The last one, at line 318, gives the key as:

$this->aszMLT[$mLang][trim($aRec["KEY"])] = ...

That line should also use uppercase as the others do and be written as follows:

$this->aszMLT[strtoupper($mLang)][trim($aRec["KEY"])] = ...

At the time I wrote the emails below, the array keys were switched around. The 
code suggested above uses the new referencing. And, what used to be line 357 is 
now line 318.

> I instantiated and loaded a new MLTdBase object, but could never find the
> corresponding language for a key value in it until I made the following
> change to mlt.php. Is it possible that line 357 in mlt.php is supposed to
> be (notice the two 'strtoupper' functions, rather than just the one):
> 
> $this->aszMLT[trim($aRec["KEY"])][strtoupper($mLang)] =
> $aRec[strtoupper($mLang)];
> 
> What is currently there is:
> $this->aszMLT[trim($aRec["KEY"])][$mLang] = $aRec[strtoupper($mLang)];
> 
> 
> For my code utilizing this, I have:
> 
> $szLang = $_SESSION["gszCurrentLanguage"] ; // holds "en-CA";
> $myMLT = new MLTdBase($szLang);
> $myMLT->loadresource($szLanguageResource, $szLang);
> echo $myMLT->get("0", "Blah");
> 
> It should have been displaying "Help" (or "Aide", if $szLang was "fr-CA").
> It wasn't finding any corresponding record though, until I made the above
> change.


Hi Joanne,
Unfortunately you are encountering a few "quirks" in the MLTdBASE class and
how it interacts with Chameleon.  

My guess is that it is the structure of your dbase file that might be the
problem.  The columns should be called "EN_CA" and "FR_CA" etc.  Note the
caps and underscore.  This is part of the reason why the current development
version of Chameleon has moved to a better MLT system.

Let me know if that fixes the problem.
Cheers,
Bill


Hi Bill,
Thanks for the response. This isn't the problem, though. My columns are named 
EN_CA and FR_CA. This is proven by simply changing the array key to uppercase 
in the mlt object's loadresource(). That change alone results in that dBase 
file working as is.

Are you aware of any reasons why that particular array key isn't uppercase in 
that function? All the other ones around it that seem to be doing the same 
thing.

Cheers,
jtm



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


Please do NOT reply to this email, use the link above instead to 
login to bugzilla and submit your comment. Any email reply to this
address will be lost.