When I change the encoding in my browser(s), the controls in the cart change accordingly when I have extended chars.
However, it is not consistent and looks very amateurish. See the attached comparison image.
How do I fix this in Magento 1.4.0.1? Or, is it a browser issue, and if so, how do I fix it?
How did you create your MySQL server? When you didn't set correct collation while creating a database, you can always face of troubles. Try following :
mysql > CREATE DATABASE sample DEFAULT CHARACTER SET UTF8 COLLATE UTF8_UNICODE_CI;
UT8_UNICODE_CI has many character sets.
Related
I'm trying to create a report that can switch between English and (Canadian) French number formatting (1,234.56 vs 1 234,56) but am having some troubles.
Before I get into what I have tried I'd like to say that in the past we have always converted the French number to a character, and than made the appropriate string modifications there, but this obviously isn't the best solution and I'm trying to find something better going forward.
The first thing I tried doing was adding the following line to the BEFORE REPORT trigger in the Oracle Report itself:
srw.do_sql ('alter session set nls_numeric_characters = '', ''');
I have my number fields set up with the format mask "(NNNGNNNGNN0D00)" so I would assume the G's and D would use the session's NLS_NUMERIC_CHARACTERS setting but they don't seem to.
To see if the setting was actually changing I created the following query in the report and displayed it's output:
select value from nls_session_parameters
where parameter = 'NLS_NUMERIC_CHARACTERS';
Sure enough the output changed from '.,' to ', ' using my alter session command.
After researching some more online I read that the change really needs to be made in the Oracle Report Server configuration as per this documentation - http://docs.oracle.com/cd/B14099_19/bi.1012/b14048/pbr_conf.htm#i1013352
I contacted the team responsible for our Oracle Application Server and had them try inserting the configurations we need to set up English and French number formatting and they added in the following:
<environment id="EN">
<envVariable name="NLS_LANG" value="AMERICAN_AMERICA.WE8ISO8859P1"/>
</environment>
<environment id="FR">
<envVariable name="NLS_LANG" value="FRENCH_CANADA.WE8ISO8859P1"/>
<envVabiable name="NLS_NUMERIC_CHARACTERS" value="', '"/>
</environment>
The report server was restarted and I entered in the URL to request the report, along with the ENVID=FR parameter, but still no luck. The report runs but the number formatting is still using the ,'s and .'s for grouping and decimal separation.
Does anyone know what we're missing or what else we could try?
I had the same issue and did to_char() where that NLS format needs to apply.
Today when I opened my website I saw question marks instead of texts. Question Marks are showing in japanese and tajik languages. The strange is that inside database it is also ?(Marks).
Does anyone know what is the problem? I have Joomla 1.5 and JoomFish for translating website language. Question marks are shown on all japanese characters. In Tajik language only in some characters are being shown ? marks. My website is navrasta.com
I have had the exact same problem with a JoomFish installation on Joomla 1.5.
From time to time some of the articles would contain just question marks ("?")
Those articles would be lost and I would have to recover them from backups.
What solved the problem for me was to change the database to have my tables use the charset "uft8" and the collation of "uft8_general_ci". Previously I had "latin1_general_ci"
Please backup your database before you attempt to do this.
You should change the charset and collation for at least these tables:
"jos_content" - your articles are stored here in the default language
"jos_jf_content" - your translation are stored here.
(of course you need to replace 'jos_' with your actual table prefix)
Good luck and always do backups before altering the database!
I have an NCLOB field in the database, which I use to save data created using the fck editor.
Certain Turkish characters are displayed as numerical codes after doing an Oracle select from this NCLOB field . For example: the Ç character becomes Ç.
How can I solve this without having to use text replacement?
Who will use the data that is retrieved from the database after the select? If it will be displayed using the FCK editor, there should be no problem.
Otherwise, you need to use a different encoding (I don't know about FCK editor so I don't know if this is possible).
Or, you need to use a different editor (other than FCK) that will read/write in the proper encoding.
Therefore, decide who will be using the data; that is, what software will they be using to display the data coming from the NCLOB field (for example, Microsoft Word, Notepad, or some other application).
Using that application, create a file that contains Turkish characters.
Write that file into a NCLOB field.
Retrieve the file back and try to display it using the same application.
Make sure the characters are the same and that Oracle has not transformed the Turkish characters.
If all works well, use that application to store data into NCLOB fields.
I have one field when importing that can contain large data, it seems that CSV has unofficial limitation of about 65000 (likely 65535*) character. as both libreoffice calc and magento truncating the data for that particular field. I have investigated well and I'm certain it is not because of a special character or quotes. the data pretty straight forward, the lines are similar in format to each other.
Question: How to increase that size? or at least where I should look to find it?
Note: I counted in libreoffice writer and it was about 65040. but probably with carriage return characters it could reach 65535
I change:
1) in table catalog_category_entity_text
type of field "value" from "text" to "longtext"
2) in file app/code/core/Mage/ImportExport/Model/Import/Entity/Abstract.php
const DB_MAX_TEXT_LENGTH = 65536;
to
const DB_MAX_TEXT_LENGTH = 16777215;
and all OK
You are right, there is a limitation in Magento, because it sets texts fields as TEXT in MySQL database and, according to MySQL docs, this kind of field supports a maximum of 65535 chars.
http://dev.mysql.com/doc/refman/5.0/es/storage-requirements.html
So you could change the column type in your Magento database to use MEDIUMTEXT. I guess the correct place is in the catalog_product_entity_text table, where you should modify the 'value' field type to match your needs. But please, keep in mind this is dangerous. Make a full backup before trying. And you may even need to play with core files... not recommended!
I'm having the same issue with 8 products from a list of more than 400, and I think I'm not going to mess with Magento core and database, we can reduce the description strings for those few products.
The CSV could care less. Due to Microsoft Access allowing Memo fields which can contain quite a bit of data, I've exported 2-3k descriptions in CSV format to be imported into Magento quite successfully.
Your limitation is either because you are using a spreadsheet that has a cell limitation or export limitation on cells or because the field you are trying to import into has a maximum character limitation set in its table for that field.
You can determine the latter by using phpMyAdmin to see what the maximum character setting is for that field.
I'm having trouble with the number formatting in Apex 3.2.1. NLS_TERRITORY is set to GERMANY, NLS_LANGUAGE to GERMAN. However, the default number formatting is wrong and I would like to fix/change it. I'm wondering why there is an application date format setting but no application number format setting. That would have been really helpful right now. So my question is: how can I set a new number format which will be applied everywhere in my application? Is it possible? If not, what would be the least painful way to to apply the new format mask. I'm mainly concerned with interactive reports. Additionally, if it were possible to change the default format mask for the territory in some configuration file, that would also be an option. Thanks for your input in advance.
Edit:
My problem with the default format is that numbers like 0.34 are being displayed as ",34", but the correct output would be "0,34".
Okay, purely the display then. I don't think there is an easy way to do this for all your fields, but specifying a format mask on those fields, by using for example FM999G999G990D000.
That would be annoying for a lot of fields across the application though, i agree. It is even more annoying when only by specifying a format mask, items are recognised as being number fields. Maybe making a plugin, which is identical to a number field, but with a default format mask may do the trick.
Or query the apex views to find items, then update them (though you will need access to the 'internal' tables of apex, the wwv_* things).
select application_name, page_id, page_name, item_name, display_as, display_as_code, format_mask from apex_application_page_items where page_id = 6
Which you could then transform into an update...
I've nothing else to offer, so far i've always specified the format mask during development...