Serious Problems with proper language encoding!

[EinfachClicken]

Hi there, everyone.
Our Server has about 10 different applications from around the world installed on it. Most of them are English/American apps. like Greetingcards, Weather Services, Photo Albums, Contact Managment, Group Planner, etc. Our server is located in Germany and the website which uses these apps. displays everything in the german language, to include the Umlaut lettering, Ä, Ü, Ö, and ß which are specific to Germany and used all of the time.

Our Server also had Webmail installed for the past 2 years and the special german characters have always worked for us. Recently we tried out Roundcube, and the special german letters worked there as well. As a matter of fact, due to the current problems with the lettering we just reinstalled roundcube in the past couple of days .... sent and received numerous test mails .... and the special letters worked just fine. No problem whatsoever. We created a test account on the server COs server and everything works there properly also, same apache configuration.

For some reason though, no matter what we do, we can't get the special Umlaut Letters to work in MyRoundcube. We've spoken to the developer of MyRoundcube about this repeatedly but the answers don't make any sense to us or to our technician. Even if MyRoundcube is coded in UTF8, wouldn't that be the same coding that was used on Roundcube initially, and if so, how come "regular" Roundcube doesn't have the lettering problems on our Server? Why would one version of Roundcube work without a problem, and the other one not (as far as character display is concerned)?

We can't figure out why regular Roundcube, all of our "Foreign Applications" *AND* our german Apps/Files display german lettering lettering properly, yet only MyRoundcube won't? This simply does not make sense and our tech swears up and down that their own server config with regular roundcube is identical to the server config that we had with regular roundcube ... and also identical with the MyRoundcube derivative that we're using right now. We need to use MyRoundcube on a professional level for our users and that means that this problem has to be fixed ASAP.

Can someone provide specific - understandable - information as to why this is happening (special characters not being displayed proeprly) and more importantly, can someone provide us with an answer other than to deinstall MyRoundcube or to switch Apache over to UTF8 since that would impact numerous thousands of files in our domains (already tried that).
There must be a viable solution to this problem? Is there some type of converter tool that can be installed perhaps? Any help is sincerely appreciated.

[rosali]

Special letters on MyRoundCube works on my server (apache) and on various other servers without the reported problem.

The only difference is that I have uploaded MyRoundCube by FTP to your server while all other installations were made by remote desktop.

So what happend during the install? I can only guess. I saw that all the special characters were broken on the initial install.

Reaction: I compiled the language files from UTF8 encoding to ISO 8859-1 (ANSI) encoding and loaded up again.

Result: On some sites most things were displayed correct on others - mainly compose section - not :-(

I never experienced that.

Hmmm... so my first thought was an Apache configution issue. You say now, you can exclude that. What could it be else? Strange, but maybe it was the ftp upload, because it is the only difference to all the other installs ?!?

Could you try to download MyRoundCube again from my site? Install it along with your current installation (just copy over the config files after extracting the archive). Would be interesting, if the ftp upload had some impact on the file encoding ...

-Roland

[EinfachClicken]

Could you try to download MyRoundCube again from my site? Install it along with your current installation (just copy over the config files after extracting the archive). Would be interesting, if the ftp upload had some impact on the file encoding ...

I'll definitely give that a try within the next few days, Roland. Narrowed the problem down even further though ....

The special Umlaut Letters are working - somewhat. Today I sent a message internally from within MyRoundcube to another MyRoundcube account, making sure to use Umlaut Letters since we're also still working on this issue. Well, sending internally with special characters works, and when I checked the other MyRoundcube Account for the sent message, the Umlaut Letters arrived there intact as well. (before checks were always made by reading older, previously existing mails and using other roundcube setups)

Update: We finally nailed it down to just the browser view!
In other words, if you send email from within MyRoundcube, including mail with Umlaut Characters, such mails will be received and viewed correctly by any third party i.e. external email programm that doesn't use a web-browser for viewing Email. Mail from third party apps to other third parts apps work anyway (sent mails back and forth between WindowsMail, Thunderbird, and 3 machines) since that actually has little to nothing to do with Roundcube. The only place, and I do mean strictly the only place where the umlaut characters Ä, Ö, or Ü, look bad is from within Myroundcube when editing Mail from within the web-browser ... mail that was received from any other external mail client (Outlook, WindowsMail, etc.). We've eliminated this problem being caused by a browser since we were able to view the bad Umlaut characters on 3 different computers, with these 3 browsers ... IE7, FireFox 2.x and Netscape version 9. We're getting closer though ....
So, whatever the problem may be, it has to do with viewing only, and only with what's being viewed in a web-browser.

[EinfachClicken]

@rosali

Reaction: I compiled the language files from UTF8 encoding to ISO 8859-1 (ANSI) encoding and loaded up again.

Result: On some sites most things were displayed correct on others - mainly compose section - not :-(

Okay, but the compose section is clearly working. So whatever you did, did indeed work for composing messages. Which files would we need to encode (manually) for the "viewing messages" section? That's where the remainder of the problem is ... viewing messages that were received from third party i.e. other external mail programms. Our tech says that they already tried doing an install on top of the current install, and that that didn't make a difference. Their english isn't 100% fluent though ... perhaps it wasn't done via remote desktop? I'll translate your earlier response for them this morning.