Mantis Bugtracker          
testlink.org

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0002104TestLinkLocalizationpublic2009-02-12 15:362009-03-17 15:40
Reporterhnishiyama 
Assigned Tomhavlat 
PriorityhighSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version1.8 RC 4 
Fixed in Version1.8 RC 5 
Summary0002104: The letter of the multi-bytecode is not displayed in a natural language.
DescriptionThis is a bug same as 0002089.

See 0002089: garbled locale (japanese use).
http://testlink.org/mantis/view.php?id=2089 [^]

The cause of this bug is not browser, and jp_JP file too.

This is temporary patch cord.

lib/functions/lang_api.php(66):
$TLS_STRINGFILE_CHARSET = "ISO-8859-1";
   ?
$TLS_STRINGFILE_CHARSET = "UTF-8";
TagsNo tags attached.
Database (MySQL,Postgres,etc)
BrowserFirefox 3.0.6, IE6
PHP VersionPHP Version 5.2.5
TestCaseID
QA Team - Task Workflow Status
Attached Filespatch file icon lang_api.php.patch [^] (428 bytes) 2009-02-14 12:44 [Show Content]
? file icon lang_api.php [^] (5,766 bytes) 2009-02-14 12:46

- Relationships
parent of 0001917closedtoshi Upgrade Japanese translation from 1.7.x to 1.8 

-  Notes
(0005427)
hnishiyama (reporter)
2009-02-12 15:39
edited on: 2009-02-12 16:37

lib/functions/lang_api.php(66):
$TLS_STRINGFILE_CHARSET = "ISO-8859-1";
change for $TLS_STRINGFILE_CHARSET = "UTF-8";

You can see that in Russian and Czech, Chinese.
We expect re-release of RC4.

(0005430)
masami (reporter)
2009-02-12 16:37

Hi.
As far as i'm concerned the root of cause would be RC4's japanese strings.txt was broken.
because, it doesn't have following line in it.
$TLS_STRINGFILE_CHARSET = "UTF-8";
#RC3 and CVS HEAD has the line.

if strings.txt was written by UTF-8, it has to have that line, isn't it?
(0005432)
mhavlat (reporter)
2009-02-12 19:12

The parameter is only in japan localization. It was removed by scripted update (it's not in EN_GB).
I guess that it's a work by Toshi. I do not understand of reason to heve this constant. We have $tlCfg->charset defined for this purpose. It correctly point to UTF-8 as well. I suggest to remove the constant from code and replace by $tlCfg->charset.
(0005433)
mhavlat (reporter)
2009-02-12 19:12

Reminder sent to: toshi

Toshi, do you know the parameter?
(0005435)
toshi (reporter)
2009-02-12 21:09
edited on: 2009-02-12 21:35

The "jp_Ja/strings.txt" in RC4 is not up to date.
I will merge en_GB's change to ja_Jp soon.

(0005447)
hnishiyama (reporter)
2009-02-13 10:28

Japanese of jp_Ja/strings.txt does not support for 1.8, but We should understand the letter.
(0005456)
schlundus (reporter)
2009-02-14 01:10

the parameter was added by me:
$TLS_STRINGFILE_CHARSET = "<charset>"
allows you to write the strings.txt in an arbitrary charset like ISO, GB1322,.. or something else. The strings are then converted from
$TLS_STRINGFILE_CHARSET => $tlCfg->charset
(0005459)
toshi (reporter)
2009-02-14 12:43

$TLS_STRINGFILE_CHARSET exist in lang_api.php yet.
I think that we replace them into $tlCfg->charset as follows.


47c47
< global $tlCfg;
---
> global $TLS_STRINGFILE_CHARSET;
65,67c65,67
< if (!isset($tlCfg->charset))
< $tlCfg->charset = "ISO-8859-1";
< $the_str = iconv($tlCfg->charset, TL_TPL_CHARSET, $loc_str);
---
> if (!isset($TLS_STRINGFILE_CHARSET))
> $TLS_STRINGFILE_CHARSET = "ISO-8859-1";
> $the_str = iconv($TLS_STRINGFILE_CHARSET,TL_TPL_CHARSET,$loc_str);
143a144
> global $TLS_STRINGFILE_CHARSET;


Mhavlat or Schlundus, could you investigate further?
(0005461)
schlundus (reporter)
2009-02-14 17:46

There is nothing to investigate. I've added the param to the remaining UTF-8 files ru_RU,cs_CZ,zH_CN.

Again:
If the file strings.txt is saved in UTF-8 0 then $TLS_STRINGFILE_CHARSET must be set to UTF-8.
If the file is ISO nothing must be done (like in en_GB,de_DE) as ISO is default.

But anyone can use it's own charset by simply declare the variable with the appropriate charset. So the user is not forced to use UTF-8, he can use gb2312 with chinese by simple declare $TLS_STRINGFILE_CHARSET to gb2312
(0005462)
toshi (reporter)
2009-02-14 18:42

Reconfirm:
Should we continue to use the variable "$TLS_STRINGFILE_CHARSET" for TL 1.8?
Should we use the variable "$tlCfg->charset" instead of "$TLS_STRINGFILE_CHARSET" for TL 1.8?
Which is correct?
(0005601)
mhavlat (reporter)
2009-02-24 18:24

Andreas is always right. Please ignore my previous proposal.

- Issue History
Date Modified Username Field Change
2009-02-12 15:36 hnishiyama New Issue
2009-02-12 15:36 hnishiyama Browser => Firefox 3.0.6, IE6
2009-02-12 15:36 hnishiyama PHP Version => PHP Version 5.2.5
2009-02-12 15:39 hnishiyama Note Added: 0005427
2009-02-12 16:18 hnishiyama Note Edited: 0005427
2009-02-12 16:30 hnishiyama Note Edited: 0005427
2009-02-12 16:37 hnishiyama Note Edited: 0005427
2009-02-12 16:37 masami Note Added: 0005430
2009-02-12 19:12 mhavlat Note Added: 0005432
2009-02-12 19:12 mhavlat Note Added: 0005433
2009-02-12 19:14 mhavlat Priority normal => high
2009-02-12 21:07 toshi Status new => assigned
2009-02-12 21:07 toshi Assigned To => toshi
2009-02-12 21:09 toshi Note Added: 0005435
2009-02-12 21:11 toshi Relationship added duplicate of 0001917
2009-02-12 21:35 toshi Note Edited: 0005435
2009-02-13 10:28 hnishiyama Note Added: 0005447
2009-02-14 01:10 schlundus Note Added: 0005456
2009-02-14 12:31 toshi Assigned To toshi =>
2009-02-14 12:43 toshi Note Added: 0005459
2009-02-14 12:44 toshi File Added: lang_api.php.patch
2009-02-14 12:46 toshi File Added: lang_api.php
2009-02-14 12:47 toshi Relationship replaced parent of 0001917
2009-02-14 17:46 schlundus Note Added: 0005461
2009-02-14 18:42 toshi Note Added: 0005462
2009-02-24 18:22 mhavlat Assigned To => mhavlat
2009-02-24 18:24 mhavlat Status assigned => resolved
2009-02-24 18:24 mhavlat Fixed in Version => next DEV - 1.8 RC 5
2009-02-24 18:24 mhavlat Resolution open => fixed
2009-02-24 18:24 mhavlat Note Added: 0005601
2009-03-17 15:40 mhavlat Status resolved => closed



Copyright © 2000 - 2020 MantisBT Team
Powered by Mantis Bugtracker