On Sat, Apr 17, 2010 at 11:39:30PM -0700, Jeremy Kemper wrote: > > Czarek, thanks for raising this. Working with 1.9 string encodings is > too unforgiving.
After working on #2188 I can say I know exactly what you mean :)
> Most of the patches so far amount to forcing UTF-8 or 8-bit ASCII
> everywhere. Not acceptable or even desirable.
I am currently trying to work out a way that could help people
"screen" their patches that shows them in exactly which cases this
won't work, without getting into too much m17n details. The amount of
knowledge about encoding internals needed to provide a useful patch is
too much to for people just trying to globalize their applications
with Ruby 1.9.
> I love the idea of trying to force the encoding on concat and giving a
> warning. It'd be wonderful is Ruby itself offered an encoding sniffer
> so we could attempt to transcode as well.
>
> Then your app works plus you get the information you need to encourage
> the library author to add 1.9 support.
Great idea! Do you think it would also make sense to rescue concat
errors, treat them as a bug with a link to a general LH ticket about
reporting encoding errors? I mean handling concat errors is much too
late and probably requires Artificial Intelligence :)
This way we could:
- quickly classify known and new problems
- design reproducable test cases for new problems
- design ways to prevent non-default-encoded string from entering
Rails
- design a general sniffer for plugins/gems that could introduce
problems in places we cannot control/check otherwise
- close Rails 1.9 encoding compatibility tickets and milestones
- create new LH tickets for new errors beyond a specific Rails
version
>
> This would make for an excellent Ruby Summer of Code project.
I wonder if one whole summer is enough ;)
> jeremy
--
Cezary Baginski
signature.asc
Description: Digital signature
