Re: Update for hungarian translation of local_autorespond_forward plugin

> On Sun, May 3, 2009 at 3:41 AM, Fredrik Jervfors
> <[email protected]> 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 <[email protected]>.
>
> 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: [email protected]
List archives: http://news.gmane.org/gmane.mail.squirrelmail.internationalization
List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-i18n