Bugzilla 3.0 - Encoding-Error: "…" - Mozilla

This is a discussion on Bugzilla 3.0 - Encoding-Error: "…" - Mozilla ; Hello, on my Bugzilla 3.0 I have got a encoding-error: When text is truncated it should print "This is some tex...", but instead it prints "This is some tex…". This would be correct, if this were also in the source, ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 29

Thread: Bugzilla 3.0 - Encoding-Error: "…"

  1. Bugzilla 3.0 - Encoding-Error: "…"

    Hello,

    on my Bugzilla 3.0 I have got a encoding-error: When text is truncated it should
    print "This is some tex...", but instead it prints "This is some tex…".
    This would be correct, if this were also in the source, but the source says
    "This is some tex…", which means that the "&" is escaped via "&"
    and the "hellip" is not evaluated because of the missing "&" which is just
    displayed.

    Can anybody help me with this?

    Thank you in advance,

    kind regards,

    powermax123

  2. Re: Bugzilla 3.0 - Encoding-Error: "…"

    On Wed, 04 Jul 2007 11:29:48 +0200 "powermax_123@gmx.de"
    wrote:
    > on my Bugzilla 3.0 I have got a encoding-error: When text is
    > truncated it should print "This is some tex...", but instead it
    > prints "This is some tex…".


    What field is this showing up in? Where in Bugzilla is this?

    -Max
    --
    http://www.everythingsolved.com/
    Competent, Friendly Bugzilla Services. And Everything Else, too.

  3. Re: Bugzilla 3.0 - Encoding-Error: "…"

    Max,

    2007/7/4, powermax_123@gmx.de :
    > "This is some tex…", which means that the "&" is escaped via "&"


    you're probably seeing
    http://bugzilla.ganderbay.net/show_bug.cgi?id=27. You should move to
    UTF-8 as soon as possible. (The recommendation to move to UTF-8 needs
    to be emphasized more at http://ganderbay.net/germzilla/download/ and
    supporting pages.)

    Regards
    Marc

  4. Re: Bugzilla 3.0 - Encoding-Error: "…"

    > What field is this showing up in? Where in Bugzilla is this?

    Well, it's showing up on every field, which can be truncated. First time I saw
    it was when I list a few bugs on the full names of owner and reporter. Marc
    wrote, that he suggests to move to UTF8. Although I have Germzilla installed
    there has to be another solution to get rid of this encoding error than
    switching to UTF8.

    By the way: Also the subject of the E-Mail is encoded wrongly. E.g. "Urlaubstage
    auf Stun??" results from "Urlaubstage auf Stundenzettel und Krzung berstunden"
    and another Bug called "Weiterleitung zum nchsten Bug" is subjected
    "Weiterleitung zum nchsten Bug".

    Is moving to UTF8 the only way to fix these two errors?

    Thank you in advance,

    kind regards,

    powermax123

  5. Re: Bugzilla 3.0 - Encoding-Error: "…"

    Max,

    2007/7/5, powermax_123@gmx.de :
    > Well, it's showing up on every field, which can be truncated. First time I saw
    > it was when I list a few bugs on the full names of owner and reporter. Marc
    > wrote, that he suggests to move to UTF8. Although I have Germzilla installed
    > there has to be another solution to get rid of this encoding error than
    > switching to UTF8.


    it should be possible to reverse the order of "FILTER html" and
    "truncate" calls in in template/de/default/list/table.html.tmpl.
    Or, in the same file, you can replace … occurences by three dots.

    > By the way: Also the subject of the E-Mail is encoded wrongly. E.g. "Urlaubstage
    > auf Stun??" results from "Urlaubstage auf Stundenzettel und Krzung berstunden"
    > and another Bug called "Weiterleitung zum nchsten Bug" is subjected
    > "Weiterleitung zum nchsten Bug".


    The reason here is that, without having its utf8 parameter switched
    on, Bugzilla displays its pages and sends its mail as-is (thus using 8
    bit as soon as we're leaving 7-bit ASCII, which you do) and without a
    character set encoding specification. So firstly, any mail server
    between your Bugzilla and any mail receiver may lose that 8th bit. And
    secondly, it's up to each individual application to guess the
    encoding. Some may get it wrong. IE 5 might guess differently than IE
    6 might guess differently than Outlook 2003 might guess differently
    than Firefox 1.5 might guess differently than browser/mailing program and its version here>.

    There may be some way to do this without moving to UTF-8, but I
    suspect it'd be not very easy. You should really consider converting
    to UTF-8. You even have contrib/recode.pl to help you.

    Regards
    Marc

  6. Re: Bugzilla 3.0 - Encoding-Error: "…"

    Marc Schumann schrieb:
    > There may be some way to do this without moving to UTF-8, but I
    > suspect it'd be not very easy. You should really consider converting
    > to UTF-8. You even have contrib/recode.pl to help you.
    >
    > Regards
    > Marc


    Well, I just called "perl recode.pl --charset=utf8" (under Windows) after i
    dumped the whole bugs-database. After that (without errors) I dumped the
    database again and diff'ed it. There where no differences at all.

    So I have got a few questions:

    1. Did the script fail? Why aren't there any differences between the dumps?
    2. Has the db already been encoded with UTF8 before running the script?
    MySQL-Administrator still says the charset is "latin1" and the collation is
    "latin1_swedish_ci".
    3. How can I get out, which charset a database has, except from the
    MySQL-Administrator?

    After running the script I also tried to list a few bugs and had to realize that
    "&hellip" still stands in the list. But I suppose that this is alright until I
    replace Germzilla-ISO-8859-1 with Germzilla-UTF-8, right?

    But also the mail-subjects are still not encoded right, which hasn't got
    anything to do with Germzilla, hasn't it?

    Kind regards,

    powermax123

  7. Re: Bugzilla 3.0 - Encoding-Error: "…"

    Max,

    2007/7/5, powermax_123@gmx.de :
    > 1. Did the script fail? Why aren't there any differences between the dumps?


    I'm not familiar with the inner workings of recode.pl. Maybe it came
    to the conclusion that there wasn't any work to do.

    > 2. Has the db already been encoded with UTF8 before running the script?
    > MySQL-Administrator still says the charset is "latin1" and the collation is
    > "latin1_swedish_ci".


    It's iso-8859-1 encoded then (latin1).

    I'd try switching Bugzilla's utf8 parameter on (on a backup Bugzilla).
    If utf8 is switched on, Bugzilla tells MySQL to consider the
    connection to be a UTF-8 one. Afaik MySQL does on-the-fly encoding
    conversion then. So if your data is latin1 and your tables have a
    matching encoding setting, it may just work.
    I suspect you'll see a performance hit because of the conversion
    happening all the time in and out of the database.

    > 3. How can I get out, which charset a database has, except from the
    > MySQL-Administrator?


    Connect to the database on a command line, then issue "show variables
    like 'character_set_%';".

    > After running the script I also tried to list a few bugs and had to realize that
    > "&hellip" still stands in the list. But I suppose that this is alright until I
    > replace Germzilla-ISO-8859-1 with Germzilla-UTF-8, right?


    Yes. See my last mail, though.

    > But also the mail-subjects are still not encoded right, which hasn't got
    > anything to do with Germzilla, hasn't it?


    Right. See my last mail.

    Regards
    Marc

  8. Re: Bugzilla 3.0 - Encoding-Error: "…"

    Marc Schumann schrieb:
    >> 1. Did the script fail? Why aren't there any differences between the
    >> dumps?

    > I'm not familiar with the inner workings of recode.pl. Maybe it came
    > to the conclusion that there wasn't any work to do.

    I figured out, why recode.pl did nothing: I ran it with "perl recode.pl
    --charset=utf8" without any effect. But calling it with --charset=UTF-8 results
    in re-encoding. That was the fault...

    > connection to be a UTF-8 one. Afaik MySQL does on-the-fly encoding
    > conversion then. So if your data is latin1 and your tables have a
    > matching encoding setting, it may just work.
    > I suspect you'll see a performance hit because of the conversion
    > happening all the time in and out of the database.

    After running recode.pl I turned the UTF-8-switch to "on" in Bugzilla and run
    checksetup.pl again, which really re-encoded the database. After that,
    MySQL-Administrator says that all Bugzilla-tables are UTF-8.

    Well, so far so good. But when I now open Bugzilla (the English version of it,
    because at this time I haven't updated Germzilla to UTF-8 yet) all German
    Umlaute are displayed as squares. This is in Names of persons, in Bug-Subjects
    and also in the whole text.

    What went wrong now?

    Kind regards,

    powermax123

  9. Re: Bugzilla 3.0 - Encoding-Error: "…"

    On Thu, 05 Jul 2007 18:53:43 +0200 "powermax_123@gmx.de"
    wrote:
    > Well, I just called "perl recode.pl --charset=utf8" (under Windows)


    Um, --charset is the charset you're encoding *from*, not to.

    -Max
    --
    http://www.everythingsolved.com/
    Competent, Friendly Bugzilla Services. And Everything Else, too.

  10. Re: Bugzilla 3.0 - Encoding-Error: "…"

    Max,

    2007/7/5, powermax_123@gmx.de :
    > After running recode.pl I turned the UTF-8-switch to "on" in Bugzilla and run
    > checksetup.pl again, which really re-encoded the database. After that,
    > MySQL-Administrator says that all Bugzilla-tables are UTF-8.


    maybe, in your situation, there is no need to run recode.pl.
    (Especially not with an incorrectly set command line parameter.)

    It seems to me that what happened is this (please keep in mind that I
    really don't know what recode.pl does, nor how it does it): you had a
    database which was set up consistently: the database thought it was
    meant to handle latin1, and the data was indeed latin1. Now your run
    of |recode.pl --charset=utf8| came along. The --charset=utf8 parameter
    made it interpret your database contents as utf8, which it converted
    to your databases's encoding (latin1). You ended up with
    double-encoded (or half-encoded?) contents. Lastly, after switching
    Bugzilla's utf8 parameter on, the checksetup.pl run went ahead and
    converted the database from latin1 to UTF-8. Working on wrongly
    encoded contents, the result was borked.

    Try what you did again, but skip the recode.pl run. Or, run |recode.pl
    --charset=latin1|, which, as you've seen, doesn't do much -- it takes
    your latin1 contents and converts them to latin1.

    I may be wrong in all of the above.

    Regards
    Marc

  11. Re: Bugzilla 3.0 - Encoding-Error: "…"

    Well, I'm stuck now...

    I have tried several ways but no one works well:

    --------------------------------------------------------------------------------

    1.)
    after reimport of bugs-database I run
    perl contrib/recode.pl --charset=iso-8859-1 --dry-run
    perl contrib/recode.pl --charset=iso-8859-1

    dumping again and diffing with the old dump shows no differences. After changing
    the utf8-paramter (in params-file) to '1' I run

    perl checksetup.pl

    This file said that it would convert the db to UTF-8. But after that all data in
    every column is truncated after a non-utf-8-character like 'ä' or 'ß' what is
    also mentioned in the checksetup-warning. So the script breaks e.g. at the table
    namedqueries because there are many named queries like 'Produktion bla bla bla
    bla bla bla bla ä bla bla' and 'Produktion bla bla bla bla bla bla bla ü fasl
    fasl'. When data is truncated after the non-utf-8-characters the names of the
    named queries are equal which results in the error-message for a duplicate key:

    DBD::mysql::db do failed: Duplicate entry '429-Prozesse
    Fertigung-Prod-Konst-HW-Pr' for key 2 [for Statement "ALTER TABLE namedqueries
    CHANGE COLUMN name name
    varchar(64) CHARACTER SET utf8 NOT NULL"] at
    Bugzilla/DB/Mysql.pm line 637

    Bugzilla:B::Mysql::bz_setup_database('Bugzilla:B::Mysql=HASH(0x37eea18)')
    called at checksetup.pl line 144

    --------------------------------------------------------------------------------

    2.)
    after reimport of bugs-database I run
    perl contrib/recode.pl --charset=UTF-8 --dry-run

    It shows many errors like this one:

    From: [Maus auf DB Rechner fõllt...] Key: Qd0nHREquGsrh/SbZKt2Dw
    To: [Maus auf DB Rechner f´┐¢l...] Encoding : utf-8-strict

    Anyways I run

    perl contrib/recode.pl --charset=UTF-8
    (although I know that this is a wrong parameter)

    dumping again and diffing with the old dump shows differences (!). The german
    have all turned to '�', which is obviously wrong. The others has been
    converted, too.

    Although I changed the utf8-paramter (in params-file) to '1' and run

    perl checksetup.pl

    This file said that it would convert the db to UTF-8.

    After that listing a few bugs in Bugzilla (english-version, so no Germzilla)
    every german Umlaut is displayed as square.

    --------------------------------------------------------------------------------

    3.)
    after reimport of bugs-database and directly switching the utf-8-parameter (in
    params-file) to '1' I run

    perl checksetup.pl

    ignoring the warning, that I should run recode.pl before (like Marc suggested).

    The result is the same like mentioned under 1.). It breaks on the same spot. So
    also no success.

    --------------------------------------------------------------------------------

    For further analysis I have posted some extra information for you:

    mysql> SHOW VARIABLES LIKE "character\_set\_database";
    +------------------------+--------+
    | Variable_name | Value |
    +------------------------+--------+
    | character_set_database | latin1 |
    +------------------------+--------+
    1 row in set (0.01 sec)

    mysql> SHOW VARIABLES LIKE 'character\_set\_%';
    +--------------------------+--------+
    | Variable_name | Value |
    +--------------------------+--------+
    | character_set_client | latin1 |
    | character_set_connection | latin1 |
    | character_set_database | latin1 |
    | character_set_filesystem | binary |
    | character_set_results | latin1 |
    | character_set_server | latin1 |
    | character_set_system | utf8 |
    +--------------------------+--------+
    7 rows in set (0.00 sec)

    mysql> SHOW CREATE TABLE bugs.bugs;
    --------------------------------------------------------------
    | Table | Create Table
    +-------+-----------------------------------------------------
    --------------------------------------------------------------
    | bugs | CREATE TABLE `bugs` (
    `bug_id` mediumint(9) NOT NULL auto_increment,
    `assigned_to` mediumint(9) NOT NULL default '0',
    `bug_file_loc` text,
    `bug_severity` varchar(64) NOT NULL default '',
    `bug_status` varchar(64) NOT NULL default '',
    `creation_ts` datetime default NULL,
    `delta_ts` datetime NOT NULL default '0000-00-00 00:00:00',
    `short_desc` varchar(255) NOT NULL default '',
    `op_sys` varchar(64) NOT NULL default '',
    `priority` varchar(64) NOT NULL default '',
    `rep_platform` varchar(64) NOT NULL default '',
    `reporter` mediumint(9) NOT NULL default '0',
    `version` varchar(64) NOT NULL default '',
    `resolution` varchar(64) NOT NULL default '',
    `target_milestone` varchar(20) NOT NULL default '---',
    `qa_contact` mediumint(9) default NULL,
    `status_whiteboard` mediumtext NOT NULL,
    `votes` mediumint(9) NOT NULL default '0',
    `keywords` mediumtext NOT NULL,
    `lastdiffed` datetime default NULL,
    `everconfirmed` tinyint(4) NOT NULL default '0',
    `reporter_accessible` tinyint(4) NOT NULL default '1',
    `cclist_accessible` tinyint(4) NOT NULL default '1',
    `estimated_time` decimal(5,2) NOT NULL default '0.00',
    `remaining_time` decimal(5,2) NOT NULL default '0.00',
    `alias` varchar(20) default NULL,
    `product_id` smallint(6) NOT NULL default '0',
    `component_id` smallint(6) NOT NULL default '0',
    `deadline` datetime default NULL,
    PRIMARY KEY (`bug_id`),
    UNIQUE KEY `bugs_alias_idx` (`alias`),
    KEY `bugs_priority_idx` (`priority`),
    KEY `bugs_reporter_idx` (`reporter`),
    KEY `bugs_product_id_idx` (`product_id`),
    KEY `bugs_creation_ts_idx` (`creation_ts`),
    KEY `bugs_assigned_to_idx` (`assigned_to`),
    KEY `bugs_qa_contact_idx` (`qa_contact`),
    KEY `bugs_votes_idx` (`votes`),
    KEY `bugs_bug_severity_idx` (`bug_severity`),
    KEY `bugs_bug_status_idx` (`bug_status`),
    KEY `bugs_delta_ts_idx` (`delta_ts`),
    KEY `bugs_version_idx` (`version`),
    KEY `bugs_component_id_idx` (`component_id`),
    KEY `bugs_resolution_idx` (`resolution`),
    KEY `bugs_target_milestone_idx` (`target_milestone`),
    KEY `bugs_op_sys_idx` (`op_sys`)
    ) ENGINE=MyISAM AUTO_INCREMENT=10111 DEFAULT CHARSET=latin1 |
    +-------+-----------------------------------------------------

    --------------------------------------------------------------------------------

    Obviously the database is encoded in latin1 (which equivalent is ISO-8859-1, see
    http://wincent.com/knowledge-base/Bu..._upgrade_notes aprox. at
    the last quarter of the page). As posted before, also MySQL-Administrator says
    this when selecting table bugs or any other table. So the procedure under 1.)
    should be the right.

    I am a little bit helpless at the moment. Please tell me, what else I can do and
    why the above steps don't result in success.

    Thank you in advance,

    kind regards,

    powermax123


    Marc Schumann schrieb:
    > Max,
    >
    > 2007/7/5, powermax_123@gmx.de :
    >> After running recode.pl I turned the UTF-8-switch to "on" in Bugzilla
    >> and run
    >> checksetup.pl again, which really re-encoded the database. After that,
    >> MySQL-Administrator says that all Bugzilla-tables are UTF-8.

    >
    > maybe, in your situation, there is no need to run recode.pl.
    > (Especially not with an incorrectly set command line parameter.)
    >
    > It seems to me that what happened is this (please keep in mind that I
    > really don't know what recode.pl does, nor how it does it): you had a
    > database which was set up consistently: the database thought it was
    > meant to handle latin1, and the data was indeed latin1. Now your run
    > of |recode.pl --charset=utf8| came along. The --charset=utf8 parameter
    > made it interpret your database contents as utf8, which it converted
    > to your databases's encoding (latin1). You ended up with
    > double-encoded (or half-encoded?) contents. Lastly, after switching
    > Bugzilla's utf8 parameter on, the checksetup.pl run went ahead and
    > converted the database from latin1 to UTF-8. Working on wrongly
    > encoded contents, the result was borked.
    >
    > Try what you did again, but skip the recode.pl run. Or, run |recode.pl
    > --charset=latin1|, which, as you've seen, doesn't do much -- it takes
    > your latin1 contents and converts them to latin1.
    >
    > I may be wrong in all of the above.
    >
    > Regards
    > Marc


  12. Re: Bugzilla 3.0 - Encoding-Error: "…"

    On Sun, 08 Jul 2007 13:53:34 +0200 "powermax_123@gmx.de"
    wrote:
    > perl contrib/recode.pl --charset=iso-8859-1 --dry-run


    Is that actually the charset your data is in?

    > Obviously the database is encoded in latin1


    No, not true, necessarily. The *bytes* are *interpreted by
    MySQL* as latin1. But the data that's in your database is in whatever
    encoding your web browser used to input it.

    If your web browser *did* use latin1, then you should choose
    cp1252 (not iso-8859-1), which is what Internet Explorer uses most
    commonly.

    -Max
    --
    http://www.everythingsolved.com/
    Competent, Friendly Bugzilla Services. And Everything Else, too.

  13. Re: Bugzilla 3.0 - Encoding-Error: "…"

    Max Kanat-Alexander schrieb:
    >> perl contrib/recode.pl --charset=iso-8859-1 --dry-run

    > Is that actually the charset your data is in?

    As mentioned, iso-8859-1 is the equivalent to latin1 in perl, citing
    http://wincent.com/knowledge-base/Bu..._upgrade_notes aprox. at
    the last quarter of the page. And the database says latin1 is the charset.

    > If your web browser *did* use latin1, then you should choose
    > cp1252 (not iso-8859-1), which is what Internet Explorer uses most
    > commonly.

    Well, I have tested it in Firefox 2.0.0.4 and IE 7.0, but I will try recode.pl
    with "cp1252", which actually was on my ToDo-list, too, but had been forgotten.

    Any other ideas?

    Thank you in advance,

    kind regards,

    powermax123

  14. Re: Bugzilla 3.0 - Encoding-Error: "…"

    powermax_123@gmx.de schrieb:
    > Well, I have tested it in Firefox 2.0.0.4 and IE 7.0, but I will try recode.pl
    > with "cp1252", which actually was on my ToDo-list, too, but had been forgotten.


    Hello,

    I have tested it with recode.pl with "cp1252" and run checksetup.pl again. After
    creating a new bug called "Test der Umlaute öäü" (with the English GUI, not via
    Germzilla!) I received an E-Mail which has got the following subject: "[Bug
    10111] New: Test der Umlaute ö�". I am using Thunderbird 2.0.0.4. On "Ansicht"
    -> "Zeichencodierung" UTF-8 is preselected for this mail, the body is displayed
    correctly, but not the subject.

    Where is the fault, now?

    Thank you in advance,

    kind regards,

    powermax123


  15. Re: Bugzilla 3.0 - Encoding-Error: "…"

    He, Max or Marc, please help me, because this problem appears on a live system
    with about 400 users who are pushing for a solution.

    Thank you in advance,

    kind regards,

    powermax123


    powermax_123@gmx.de schrieb:
    > powermax_123@gmx.de schrieb:
    >> Well, I have tested it in Firefox 2.0.0.4 and IE 7.0, but I will try recode.pl
    >> with "cp1252", which actually was on my ToDo-list, too, but had been forgotten.

    >
    > Hello,
    >
    > I have tested it with recode.pl with "cp1252" and run checksetup.pl again. After
    > creating a new bug called "Test der Umlaute öäü" (with the English GUI, not via
    > Germzilla!) I received an E-Mail which has got the following subject: "[Bug
    > 10111] New: Test der Umlaute ö�". I am using Thunderbird 2.0.0.4. On "Ansicht"
    > -> "Zeichencodierung" UTF-8 is preselected for this mail, the body is displayed
    > correctly, but not the subject.
    >
    > Where is the fault, now?
    >
    > Thank you in advance,
    >
    > kind regards,
    >
    > powermax123
    >


  16. Re: Bugzilla 3.0 - Encoding-Error: "…"

    Max,

    2007/7/13, powermax_123@gmx.de :
    > He, Max or Marc, please help me, because this problem appears on a live system
    > with about 400 users who are pushing for a solution.


    as said, you've come accross a real bug
    (https://bugzilla.mozilla.org/show_bug.cgi?id=387860), and there's
    currently no fix. Mails where the multi-byte character is at a
    non-critical position will be transferred correctly (try " Test der
    Umlaute" to confirm).

    Regards
    Marc

  17. Re: Bugzilla 3.0 - Encoding-Error: "…"

    Marc,

    > as said, you've come accross a real bug
    > (https://bugzilla.mozilla.org/show_bug.cgi?id=387860), and there's
    > currently no fix. Mails where the multi-byte character is at a
    > non-critical position will be transferred correctly (try " Test der
    > Umlaute" to confirm).


    is it possible to suppress wrapping to subject-line or is there any other
    workaround?

    Thank you in advance,

    kind regards,

    powermax123

  18. Re: Bugzilla 3.0 - Encoding-Error: "…"

    Max,

    2007/7/25, powermax_123@gmx.de :
    > is it possible to suppress wrapping to subject-line or is there any other
    > workaround?


    I'm not aware of any. If you find one, please consider mentioning it
    in a comment on the bug.

    Regards
    Marc

  19. Re: Bugzilla 3.0 - Encoding-Error: "…"

    On Wed, 25 Jul 2007 14:22:01 +0200 "powermax_123@gmx.de"
    wrote:
    > is it possible to suppress wrapping to subject-line or is there any
    > other workaround?


    You may want to try upgrading to the *very* latest:

    * Email::MIME
    * Email::Simple
    * Email::MIME::Modifier
    * Email::Send

    And any other Email:: modules you have installed. There have
    been some line-break fixes in the very latest version.

    -Max
    --
    http://www.everythingsolved.com/
    Competent, Friendly Bugzilla Services. And Everything Else, too.

  20. Re: Bugzilla 3.0 - Encoding-Error: "…"

    Max,

    Max Kanat-Alexander schrieb:
    > You may want to try upgrading to the *very* latest:
    >
    > * Email::MIME
    > * Email::Simple
    > * Email::MIME::Modifier
    > * Email::Send
    >
    > And any other Email:: modules you have installed. There have
    > been some line-break fixes in the very latest version.


    do you think this is a perl-problem? Because Marc opened a Bug
    (https://bugzilla.mozilla.org/show_bug.cgi?id=387860).

    Kind regards,

    powermax123

+ Reply to Thread
Page 1 of 2 1 2 LastLast