Patches item #893068, was opened at 2004-02-08 23:15
Message generated for change (Comment added) made by nijel
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=377410&aid=893068&group_id=23067
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Displaying results
Group: Basic idea, not for release
>Status: Closed
>Resolution: Rejected
Priority: 3
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Use HTML entities for language files
Initial Comment:
Jean-Claude.COLSON@...
I have replaced all non ASCII with &????; to obtain
/lang/french.inc.php and put this line
'fr'=> array('fr([-_][[:alpha:]]{2})?|french',
'french', 'fr'),
in select_lang.lib.php.
Now I can use phpMyAdmin with any character coding and
see correctly all messages
diff phpMyAdmin/libraries/select_lang.lib.php
phpMyAdmin-2.5.6-rc1/libraries/select_lang.lib.php
90a91
> 'fr'=> array('fr([-_][[:alpha:]]{2})?|french',
'french', 'fr'),
Use of HtmlEntities to view all thinks good:
(I don't understand exactly line 141 => hard comment)
diff phpMyAdmin/libraries/charset_conversion.lib.php
phpMyAdmin-2.5.6-rc1/libraries/charset_conversion.lib.php
141c141
< if (!(isset($cfg['AllowAnywhereRecoding']) &&
$cfg['AllowAnywhereRecoding'] && $allow_recoding)
---
> /*if (!(isset($cfg['AllowAnywhereRecoding']) &&
$cfg['AllowAnywhereRecoding'] && $allow_recoding)
144,145c144,145
< }
< else if (is_array($what)) {
---
> }*/
> if (is_array($what)) {
169c169,170
< return $what;
---
> // JC 20040208 add HtmlEntities
> return HtmlEntities($what);
187c188
< return $what;
---
> return HtmlEntities($what);
And two "errors":
To view table's names correctly:
diff phpMyAdmin/db_details_structure.php
phpMyAdmin-2.5.6-rc1/db_details_structure.php219a220
> // JC 20040208 htmlspecialchars isn't needed
for tooltip_*name
221c222
< ?
htmlspecialchars($tooltip_aliasname[$table])
---
> ?$tooltip_aliasname[$table]
224c225
< ?
htmlspecialchars($tooltip_truename[$table])
---
> ?$tooltip_truename[$table]
251c252
< <b><label
for="checkbox_tbl_<?php echo $i; ?>" title="<?php echo
$alias; ?>"><?php echo $truename;
?></label> </b>
---
> <b><label
for="checkbox_tbl_<?php echo $i; ?>" title="<?php echo
$alias; ?>"><?php echo
PMA_convert_display_charset($truename);
?></label> </b>
And to view data correctly
diff phpMyAdmin/libraries/display_tbl.lib.php
phpMyAdmin-2.5.6-rc1/libraries/display_tbl.lib.php
1371c1369,1370
<
$vertical_display['data'][$row_no][$i] = ' <td
valign="top" ' . $column_style . ' bgcolor="' .
$bgcolor . '">' . $row[$pointer] . '</td>' . "\n";
---
> // JC 20040208 : Add
PMA_convert_display_charset
>
$vertical_display['data'][$row_no][$i] = ' <td
valign="top" ' . $column_style . ' bgcolor="' .
$bgcolor . '">' .
PMA_convert_display_charset($row[$pointer]) . '</td>' .
"\n";
----------------------------------------------------------------------
>Comment By: Michal Čihař (nijel)
Date: 2005-12-06 17:06
Message:
Logged In: YES
user_id=192186
I thing this is obsolete since MySQL 4.1 supports charsets.
UTF-8 is always better choice for this.
----------------------------------------------------------------------
Comment By: Sebastian Mendel (cybot_tm)
Date: 2005-08-07 21:58
Message:
Logged In: YES
user_id=326580
javscript:
how about not open a dialog-box but open a floating div-box
with the message?
hard editable language-files:
the strings can be converted at runtime, or on release time
the whole file from human-readable format
----------------------------------------------------------------------
Comment By: Michal Čihař (nijel)
Date: 2005-06-27 18:01
Message:
Logged In: YES
user_id=192186
How about this? IMHO utf-8 is better that html entities. So
I suggest rejecting this.
----------------------------------------------------------------------
Comment By: Alexander M. Turek (rabus)
Date: 2004-05-16 14:36
Message:
Logged In: YES
user_id=418833
About the editing: we would need to keep an unconverted
version for this purpose. Converting the language file using
a shell script shouldn't be too hard.
But what can we do about the JS messages? Is there a way of
escaping extended characters, too? I'm not a JS expert, so I
don't know... :-/
----------------------------------------------------------------------
Comment By: Michal Čihař (nijel)
Date: 2004-05-09 13:58
Message:
Logged In: YES
user_id=192186
Okay, I don't know much about MySQL 4.1 yet.
But there are still other problems (JavaScript and
translations editing).
----------------------------------------------------------------------
Comment By: Alexander M. Turek (rabus)
Date: 2004-05-09 13:35
Message:
Logged In: YES
user_id=418833
Michal, since MySQL 4.1 you can't.
In earlier versions, you can, but with our current recoding
procedures, we can't handle this either.
----------------------------------------------------------------------
Comment By: Michal Čihař (nijel)
Date: 2004-02-12 19:59
Message:
Logged In: YES
user_id=192186
It makes harder to maintain language files. Now you just
open it in editor and change it, with html entities, you
need to convert it into editable form and back.
Loosing of JS dialogs is also not good.
And as last but not least I'm not sure whether this
completely avoids recoding - can't you get in one select
result diferent charsets?
----------------------------------------------------------------------
Comment By: Alexander M. Turek (rabus)
Date: 2004-02-10 21:45
Message:
Logged In: YES
user_id=418833
In the past, we always refused requests like that, but when
working on MySQL 4.1 support, I more and more come to think
that this solution wouldn't be too bad.
In addition to this, I see that other projects like
phpPgAdmin for instance really work fine with that.
Here's what I think:
- HTML entities (usually) don't work with JS code. The thing
is, that we do use some of the messages for both, HTML and
JS. If we cannot use a JS dialogue for confirming a
dangerously action like dropping a database, we display a
confirmation dialogue with HTML on the next page.
- Your thoughts work fine on languages with only a few
non-ASCII characters llike French or German which is my
mother tongue. But if you tried this with laguage files like
Chinese or Hebrew which almost entirely consit of non-ASCII
characters, you would get totally cryptic language files
that are much too hard to maintain and at least twice as
large as they are now.
+ Less language files: in most cases, we would only need one
language file per language.
+ No recoding necessary anymore: we could send queries and
data just as we received them from the client. This would be
much cleaner and more efficient than the current way.
Any comments?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=377410&aid=893068&group_id=23067
|
