Update for hungarian translation of local_autorespond_forward plugin

Dear developers,

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).

In addition to this, I'd like to ask, what are your plans to solve this
problem:

http://sourceforge.net/mailarchive/message.php?msg_name=200904291924.53528.nice%40titanic.nyme.hu

Thank you,

Tamás


------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
-----
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

[Fredrik Jervfors-4]

> 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?

> In addition to this, I'd like to ask, what are your plans to solve this
> problem:
>
> http://sourceforge.net/mailarchive/message.php?msg_name=200904291924.5352
> 8.nice%40titanic.nyme.hu

See the replies to your original post.

Sincerely,
Fredrik

------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
-----
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

On 2009. április 30. 20.10.35 Fredrik 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.

Regards,

Tamás


------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
-----
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

>> 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?

OK, I'm not sure that all versions of vacation send the message text
as-is. My version is pretty old, and it's clear to me that SquirrelMail
generates .vacation files for other versions than mine. I haven't found
any documentation about those (maybe newer) versions, but I think those
versions may be able to create a properly formed mail from the vacation
message, so I removed my extra warnings (but retained the header fixes). I
attach this new version. Can you commit it, please?

Thank you in advance,

Tamás

------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
-----
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

[Paul Lesniewski]

On Sat, May 2, 2009 at 11:46 AM, Németh Tamás <nice@...> 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?
>
> OK, I'm not sure that all versions of vacation send the message text
> as-is. My version is pretty old, and it's clear to me that SquirrelMail
> generates .vacation files for other versions than mine. I haven't found
> any documentation about those (maybe newer) versions, but I think those
> versions may be able to create a properly formed mail from the vacation
> message, so I removed my extra warnings (but retained the header fixes). I
> attach this new version. Can you commit it, please?

Committed.  Thank you.

------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
-----
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

[Fredrik Jervfors-4]

>>> 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. 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@...>.

Sincerely,
Fredrik

------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
-----
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

[Paul Lesniewski]

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

> 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 maybe 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.

OK, I FOUND THE ANSWER:

The vacation program only uses the file .vacation.msg, and send that file
AS IS. Other files (.vacation.pref, .vacation.sq and .vacation.subj) are
not for different (enhanced) versions of vacation, as I thought before,
but for SquirrelMail itself (just like .forward.fwd)!!! This means that
the extra warning messages introduced in the previous version of my
translation are definitely necessary! I also encourage other languages'
translators to include such a warning (for people not to use accentuated
characters in autoreply messages). Can we revert to that version?


Thank you,

Tamás

------------------------------------------------------------------------------
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

2009/5/5 Németh Tamás <nice@...>:

> OK, I FOUND THE ANSWER:
>
> The vacation program only uses the file .vacation.msg, and send that file
> AS IS. Other files (.vacation.pref, .vacation.sq and .vacation.subj) are
> not for different (enhanced) versions of vacation, as I thought before,
> but for SquirrelMail itself (just like .forward.fwd)!!! This means that
> the extra warning messages introduced in the previous version of my
> translation are definitely necessary! I also encourage other languages'
> translators to include such a warning (for people not to use accentuated
> characters in autoreply messages). Can we revert to that version?

The bug is in the SM vacation plugin. The .vacation.msg file should
contain headers first, then empty line, then the mail body. A properly
formatted .vacation.msg should therefore look e.g. like this:

--------------------------------------------------------------
From: "Joe User" <joe@...>
Subject: This is an error autoreply...[Re: $SUBJECT]
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

I'm on vaction without any access to email.
Will only read it after return on ....
--------------------------------------------------------------

Thus if your vacation replies are broken, it means that SM generates
.vacation.msg without the necessary MIME headers. I.e. it's not
necessary to change the translations, but instead the plugin should be
fixed.

Petr

------------------------------------------------------------------------------
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

> 2009/5/5 Németh Tamás <nice@...>:
>> OK, I FOUND THE ANSWER:
>>
>> The vacation program only uses the file .vacation.msg, and send that
>> file
>> AS IS. Other files (.vacation.pref, .vacation.sq and .vacation.subj) are
>> not for different (enhanced) versions of vacation, as I thought before,
>> but for SquirrelMail itself (just like .forward.fwd)!!! This means that
>> the extra warning messages introduced in the previous version of my
>> translation are definitely necessary! I also encourage other languages'
>> translators to include such a warning (for people not to use accentuated
>> characters in autoreply messages). Can we revert to that version?
>
> The bug is in the SM vacation plugin. The .vacation.msg file should
> contain headers first, then empty line, then the mail body. A properly
> formatted .vacation.msg should therefore look e.g. like this:
>
> --------------------------------------------------------------
> From: "Joe User" <joe@...>
> Subject: This is an error autoreply...[Re: $SUBJECT]
> MIME-Version: 1.0
> Content-Type: text/plain; charset="utf-8"
> Content-Transfer-Encoding: 8bit
>
> I'm on vaction without any access to email.
> Will only read it after return on ....
> --------------------------------------------------------------

Yes, you're right, I also think that it's possible for the plugin to
compose a properly formatted message into .vacation.msg (from .vacation.sq
and .vacation.subj).

> Thus if your vacation replies are broken, it means that SM generates
> .vacation.msg without the necessary MIME headers. I.e. it's not
> necessary to change the translations, but instead the plugin should be
> fixed.

I agree with you, the plugin should be enhanced. (However, the command
line interface of vacation creates unformatted messages, too.)

Tamás


------------------------------------------------------------------------------
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