Project

General

Profile

Actions

Defect #11116

closed

CSV export encoding problem when issues and interface languages are not equal

Added by Dmitry Babenko over 12 years ago. Updated over 9 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
I18n
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Resolution:
Wont fix
Affected version:

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

Related to Redmine - Patch #6287: character corruption in exporting spent timeClosed2010-09-03

Actions
Related to Redmine - Feature #7037: CSV export encoding and excel. UTF-8 and BOMClosedJean-Philippe Lang2010-12-03

Actions
Has duplicate Redmine - Defect #19523: problem in exporting Arabic text to csvClosed

Actions
Actions #1

Updated by Jean-Philippe Lang over 12 years ago

Could you explain why?

Actions #2

Updated by Dmitry Babenko over 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 :)

Actions #3

Updated by Toshi MARUYAMA about 12 years ago

  • Category changed from Issues to I18n
Actions #4

Updated by Timur Irmatov over 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.

Actions #5

Updated by Filou Centrinov over 11 years ago

Related with #6287

Actions #6

Updated by Johan Hornof over 11 years ago

agree with Dmitry and Filou, I'd also appreciate changing csv export to utf8

Actions #7

Updated by alex koval about 11 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.

Actions #8

Updated by @ go2null over 9 years ago

+1 for UTF-8 in en.yml, or have it as a UI option.

Actions #9

Updated by Toshi MARUYAMA over 9 years ago

  • Related to Feature #7037: CSV export encoding and excel. UTF-8 and BOM added
Actions #10

Updated by Toshi MARUYAMA over 9 years ago

Try #7037 patch.

Actions #11

Updated by Toshi MARUYAMA over 9 years ago

  • Has duplicate Defect #19523: problem in exporting Arabic text to csv added
Actions #12

Updated by Pavel Liavonau over 9 years ago

@ go2null wrote:

+1 for UTF-8 in en.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.

Actions #13

Updated by Toshi MARUYAMA over 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.

Actions

Also available in: Atom PDF