Guest Joker Posted October 22, 2005 Share Posted October 22, 2005 If someone want use more than one language, I suggest three things: 1. You must convert after install all tables to UTF8_unicode 2. Save template pages to UTF-8 encoding (now they make in ANSII encoding) 3. In all pages header you must use UTF-8 encoding Brgrds, Joker Quote Link to comment Share on other sites More sharing options...
Guest Joker Posted October 22, 2005 Share Posted October 22, 2005 Idea to brooky, in install good when ask from user, what database encode want user use! Brgrds, Joker Quote Link to comment Share on other sites More sharing options...
Guest Gaijin Posted October 24, 2005 Share Posted October 24, 2005 If someone want use more than one language, I suggest three things: 1. You must convert after install all tables to UTF8_unicode 2. Save template pages to UTF-8 encoding (now they make in ANSII encoding) 3. In all pages header you must use UTF-8 encoding Brgrds, Joker Hmm, the main reason I have gone for this cart script is that encoding is called directly from the language files so that I can comfortably encode the data to be displayed in shift_jis for my Japanese text, Win 1250 for my Czech text and leave it as it likes for the English text In contrast to my previous experience the database content does not collide with the script code, which oftenly occurred when the database entries were in Japanese (the two-to-one-byte translation often spitted [ and the code was hopelessly waiting to close it by ]) So I gladly leave the language encoding on brooky - with a hope he will standardize the language options for categories as he has already done it for products... Quote Link to comment Share on other sites More sharing options...
Guest Joker Posted October 27, 2005 Share Posted October 27, 2005 Same time you must change your database encoding to UTF-8! Install doesn't do it and put database to default code. It's important when you use Russian, Japanese, or some other exotic language. If you use latin characters, it doesnt't have problem! Example I use Russian characerset and added info to database, the result was like this -> ??????? ?????? ????? ???? In my database was default -> latin1_swedish_ci and I changed it to -> utf8_unicode_ce. Now everything work perfeclty! Brgrds, Joker Quote Link to comment Share on other sites More sharing options...
Guest estelle Posted October 30, 2005 Share Posted October 30, 2005 So I gladly leave the language encoding on brooky - with a hope he will standardize the language options for categories as he has already done it for products... With 3.0.4 onwards you can now have your category names in different languages. Quote Link to comment Share on other sites More sharing options...
convict Posted October 30, 2005 Share Posted October 30, 2005 Joker is absolutely right. Applications that support Unicode are often capable of displaying multiple languages and scripts within the same document. In a multilingual office or business setting, Unicode's importance as a universal character set cannot be overlooked. Unicode is the only practical character set option for applications that support multilingual documents. UTF-8 is a multibyte encoding in which each character can be encoded in as little as one byte and as many as four bytes. Most Western European languages require less than two bytes per character. For example, characters from Latin-based scripts require only 1.1 bytes on average. Greek, Arabic, Hebrew, and Russian require an average of 1.7 bytes. Finally, Japanese, Korean, and Chinese typically require three bytes per character. CubeCart was born in the UK - UTF-8 is useless. @Gaijin you are right that code page for language files is stored somewhere, but one side is translated file and the other database contents. [skus is v CC nacpat rukse znaky do databazy s CP1250] :D Quote Link to comment Share on other sites More sharing options...
Guest Gaijin Posted November 10, 2005 Share Posted November 10, 2005 With 3.0.4 onwards you can now have your category names in different languages. Oh yeah, I was eagerly waiting for that feature as categories stay a little bit higher above product items. Anyway, Joker's recommendations seems to be a bit tricky - my first attempt to "internationalize" CC was UTF-8 encoding, which actually corrupted the source code - the tables went out somewhere to the fourth dimension as they became completely corrupted. (Anyone else's experience?). After that I modestly came back to the original ISO encoding :unsure: Quote Link to comment Share on other sites More sharing options...
Guest Gaijin Posted November 10, 2005 Share Posted November 10, 2005 Joker is absolutely right. Applications that support Unicode are often capable of displaying multiple languages and scripts within the same document. In a multilingual office or business setting, Unicode's importance as a universal character set cannot be overlooked. Unicode is the only practical character set option for applications that support multilingual documents. UTF-8 is a multibyte encoding in which each character can be encoded in as little as one byte and as many as four bytes. Most Western European languages require less than two bytes per character. For example, characters from Latin-based scripts require only 1.1 bytes on average. Greek, Arabic, Hebrew, and Russian require an average of 1.7 bytes. Finally, Japanese, Korean, and Chinese typically require three bytes per character. CubeCart was born in the UK - UTF-8 is useless. @Gaijin you are right that code page for language files is stored somewhere, but one side is translated file and the other database contents. [skus is v CC nacpat rukse znaky do databazy s CP1250] As I have told, my experience with UTF-8 encoding for CC has been a disaster - only traditional iso encoding has gone well with my Japanese-Czech hybride. [Myslim si, ze si z nas Joker dela prdel. Zkusil sis jen treba zadat do konfigurace jazyku kodovani UTF? Mne to rozhodilo tabulku shopu po cele obrazovce - evidentne se UTF nastaveni tluce s PHP kodem nebo prinejmensim s CSS. Jinak ruske znaky nemusim, staci mi japonstina... ] Quote Link to comment Share on other sites More sharing options...
Guest Gaijin Posted November 12, 2005 Share Posted November 12, 2005 Apology to JOKER for my suspection he was joking overly... I tried again to switch the encoding from shift_jis to UTF-8 and have experienced no problem at all with the page structure this time. Yes, unifying all languages under the unicode umbrella would be the best solution. [izvini drug] Quote Link to comment Share on other sites More sharing options...
convict Posted November 12, 2005 Share Posted November 12, 2005 If you think, think it again [V pohode] Quote Link to comment Share on other sites More sharing options...
Guest Gaijin Posted November 12, 2005 Share Posted November 12, 2005 If you think, think it again [V pohode] The upper part of the image is gotten from the shop using shift_jis encoding and the lower one from that UTF encoded, version 3.0.2, now I don´t have any problem like that. Disregard the written content, just have a look at the shape of tables. So your reply shoud rather read "If you use UTF, wait for the right version of the code" The problem is that some Japanese characters translated into one-byte "language" contains special characters, which could interact with the source code and corrupt it, if the text imput is not strictly separated from it. This phenomenon occurs, when Japanese pages are hosted on standard-ASCII-code based servers. Quote Link to comment Share on other sites More sharing options...
Guest vrakas Posted February 20, 2006 Share Posted February 20, 2006 This is an old thread but never the less an important one. Usefull if you could also add to this the sql query's you used to get the wished results :D Quote Link to comment Share on other sites More sharing options...
Guest Gaijin Posted February 21, 2006 Share Posted February 21, 2006 This is an old thread but never the less an important one. Usefull if you could also add to this the sql query's you used to get the wished results Well, I'm quite surprised you've got so much time to analyse that old postings You made me to give you an hour or so to reinstall the old stuff - 3.0.2. and the languages. The stuff I freshly reinstalled is here: http://www.czexplorer.jp/vrakas You can select one of three of them: English - as the standard, Slovakian - as one abundant in diakrtitic marks (like Czech - is that so, Convict?), and Japanese with the shift_jis -> utf-8 encoding change; there was no problem with the former JP encoding. Just select any of them and compare. But before taking me to the court for a sql qery fabrication, please try to access the site using MSIE, since there has been no problem when when watching the site through Firefox, which I installed quite recently. Vast majority of my Japanese customers are, however, the The Holy Microsoftening and Outlooking Exploration Church believers so that I have to follow the Scripture as well Besides, the correct displaying of Japanese dug out from databases hosted on non-Japanese servers is the main reason I am keeping myself stuck with CC. I might tell you long horror stories how the "spred-tea-leaves-like characters looked after passage through the MS ASP machine. Quote Link to comment Share on other sites More sharing options...
Guest vrakas Posted February 21, 2006 Share Posted February 21, 2006 First of all thanks for sparing the time with us and sorry to put you through all this trouble These are the results i got when i tryed the various compinations with IE6.2900 I have the encoding on auto select. Starting from left to right IE auto switched to: Japanese: Unicode-UTF8 English: Western European ISO Slovakian: Central European Windows What i saw is this: Quote Link to comment Share on other sites More sharing options...
Guest Gaijin Posted February 22, 2006 Share Posted February 22, 2006 First of all thanks for sparing the time with us and sorry to put you through all this trouble These are the results i got when i tryed the various compinations with IE6.2900 I have the encoding on auto select. Starting from left to right IE auto switched to: Japanese: Unicode-UTF8 English: Western European ISO Slovakian: Central European Windows What i saw is this: Well, the problem has already been history. As you can see the input text is corrupted - this has not been the core problem, this has come out due to incorrect coding. The problem itself is that originally two-byte Japanese characters are transcribed into one-byte characters including special characters used in scripts. These characters collide with the html script (or better to say with its MSIE interpretation), so that you can see in the lower part of the far left picture you submitted that a part of a table is repeated many times in contrast with the standard ASCII or CE encodings. Since the very begining my shop has been ISO Japanese shift_jis encoded, so I did not anything about the problem - it occurred when I went international and tried to change into utf-8, as I am planning to run a Czech beside Japanese from one database... To not panic the folks who intend to try out CC I have to conclude that: - CC utf encoding for multi-byte languages has always been safe for Fifefox browser - in newer CC versions (starting from 3.0.3) there are no problems with encoding at all :) Quote Link to comment Share on other sites More sharing options...
Guest vrakas Posted February 22, 2006 Share Posted February 22, 2006 Thanks again ;) Quote Link to comment Share on other sites More sharing options...
Guest Gaijin Posted February 23, 2006 Share Posted February 23, 2006 Thanks again You are welcome. As the 3.0.2 story vs. utf-8 is over, the related site (subdirectory) containing the script has already been erased... Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.