Closed Bug 543845 Opened 16 years ago Closed 16 years ago

suggested name for Default User causes error

Categories

(Mozilla Localizations :: sr / Serbian, defect)

x86
Windows XP
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: ivan.icin, Unassigned)

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; sr; rv:1.9.2) Gecko/20100115 Firefox/3.6 (.NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; sr; rv:1.9.2) Gecko/20100115 Firefox/3.6 (.NET CLR 3.5.30729) In create new profile dialog, by default profile name is Default User. This is translated in cyrilics, and it seems that Firefox can't create folder with cyrilics letter in it, and user gets error message if he uses default translation. It is likely that user will think that there is something wrong with the program and not that if he changes words in roman letters that everything will work fine. So please use translation with Roman letters here. This is just work around, fix should enable Firefox to create profile dir with unicode letters and it should be another bug, but I guess something is better than nothing. Reproducible: Always
Why would Mozilla have problems creating Cyrillic files on Windows? Can you give more context, please? (btw, this works on Linux just fine)
OK, I have planned to write down error message, but didn't have time... Why? In Windows you have different APIs when using unicode and non-unicode paths and some people just got used in calling those non-unicode APIs... I found some documenation on how to call some file related API on web and written one C# application it worked fine until someone sent me file with Cyrillic letters. Then I realised that there is the same API, but it is much harder to find info about it on web... people just use those non-unicode APIs more wide...
Then this is no(In reply to comment #2) > OK, I have planned to write down error message, but didn't have time... I don't have access to Windows to reproduce this > Why? In Windows you have different APIs when using unicode and non-unicode > paths and some people just got used in calling those non-unicode APIs... This is not a l10n bug then, you should file a bug for the component at fault.
Component: sr / Serbian → Preferences
Product: Mozilla Localizations → Thunderbird
QA Contact: sr → preferences
Version: unspecified → Trunk
Component: Preferences → General
Product: Thunderbird → Firefox
QA Contact: preferences → general
Target Milestone: --- → Firefox 3.6
I can confirm on Windows XP Professional that some apps(.msi) won't run properly(or won't run at all) if the file path contains cyrilic letters. Also, some of the .exe installers won't run from Пријеми directory(Downloads in English) which is the default directory where files downloaded via Firefox are stored.
Reverting this to localization bug. I have already posted bug 543854 for Core component and it has proper description, and some activities... This bug is for workaround. Personally, I think that it is desirable to use non-unicode transcription if it makes user experience better, until the bug that requires this is fixed. I emailed Axel to see his and official opinion on this, this will happen now and then and probably in other localizations. I see that he subscribed to main bug, so he spotted email, and I guess I'll get some answer later, probably he needs to think some more or consult someone else...
Component: General → sr / Serbian
Product: Firefox → Mozilla Localizations
Target Milestone: Firefox 3.6 → ---
Version: Trunk → unspecified
QA Contact: general → sr
Core bug is fixed. Just to note that I've got reply from Seth whether it is desirable to use ANSI characters as a workaround for Unicode bug, and the answer is in some cases yes (as I suggested here). Please note that I explained him what's the problem on installer bug which is now fixed, as installer text was unreadable. And we should have used Latin text for installer as I suggested then, actually Mozilla required that from all localizations that could be transcribed to ANSI. Here is from the email: // Hi Ivan, I asked a guy who works on our installer code. Here is his response: "In my opinion it should be evaluated on a case by case basis. In the case of the installer before 3.5 it didn't have Unicode support and all translations were in ANSI. The locales that didn't have an ANSI equivalent were in English and all of the locales I looked at that didn't have an ANSI equivalent were in English. If there are issues with Unicode and the installer bugs should be filed upstream against NSIS and a bug should be filed in bugzilla referencing the bug. "In the case of the bug below the bug itself should be fixed since it isn't really a localization bug... it is a bug in the way we handle Unicode when creating paths for profiles on the file system and can technically affect any locale when using a combination of different charsets." I hope this helps. Now that it is on a radar screen, perhaps the bugs will get fixed. //
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.