https://sourceforge.net/apps/trac/sourceforge/ticket/20723
I have read MikTeX forum e-mails originating from
https://sourceforge.net/projects/miktex/forums/forum/33790
for many years. Very recently, something changed in the messaging
format, and now non-printing characters appear as text strings in the
body of the message. So the typical message is filled with strings such as =0A and =0A=0A and ).=0A=0D=0A. No amount of tweaking of my e-mail client (Eudora 7) can restore legibility to my messages, and I must conclude that something changed at sourceforge.net.
Example email:
=0ARead and respond to this message at: =0Ahttps://sourceforge.net/project=
s/miktex/forums/forum/33790/topic/4619709=0ABy: clembibou=0A=0A=0D=0AHi=0D=
=0A=0D=0ASince the last update MikTex (23/07/2011), if I try to launch the=updater the=0Afollowing error pop-up appears:=0A=0D=0AWindows API error 1=
113: No mapping for the Unicode character exists in the target=0Amulti-byt=
e code page.=0A=0D=0AI understand this could be related to Windows version=with accentuated path=0A(my username has an accent). However, I never got=
this problem before with MikTex=0A(or any other software) which I use for=
years on French MS Windows systems.=0AI executed "fc-cache --verbose" as=
suggested by a post on the Internet, but=0Ano problem are reported and fc=-cache succeeds. MikTex (LaTeX, PdfLaTeX...) works=0Afine, only the update=
r generates the error.=0A=0D=0AAnybody with an idea for a workaround?=0D=
=0AThanks in advance=0D=0A(a Spanish speaking member of the forum reports=a similar problem)=0D=0A=0A=0A_=
=0AYou are receiving this email=
because you elected to monitor this topic or entire forum.=0ATo stop moni=
And also from https://sourceforge.net/apps/trac/sourceforge/ticket/20806:
Hi.
I have a query regarding monitoring feature in forums(e.g. Open discussion).
If I enter topic title and its contents with English, there is no issue. Relevant reply to specific topic is beautifully delivered into my email inbox via monitoring feature. Thanks for this, i don't need to bother to log in to my project site every once in a while to check other team mate's reply. great!
But the problem is once I use Korean language (yes, i am Korean) as a topic title, delivered email messages are all broken like what i provided with the screenshot(1.png).
Strangely, if i use English with a topic title, email message is not broken even if reply content is written in Korean language (refer to 2.png).
Is it supposed to work like this? or unreported glitch something?
Thanks for your support in advance.
I'm not sure if these two issues are related, but they appear to be at least.
To engr.geek.net:sfx
09e271d..5f9ddea HEAD -> jwh/2519
jwh/2519!sfx> qa
Todays random choice is: Rick
I did a quick google for Zend mail header encoding issues and there have been several, so I simply imported the Mail module from the latest Zend Framework and it appears to be working fine.
To test:
- login as admin1
- find a ticket, add a comment and make sure you're monitoring it
- find a forum post, add a reply and make sure you monitor it
- login as user01, add comments and replies to the previous tickets/posts
- make sure you receive email
- go to /users/admin1 and click 'send me a message', make sure you get that too
I'm not actually able to replicate the issue referenced in the ticket in a sandbox, so this is simply an update and pray.
Looks good from what I can tell. Putting in validation.
Originally by: kossieteam
Hi SourceForge engineering team.
I am the Korean developer who reported this issue.
Thanks for your work so far.
I did test it just before and I still can reproduce the issue.
If you need any help from my side, i am happy to help you.
Thanks.
Hi Kossie,
We believe we've made the fix in the code, but haven't pushed it to our production servers yet. That should be soon, and we'll post an update here when we have.
Threw a 500 error on production for some reason, re-opening
To engr.geek.net:sfx
66d25cb..e87b7ef HEAD -> jwh/2519b
jwh/2519b!sfx> qa
Todays random choice is: Dave
Looks good, merged. Set to 'validation' since we've had trouble with it
Tested on production, looks good here.