To be honest, I'm not sure what the right way to deal with this is 
either. I'd suggest you name the change set very explicitly 
(UTF8Clipboard-V39ONLY.cs or so) and attach it to the bug report, with a 
comment explaining its purpose.

Cheers,
   - Andreas

frank.urbach at schmees.com wrote:
> Hi Andreas,
> 
> For a stock 3.9 image the changeset UTF8Clipboard.cs didn't work in my environment(3.9 image and 3.10.6 vm on Windows XP). I slightly modified this as you can see in the attached file. Because I don't know the right way submit this modified changeset( open a new bugreport or atach the file to the old one??) Could you please review this. With the hint for the right place I will put it there.
> 
> Cheers,
>   Frank 
> 
> -------- Original Message --------
> Subject: Re: Win32 VM 3.10.6 problem with special characters (11-Okt-2007 18:01)
> From:    Andreas Raab <andreas.raab at gmx.de>
> To:      frank.urbach at schmees.com
> 
>> Hi Jens -
>>
>> The problem you see comes from the VM now universally taking UTF-8 and 
>> your (3.9) image being unaware of this situation. You will have to apply 
>> the changes available here:
>>
>> http://bugs.squeak.org/view.php?id=6523
>> http://bugs.squeak.org/view.php?id=6525
>> http://bugs.squeak.org/view.php?id=6526
>>
>> Cheers,
>>   - Andreas
>>
>> Jens Moenig wrote:
>>> dear squeakers,
>>>
>>> I have run into two problems after switching from a 3.9.2 vm to the current
>>> 3.10.6 in a deployed application using the current stable 3.9 image. The
>>> main reason for switching was the new splash feature, which does help a lot
>>> on slower machines. However there seems to be an issue with special
>>> characters (German Umlaute, sharp s's and paragraph characters).
>>>
>>> The first problem is, files containing such characters (Umlaute) are shown
>>> garbled in StandardFileMenu.
>>>
>>> Interestingly these 'garbled' file(name)s load perfectly ok from
>>> StandardFileMenu as well as using Smalltalk getSystemAttribute: 3, or
>>> FileStream requestDropStream: n. But it just doesn't look nice in a 
>>> deployed
>>> application, and I don't really want to restrict users' creativity in
>>> composing inventive fileNames ;-).
>>>
>>> The second problem is, these special characters simply get lost in the
>>> clipboard.
>>>
>>> This is somewhat worse, because my application builds on user defined
>>> strings as Dictionary keys. Whenever someone  pastes such a string from
>>> another place in or outside the image using the clipboard it first has to 
>>> be
>>> manually corrected, otherwise things don't work out.
>>>
>>> As I'm mostly just 'lurking' in here I'm not sure if this problem has been
>>> reported before or - indeed - if it's a problem for others as well or just 
>>> a
>>> side effect of the unicode effort aparently going on. For the moment, I 
>>> have
>>> switched back to the 'vintage' 3.9.2 vm (which works just fine). But I
>>> wouldn't want to be 'left bedind', so any help is appreciated.
>>>
>>> Thanks
>>> -Jens
>>>
>>>
>>
> 
> 
> Edelstahlwerke Schmees GmbH 
> Geschäftsleitung Clemens Schmees
> Sitz D-01796 Pirna
> Handelsregister Dresden HRB 54
> E-Mail: es.la at schmees.com 
> WEB:     www.schmees.com 
> 
> Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet.
>  
> This e-mail may contain confidental and/or privileged information. If you are not intended recipient or have received this e-mail in error, please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is stictly forbidden.
> 
> 
> ------------------------------------------------------------------------
> 
>