« Return to Thread: Update for hungarian translation of local_autorespond_forward plugin
Re: Update for hungarian translation of local_autorespond_forward plugin
by Paul Lesniewski
::
Rate this Message:
On Sun, May 3, 2009 at 3:41 AM, Fredrik Jervfors
<jervfors@...> wrote:
>>>> This file includes a minor header fix and an additional warning for
>>>> users, not to use accentuated characters in the autoreply message
>>>> (since
>>>> that message will be sent as-is, without any charset and transfer
>>>> encoding information).
>>>
>>> I committed your new version, but afterwards I had second thoughts
>>> about it. Are you sure that it's true that auto reply messages are send
>>> as-is, without any charset and transfer encoding information in all
>>> set-ups? Or could it be that it's just your set-up that's broken?
>>
>> See the attached autoreply.tgz! It contains the vacation related files
>> created by SM, and an autoreply message generated by vacation, based on
>> the configuration by SM. My vacation version uses the file .vacation.msg.
>> I typed
>> in a certain text (in UTF-8 encoding) and I cannot see any encoding or
>> charset information either in .vacation.msg or in the message. My SM
>> installation can display this message correctly, but only because its
>> charset is UTF-8. If I change to iso-8859-2, the message becomes a
>> garbage. However, my vacation program is very old, and mybe some newer
>> versions do some MIME conversion, but this seems to be unlikely for me.
>
> I have to admit I've no idea what versions of vacation software is out
> there and how they can be configured. I don't use vacation messages I
> don't plan to do so.
I don't really either.
> Maybe Paul, who wrote the plugin, knows more about
> this or not. If this is a general problem the warning should be part of
> the plugin itself and not just in the translations thereof. You might want
> to post the issues you're having with this plugin to the plugins mailing
> list instead <squirrelmail-plugins@...>.
It depends on what plugin is being used and how the information is
written to disk. Generally, I don't think any of the vacation plugins
make a bother with the charset encoding at all. If the file is
written with PHP file functions, then the data is written in whatever
encoding the data is provided, which may end up being what the current
user's charset is. This can be borne out with some simple tests. I
think but am not entirely sure that an suid backend would end up
functioning the same way, of course depending on how the backend is
given the data and how it writes it to disk. However, if the file is
written via an FTP server, that probably introduces all sorts of other
factors, but again, assuming the file stays intact, it might be down
to the original encoding. So if SM manages to write a UTF-8 file for
a user using a UTF-8 charset (someone who uses a vacation plugin can
verify), then it's a matter of how the vacation program in use uses
that file - specifically whether or not it sends out properly encoded
emails itself - a question I'd have to let someone else who uses a
local vacation program answer.
------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
-----
squirrelmail-i18n mailing list
Posting guidelines: http://squirrelmail.org/postingguidelines
Information about translations: http://squirrelmail.org/wiki/LanguageTranslation
Statistics for translations: http://l10n-stats.squirrelmail.org/
List address: squirrelmail-i18n@...
List archives: http://news.gmane.org/gmane.mail.squirrelmail.internationalization
List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-i18n
<jervfors@...> wrote:
>>>> This file includes a minor header fix and an additional warning for
>>>> users, not to use accentuated characters in the autoreply message
>>>> (since
>>>> that message will be sent as-is, without any charset and transfer
>>>> encoding information).
>>>
>>> I committed your new version, but afterwards I had second thoughts
>>> about it. Are you sure that it's true that auto reply messages are send
>>> as-is, without any charset and transfer encoding information in all
>>> set-ups? Or could it be that it's just your set-up that's broken?
>>
>> See the attached autoreply.tgz! It contains the vacation related files
>> created by SM, and an autoreply message generated by vacation, based on
>> the configuration by SM. My vacation version uses the file .vacation.msg.
>> I typed
>> in a certain text (in UTF-8 encoding) and I cannot see any encoding or
>> charset information either in .vacation.msg or in the message. My SM
>> installation can display this message correctly, but only because its
>> charset is UTF-8. If I change to iso-8859-2, the message becomes a
>> garbage. However, my vacation program is very old, and mybe some newer
>> versions do some MIME conversion, but this seems to be unlikely for me.
>
> I have to admit I've no idea what versions of vacation software is out
> there and how they can be configured. I don't use vacation messages I
> don't plan to do so.
I don't really either.
> Maybe Paul, who wrote the plugin, knows more about
> this or not. If this is a general problem the warning should be part of
> the plugin itself and not just in the translations thereof. You might want
> to post the issues you're having with this plugin to the plugins mailing
> list instead <squirrelmail-plugins@...>.
It depends on what plugin is being used and how the information is
written to disk. Generally, I don't think any of the vacation plugins
make a bother with the charset encoding at all. If the file is
written with PHP file functions, then the data is written in whatever
encoding the data is provided, which may end up being what the current
user's charset is. This can be borne out with some simple tests. I
think but am not entirely sure that an suid backend would end up
functioning the same way, of course depending on how the backend is
given the data and how it writes it to disk. However, if the file is
written via an FTP server, that probably introduces all sorts of other
factors, but again, assuming the file stays intact, it might be down
to the original encoding. So if SM manages to write a UTF-8 file for
a user using a UTF-8 charset (someone who uses a vacation plugin can
verify), then it's a matter of how the vacation program in use uses
that file - specifically whether or not it sends out properly encoded
emails itself - a question I'd have to let someone else who uses a
local vacation program answer.
------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
-----
squirrelmail-i18n mailing list
Posting guidelines: http://squirrelmail.org/postingguidelines
Information about translations: http://squirrelmail.org/wiki/LanguageTranslation
Statistics for translations: http://l10n-stats.squirrelmail.org/
List address: squirrelmail-i18n@...
List archives: http://news.gmane.org/gmane.mail.squirrelmail.internationalization
List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-i18n
« Return to Thread: Update for hungarian translation of local_autorespond_forward plugin
| Free embeddable forum powered by Nabble | Forum Help |
