Hello.
Sometimes to me letters in such charsets come. No, I don't correspond with Chinese or Koreans. But someone writes on cyrillic using these charsets.
These codings, as well as UTF-8, allow to mix characters of different national alphabets, including Latin and cyrillic in the letter.
Some e-mail clients work with this coding normally.
As far as I can judge, RC 1.1.4 doesn't support these codings.
Whether there is a support of these codings in the latest version of RC?
Whether it is planned to add it to next versions?
Most likely, I should add it to RC 1.1.4 urgently. I will be grateful if to me help to find places where different codings for a letter body, both HTML, and the text are processed. I found processing of codings in titles recently.
If it is interesting to someone, I am ready to transfer results of this work.
On 22.09.2016 09:45, Vladimir Gorpenko wrote:
As far as I can judge, RC 1.1.4 doesn't support these codings.
Roundcube supports all encodings supported by iconv/mbstring.
Do these letters specify encoding in mail headers and/or HTML head?
Do you have php-mbstring installed?
Are you sure they are properly encoded? E.g. if conversion to utf-8 fails (using mbstring or iconv) then the content will be displayed as is (with removed non-unicode characters).
Yes, mbstring is installed. But one configuration setting raises doubts:
Multibyte Support enabled Multibyte string engine libmbfl HTTP input encoding translation disabled libmbfl version 1.3.2
I do not know, is "HTTP input encoding translation" significant for my situation or now.
Now I have a letter with GB2312 charset.
This encoding is specified in:
headers, where it is used: Subject: =?gb2312?B?STo...
Content-type header:
Content-Type: text/plain; charset="gb2312" Content-Type: text/html; charset="gb2312"
- The coding is mentioned in HTML headers quite strange. I don't know,
what does it mean.
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" = xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:x=3D"urn:schemas-microsoft-com:office:excel" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" = xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta = http-equiv=3DContent-Type content=3D"text/html; charset=3Dgb2312">
I am sure the letter is encoded properly because eM client opens it correctly. But in RC I see something like the Arab characters.
Best regards, Vladimir Gorpenko
A.L.E.C писал 2016-09-22 10:48:
On 22.09.2016 09:45, Vladimir Gorpenko wrote:
As far as I can judge, RC 1.1.4 doesn't support these codings.
Roundcube supports all encodings supported by iconv/mbstring.
Do these letters specify encoding in mail headers and/or HTML head?
Do you have php-mbstring installed?
Are you sure they are properly encoded? E.g. if conversion to utf-8 fails (using mbstring or iconv) then the content will be displayed as is (with removed non-unicode characters).
On 22.09.2016 10:27, Vladimir Gorpenko wrote:
Multibyte Support enabled Multibyte string engine libmbfl HTTP input encoding translation disabled libmbfl version 1.3.2
I do not know, is "HTTP input encoding translation" significant for my situation or now.
input/output encoding must be disabled.
Now I have a letter with GB2312 charset.
This encoding is specified in:
headers, where it is used: Subject: =?gb2312?B?STo...
Content-type header:
Content-Type: text/plain; charset="gb2312" Content-Type: text/html; charset="gb2312"
- The coding is mentioned in HTML headers quite strange. I don't know,
what does it mean.
xmlns=3D"http://www.w3.org/TR/REC-html40%22%3E<head><meta = http-equiv=3DContent-Type content=3D"text/html; charset=3Dgb2312">
This looks fine. Do you have the same problem if you display the message in both text and html modes?
I am sure the letter is encoded properly because eM client opens it correctly. But in RC I see something like the Arab characters.
What PHP version? Could you forward a sample message to me?
A.L.E.C писал 2016-09-22 11:30:
This looks fine. Do you have the same problem if you display the message in both text and html modes?
I think so. I switched the "Prefer HTML" checkbox and opened the letter, I tried to answer in a text format. In both cases characters were wrong.
What PHP version? Could you forward a sample message to me?
PHP 5.6.25.
Unfortunately, the letter about which there is a speech contains the commercial information. Possibly, I could delete from it some parts and send in such look.
There was also a letter in ISO-2022-KR. It can be sent, but it from other source and strongly differs. HTML version there the strange and as if defective. But eM client opens it correctly.
Best regards, Vladimir Gorpenko
On 22.09.2016 10:52, Vladimir Gorpenko wrote:
This looks fine. Do you have the same problem if you display the message in both text and html modes?
I think so. I switched the "Prefer HTML" checkbox and opened the letter, I tried to answer in a text format. In both cases characters were wrong.
In this case I'm afraid it uses HTML part only. Just use the HTML/Plain switch in mail preview (upper right corner).
The letter opens incorrectly in both text and HTML modes.
Best regards, Vladimir Gorpenko
A.L.E.C писал 2016-09-22 11:53:
On 22.09.2016 10:52, Vladimir Gorpenko wrote:
This looks fine. Do you have the same problem if you display the message in both text and html modes?
I think so. I switched the "Prefer HTML" checkbox and opened the letter, I tried to answer in a text format. In both cases characters were wrong.
In this case I'm afraid it uses HTML part only. Just use the HTML/Plain switch in mail preview (upper right corner).
It seems, the problem will be resolved by itself.
I have two web servers - for work and for debugging. They work with the same IMAP/SMTP server and with the same mail base.
On the work server PHP 5.6.17 is set. On it the problem is urgent.
On a test server PHP 5.6.25. On it the problem was, but unexpectedly (perhaps, after reset) it was gone. Now Subject and body, both HTML and text are correct.
Now I hope that after updating of the work server the problem will be gone also on it. I will make it tonight.
Best regards, Vladimir Gorpenko
A.L.E.C писал 2016-09-22 11:53:
On 22.09.2016 10:52, Vladimir Gorpenko wrote:
This looks fine. Do you have the same problem if you display the message in both text and html modes?
I think so. I switched the "Prefer HTML" checkbox and opened the letter, I tried to answer in a text format. In both cases characters were wrong.
In this case I'm afraid it uses HTML part only. Just use the HTML/Plain switch in mail preview (upper right corner).
Hi all,
I am using |rcmail.gettext('somelabel', 'plugin-name') to label something within my java script file (as described in Wiki). But my label is always 'somelabel' and not the translated text. My plugin name has underscores in the name, but that should not matter?
What am I doing wrong?
Thank you
Regards, Jack |
I am using |rcmail.gettext('somelabel', 'plugin-name') to label something within my java script file (as described in Wiki). But my label is always 'somelabel' and not the translated text. My plugin name has underscores in the name, but that should not matter?
What am I doing wrong?
you also need to pass through those strings to the javascript from the php backend. in the php bits you'd have these :
// load in the language strings from plugindir/localization/ $this->add_texts('localization/', false); // send the strings to the client $rcmail->output->add_label(['somelabel']);
likely, you'll call add_texts in your init() function, and add_label inside a function you are referencing with register_action or add_hook inside the init() function. you can call it in init() if need be, you might just need to wrap it inside a test to make sure the add_label function exists:
$this->rc = rcube::get_instance(); if (method_exists($this->rc->output,'add_label')) { $rcmail->output->add_label(['somelabel']); }
then inside your javascript you can call rcmail.get_label('pluginname.somelabel') to get the localized version of that string. (you can see the labels stored in rcmail.labels)
doing it this way allows the php backend and js frontend scripts to both have access to the localized strings.
On Wed, Sep 28, 2016 at 6:24 PM, Brendan brendan@tucows.com wrote:
I am using |rcmail.gettext('somelabel', 'plugin-name') to label something within my java script file (as described in Wiki). But my label is always 'somelabel' and not the translated text. My plugin name has underscores in the name, but that should not matter?
What am I doing wrong?
you also need to pass through those strings to the javascript from the php backend. in the php bits you'd have these :
// load in the language strings from plugindir/localization/ $this->add_texts('localization/', false); // send the strings to the client $rcmail->output->add_label(['somelabel']);
Actually, $this->add_texts('localization/', true); does exactly that in one go. The second argument set to true exports all texts to the client.
~Thomas
-
A.L.E.C -
Brendan -
Joogl -
Thomas Bruederli -
Vladimir Gorpenko