Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

Error in displaying french characters é, è, à, m²


Guest

Recommended Posts

Found display error when using french language.

 

First i created a standard oscommerce v2.3 installation.

Then i added the french language.

 

When using french product description in the admin product panel all works fine.

However when typing into the php languages files this characters 'é, è, à, m²) the result in the display is a '?'.

How to solve this problem.

 

On Oscommerce v2.2 i used the same files and all was fine.

 

Thanks, Mon

Link to comment
Share on other sites

You might need to use their HTML equivalents. http://www.w3schools.com/tags/ref_entities.asp

 

The french text is in a define statement, nothing to do with HTML.

 

define('TEXT_INFORMATION', '

Ou préférez vous créer un compte. Notre magasin est grandi jusque\'a 400m² ');

 

I don't see why it is not working in OSCommerce V2.3. The same text works fine in OSCommerce V2.2.

 

However thanks for the link.

 

Mon

Link to comment
Share on other sites

By default, osC 2.3 is UTF-8 encoding, while osC 2.2 is Latin-1 (ISO-8859-1). It sounds like one or more of:

  1. Your osC-supplied language files are still Latin-1. Did you get a fresh set of UTF-8 encoded French files?
  2. Your database was not properly converted from Latin-1 encoding to UTF-8 encoding when you upgraded to 2.3.
  3. Your custom French text in various language files (defines) was edited in Latin-1 or Windows-1252 on a PC, and need to be either edited in UTF-8, or run through a converter to change them to UTF-8. If you can display the .php files with the defines OK on a PC (that is not running in UTF-8 mode), it means the text is still Latin-1. You will need a UTF-8 capable editor, or a converter utility. Be sure to save files without Byte Order Mark (BOM).

Link to comment
Share on other sites

The html, of this forum page, has the line

 

<meta charset="UTF-8" />

 

and so the letters are correct. In the case of your pages that are not displaying correctly, you may find something like

 

<meta charset="ISO-8859-1" />

 

and if so then you need to find out where the ISO text is coming from.

 

Incidentally I think that your "jusque\'a" could equally well be "jusqu\'a". But you know best.

Link to comment
Share on other sites

By default, osC 2.3 is UTF-8 encoding, while osC 2.2 is Latin-1 (ISO-8859-1). It sounds like one or more of:

  1. Your osC-supplied language files are still Latin-1. Did you get a fresh set of UTF-8 encoded French files?
  2. Your database was not properly converted from Latin-1 encoding to UTF-8 encoding when you upgraded to 2.3.
  3. Your custom French text in various language files (defines) was edited in Latin-1 or Windows-1252 on a PC, and need to be either edited in UTF-8, or run through a converter to change them to UTF-8. If you can display the .php files with the defines OK on a PC (that is not running in UTF-8 mode), it means the text is still Latin-1. You will need a UTF-8 capable editor, or a converter utility. Be sure to save files without Byte Order Mark (BOM).

 

I might be wrong but a define text statement in a php file comes not from a table. I think that's only a variable. I'm going to look at your nbr 3 solution.

All my database an tables are in latin1 but every special character coming from a table is correctly displayed. Only the special characters from the define statements are wrong.

 

Thanks

Mon

Link to comment
Share on other sites

The html, of this forum page, has the line

 

<meta charset="UTF-8" />

 

and so the letters are correct. In the case of your pages that are not displaying correctly, you may find something like

 

<meta charset="ISO-8859-1" />

 

and if so then you need to find out where the ISO text is coming from.

 

Incidentally I think that your "jusque\'a" could equally well be "jusqu\'a". But you know best.

 

Sorry, jusque\'a was a typing error.

 

Thanks

Mon

Link to comment
Share on other sites

Did you say this was osC 2.3? By default that is UTF-8 page display, along with a UTF-8 database and language file set. Was this a conversion from osC 2.2 or a fresh install of osC 2.3? What are your pages displaying in? Your browser will tell you with View > Character Encoding or something similar. Did you deliberately change osC 2.3 to Latin-1? That can be done, but you'll have to change all the language files (which also define the page encoding). Any custom definitions in language files need to be the proper encoding.

 

If you're seeing ?-in-black-diamond in your browser, it means it is displaying in UTF-8, but (most likely) the text being provided is still Latin-1 (single byte accented characters). Confirm what the pages are displaying in, what the database is, what set of language files you use is (both the characters in the text and the setlocale()-type calls in french.php), and how you edited any language files (Latin-1 or UTF-8). If you're seeing regular ?, it sounds like everything is in Latin-1, but the database is unhappy about some of the characters.

 

A UTF-8 page displaying single byte accented characters (Latin-1 or Windows-1252 most likely) will usually show a ?-in-black-diamond because the Latin-1 encoding is an invalid UTF-8 multibyte character code. A Latin-1 page displaying UTF-8 multibyte characters (anything not ASCII, including all accented characters) will show a sequence of two or more oddball accented characters, such as \^A\`e. Please be specific about what you're seeing.

Link to comment
Share on other sites

Did you say this was osC 2.3? By default that is UTF-8 page display, along with a UTF-8 database and language file set. Was this a conversion from osC 2.2 or a fresh install of osC 2.3? What are your pages displaying in? Your browser will tell you with View > Character Encoding or something similar. Did you deliberately change osC 2.3 to Latin-1? That can be done, but you'll have to change all the language files (which also define the page encoding). Any custom definitions in language files need to be the proper encoding.

 

If you're seeing ?-in-black-diamond in your browser, it means it is displaying in UTF-8, but (most likely) the text being provided is still Latin-1 (single byte accented characters). Confirm what the pages are displaying in, what the database is, what set of language files you use is (both the characters in the text and the setlocale()-type calls in french.php), and how you edited any language files (Latin-1 or UTF-8). If you're seeing regular ?, it sounds like everything is in Latin-1, but the database is unhappy about some of the characters.

 

A UTF-8 page displaying single byte accented characters (Latin-1 or Windows-1252 most likely) will usually show a ?-in-black-diamond because the Latin-1 encoding is an invalid UTF-8 multibyte character code. A Latin-1 page displaying UTF-8 multibyte characters (anything not ASCII, including all accented characters) will show a sequence of two or more oddball accented characters, such as \^A\`e. Please be specific about what you're seeing.

 

 

For testing on my localhost i did do a fresh install from osc 2.3. Downloaded from the os site.

Created a new database with pfpMyadmin and did not enter any collation.

The database and tables are showing collation Latin1.

Testing the products description entered in the database with special characters are ok.

Changing the define text in \includes\language\english\contactus.php by entering a few special characcters shows the black diamond.

 

The second test, i started a new installation from osc 2.3.

Now created a new database with collation utf8.

Everything now showing collation utf8.

Products description from database all ok also special characters.

 

Text from the contact_us.php file still showing the black diamond.

 

I feel that you are on the right track with the UTF-8 but at this very moment i have not solved the problem.

Your last explanation is something i'm going to try out.

In my define statement i typed : the character é, maybe i should type something like \^A\`e.

 

Thanks

Mon

Link to comment
Share on other sites

Did you say this was osC 2.3? By default that is UTF-8 page display, along with a UTF-8 database and language file set. Was this a conversion from osC 2.2 or a fresh install of osC 2.3? What are your pages displaying in? Your browser will tell you with View > Character Encoding or something similar. Did you deliberately change osC 2.3 to Latin-1? That can be done, but you'll have to change all the language files (which also define the page encoding). Any custom definitions in language files need to be the proper encoding.

 

If you're seeing ?-in-black-diamond in your browser, it means it is displaying in UTF-8, but (most likely) the text being provided is still Latin-1 (single byte accented characters). Confirm what the pages are displaying in, what the database is, what set of language files you use is (both the characters in the text and the setlocale()-type calls in french.php), and how you edited any language files (Latin-1 or UTF-8). If you're seeing regular ?, it sounds like everything is in Latin-1, but the database is unhappy about some of the characters.

 

A UTF-8 page displaying single byte accented characters (Latin-1 or Windows-1252 most likely) will usually show a ?-in-black-diamond because the Latin-1 encoding is an invalid UTF-8 multibyte character code. A Latin-1 page displaying UTF-8 multibyte characters (anything not ASCII, including all accented characters) will show a sequence of two or more oddball accented characters, such as \^A\`e. Please be specific about what you're seeing.

 

 

Problem solved. you put me on the right track.

 

When typing text in the define statement is must type \^A\`e instead of the special character.

I found those in the french language file.

 

This topic has solved.

 

Thank you very much for the tip.

Mon

Link to comment
Share on other sites

Really? TeX-style escapes work? Maybe that's something in your browser or editor configuration? I just used them because I didn't feel like loading up a glass keyboard to input accented characters. Well, as long as it works, and you got correctly encoded accented letters, that's what counts.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...