Defect #11116
closed
CSV export encoding problem when issues and interface languages are not equal
Added by Dmitry Babenko almost 12 years ago. Updated almost 9 years ago.
0%
Description
general_csv_encoding should be set to UTF-8 in locales (config/locales/*.yml) in order to avoid encoding problems when you try to export issues in one language when interface is set to another.
Related issues
Updated by
Updated by Dmitry Babenko almost 12 years ago
Jean-Philippe Lang wrote:
Could you explain why?
Sure. Here is our case. We use English interface and manage almost all projects and their issues in English. But also we have some local projects and we need to manage them in Russian. So, when we try to export issues written in Russian when we use English interface we get only "?" instead of Russian chars in CSV file.
But when we use Russian interface we have no problems with export to CSV because general_csv_encoding is set to UTF-8, and won't have them with issues in any language.
Also, I believe that UTF-8 is more universal encoding for multi-lingual software :)
Updated by Toshi MARUYAMA over 11 years ago
- Category changed from Issues to I18n
Updated by Timur Irmatov about 11 years ago
I support Dmitry, we similarly using Redmine with English interface, but issues are in Russian. CSV export converts all russian characters to question marks with default setting. Changing general_csv_encoding to UTF-8 in config/locales/*.yml fixes this issue. Last comment about UTF-8 being a standard for today is pretty valid too.
Updated by
Updated by Johan Hornof almost 11 years ago
agree with Dmitry and Filou, I'd also appreciate changing csv export to utf8
Updated by alex koval over 10 years ago
In today world the standard de-facto is UTF8 and not national charsets anymore.
My Redmine installation for example contains projects for different customers, some in German, some in Russian, most in English. This simply means, for the sake of simplicity I use English interface and it take quite time for me to get to this issue. All non-English letters are '?' by default... Not usable for truly international Redmine install.
The shortcut here would be to provide language setting: English (UTF-8) for those people which require UTF-8 support.
Updated by @ go2null about 9 years ago
+1 for UTF-8 in en.yml, or have it as a UI option.
Updated by Toshi MARUYAMA about 9 years ago
- Related to Feature #7037: CSV export encoding and excel. UTF-8 and BOM added
Updated by Toshi MARUYAMA about 9 years ago
- Has duplicate Defect #19523: problem in exporting Arabic text to csv added
Updated by Pavel Liavonau almost 9 years ago
@ go2null wrote:
+1 for
UTF-8inen.yml, or have it as a UI option.
+1
When I am working under english locale of redmine export to csv doesn't work correctly. Ciryllic symbols looks like questions. When I switch language of redmine to Russian - export works good.
So, why the parameter general_csv_encoding in localization files is not UTF-8 by default? Especially I mean the file en.yml.
thanks.
Updated by Toshi MARUYAMA almost 9 years ago
- Status changed from New to Closed
- Resolution set to Wont fix
Pavel Liavonau wrote:
So, why the parameter general_csv_encoding in localization files is not UTF-8 by default? Especially I mean the file en.yml.
Because old MS Excel cannot treat UTF-8 with BOM.
#7037 was fixed in 3.1.0.
You can change general_csv_encoding to UTF-8 if your all MS Excel can treat UTF-8 with BOM.
I close this issue.