Defect #4865
closed
Trim project name above 30 chars
Added by Александр Рябиков almost 15 years ago. Updated over 14 years ago.
0%
Description
Project name trimmed above 30 chars.
For example in Rusiian language show in attache.
Files
| trim_name.JPG (5.29 KB) trim_name.JPG | Александр Рябиков, 2010-02-17 17:42 | ||
| file1.png (3.41 KB) file1.png | database and redmine views after data save from REDMINE | Oleg Agafonov, 2010-06-12 11:05 | |
| file2.png (3.21 KB) file2.png | database and redmine views after data save from DATABASE | Oleg Agafonov, 2010-06-12 11:05 |
Updated by Evgeny Ushkalov almost 15 years ago
Not only Project name.
Document categories, trackers and all other editable fields.
I think that is Unicode string problem because all entered strings trimmed about half of maximum length.
Updated by Jean-Philippe Lang almost 15 years ago
Please read SubmittingBugs and make sure to mention the database you use.
Updated by Oleg Agafonov over 14 years ago
Then problem is database default character set (non unicode).
Example: Bitnami virtual machine with MySQL and Redmine ( http://bitnami.org/stack/redmine ). It's using latin1 and can't normal work with multi byte characters (all string's fields trim by 2x).
Updated by Holger Just over 14 years ago
Well, this is an issue of the Bitnami stack then.
Quoted from RedmineInstall:
create database redmine character set utf8;That way, the MySQL database should properly handle multi-byte characters.
Updated by Oleg Agafonov over 14 years ago
Holger Just wrote:
Well, this is an issue of the Bitnami stack then.
Quoted from RedmineInstall:
create database redmine character set utf8;
That way, the MySQL database should properly handle multi-byte characters.
After all that's not working :( Redmine always write data to one-byte characters in database (with utf8 too!).
Example with UTF8 database:
File 1: database and redmine views after data save from REDMINE;
File 2: database and redmine views after data save from DATABASE.
Updated by Holger Just over 14 years ago
Make sure to include encoding: utf8 in your database.yml (see source:trunk/config/database.yml.example for an example) and setting the default-encoding of all tables to UTF-8. You might also need to update the encoding of all existing data in the tables to real UTF-8 (but I don't know enough MySQL for that).
Using this, Redmine (and any other Rails app) should always write proper UTF-8 charcters to the database.
Besides, I think, you are just seeing a mismatch in encodings in your PHPMyAdmin, Redmine and MySQL. Everywhere else in the world, this works properly, so this is most probably not an issue of Redmine.
Updated by Felix Schäfer over 14 years ago
How far are we on this? Does the problem still exist after having applied the right configuration?
Updated by Oleg Agafonov over 14 years ago
Felix Schäfer wrote:
How far are we on this? Does the problem still exist after having applied the right configuration?
Yes, it's live. I'v checked redmine and database settings, changed encoding, convert all table's data to UTF8. It isn't help. That's attached screenshots show not only "visual" bug, but "max project's name bug" from first post too. Maybe problem in mongrel, suse os or etc. I don't know that's systems very well for check.
Updated by Felix Schäfer over 14 years ago
- Status changed from New to Closed
- Resolution set to Cant reproduce
I've tested this locally on my development redmine with SQLite and on my production server with MySQL and was able to create a project with the name "Александр Рябиков Александр Ря" in each. Make sure everything in the stack uses UTF-8: The database (and I don't think changing from whatever collation to UTF-8 will change the data already in the DB, so you will need to change that yourself after the collation change), phpMyAdmin (you have to chose an UTF-8 locale upon connection), and redmine's database connection settings.
If you have troubles getting the configuration right, please visit the forums or maybe even the forums of your linux distribution (or bitnami if using the bitnami stack), but this is not a bug I could reproduce on current trunk.