I think this is going to be something that's just awkward on Solaris, 
like a lot of other gettext stuff, unfortunately.

well, for Solaris 10 I had to install the region packages ceu, weu, 
neu, eeu, sue, sam, cam and nam locale packages using localeadm. Which 
then installs the complete locales including lc_message for that 
regions (weu eg. is western europe). This adds a lot of stuff to the 
system which is not really needed there e.g. LC_MESSAGES for X11 progs 
e.g. evolution, gnome, gimp etc. those programs are not installed on 
the system. So to me the MESSAGES in any language are not necessary.



Users on systems without root access, will have problems to install 
those packages.



For Solaris 9 I installed the following packages:



SUNW1251f SUNW5xmft SUNWarrf SUNWceudt SUNWceuos SUNWceuow SUNWceuox 
SUNWcxmft SUNWeeudt SUNWeeuos SUNWeeuow SUNWeeuox SUNWeu8df SUNWeu8os 
SUNWeu8ox SUNWeudba SUNWeudda SUNWeudhr SUNWeudis SUNWeudiv SUNWeudlg 
SUNWeudmg SUNWeuezt SUNWeuhed SUNWeuluf SUNWeulux SUNWeuodf SUNWeurf 
SUNWeuxwe SUNWi13cs SUNWi13rf SUNWi15cs SUNWi15rf SUNWi1cs SUNWi1of 
SUNWi2cs SUNWi2rf SUNWi4rf SUNWi5cs SUNWi5rf SUNWi7cs SUNWi7rf 
SUNWi8rf SUNWi9cs SUNWi9rf SUNWinttf SUNWislcc SUNWislcx SUNWjxmft 
SUNWkxmft SUNWneudt SUNWneuos SUNWneuow SUNWneuox SUNWplow SUNWplow1 
SUNWseudt SUNWseuos SUNWseuow SUNWseuox SUNWtxfnt SUNWuiu8 SUNWuiu8x 
SUNWulcf SUNWulcfx SUNWulocf SUNWuxlcf SUNWuxlcx SUNWweudt SUNWweuos 
SUNWweuow SUNWweuox



with the same overhead as for Solaris 10.



Didi

Can you be more specific about what you had to install? Why do you 
think the locales are unnecessary, and why do you think other users 
can't necessarily do what you did?

+1 for requiring unicode support.

Ok, I was able to solve this problem by installing a lot of additional 
(and basically elsewhere unneeded) locales. But I think this is not 
always possible for a user.

supporting such systems would be nice on one hand, on the other I'd 
like to know how to enable the UTF-8 support on the server (Solaris 9, 
Solaris 10)

So it exactly what I assumed in the beginning. Your server doesn't 
support UTF-8 locales and DIMP doesn't work with non-UTF-8 locales.

And the question still is, do we want to support such systems, like we 
still do with other Horde apps, or do we set this as a requirement?

only the various test.php pages come back in UTF-8

also ISO-8859-1

And the other apps?

Hmm... Western ISO-8859-1

But what is the charset that your browsers see if you enter DIMP vs. 
other Horde apps?

MS IE 6.0 WinXP/SP2 shows the same behaviour.

I think it's not the Browser....

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.3) Gecko/20070309 
Firefox/2.0.0.3

Opera/9.20 (X11; Linux i686; U; en)

Firefox 1.5.0.7 on Win XP/SP2

Firefox 1.5.0.11 on Win XP/SP2 (Gecko/20070312 Firefox/1.5.0.11)



I hope they are not to exotic :-)

Strange, your Horde login screen comes back in utf-8 just fine. Any 
chance that you use some exotic browser? Did you try another?

mbstring is compiled in and enabled:



from php_nfo()



Multibyte Support         enabled

Multibyte string engine         libmbfl

Multibyte (japanese) regex support         enabled

Multibyte regex (oniguruma) version         4.4.4

Multibyte regex (oniguruma) backtrack check         On



mbstring extension makes use of "streamable kanji code filter and 
converter", which is distributed under the GNU Lesser General Public 
License version 2.1.



Directive        Local Value        Master Value

mbstring.detect_order        no value        no value

mbstring.encoding_translation        Off        Off

mbstring.func_overload        0        0

mbstring.http_input        pass        pass

mbstring.http_output        pass        pass

mbstring.internal_encoding        no value        no value

mbstring.language        neutral        neutral

mbstring.strict_detection        Off        Off

mbstring.substitute_character        no value        no value



you can check that also under:  https://webmail.tugraz.at/horde/test.php

Yes, JSON must be utf-8 (or an ascii subset).

Because the server OS doesn't support it. That's not an issue usually, 
though they will loose all benefits of using Unicode. But there might 
be a problem with JSON that MUST be Unicode. Could be an issue with 
mixing a non-utf interface with utf-8 javascript or some such.

I guess the question is, why isn't utf-8 being used? Lack of 
iconv/mbstring on the server to convert it?

The important information from your screenshot is, that you your pages 
are not displayed in UTF-8.



I wonder if we should take the hassle of supporting non-utf platforms at all.

next shot



(sorry for so many messages, but I don't know how to attach more than 
one file at once)

next shot

next shot

Here are some screenshots, to illustrate how it looks like.

I discovered that in the message view (double clicking on the subject) 
the text does not get truncated when a German Umlaut is present. It 
happens only in the mboxlist view. Note, that also the fullname gets 
truncated if there is an Umlaut, see dimp_umlauts_mboxlist.png.

OK, I'll see that I find something...

Thx

Unless you can trace down exactly in the code where this is happening, 
we can't do anything about this since it works fine for everyone else.

No, never seen this.

Still not seeing it here.  Jan, do you see this?

Strange...

I still see it, it got even worse, now (cvs updated April 24 2007) 
messages get also cut in the message view.

- Firefox 2.0.0.3 on Linux.

- Firefox 1.5.0.7 on XP

Can not reproduce.  I replied to the message sent to bugs@ with the 
text from below and it worked just fine.

When replying to a message, the quoted message part gets cut after the 
first occurrence of a German Umlaut.



Example:

Das ist der nächste Test

zweite Zeile



gets quoted as: