Hi,
I was just curious to know what the status of UTF support in 2.3.5 +
Ruby 1.9 was - from the core developers point of view.
Here are the impressions I have:
- everyone is working on Rails 3, so no one really cares about 2.3,
except for serious bugs and security issues - and it looks like
1.9 issues don't count.
- 2.3.6 still won't have decent UTF8 support 'out of the box' for
Ruby 1.9, because it probably won't include the UTF-8 patches
already in LH
- 2-3-stable branch doesn't have the patches for 1.9 + UTF to work
- since no one seriously considers ruby 1.9 ready for production,
nobody is going to spend time merging patches for 1.9 encoding
support, so sending patches is a waste of time
As many articles and posts suggest, many people have been bitten by
all sorts of encoding problems with ruby 1.9. Of course LH has many
patches and solutions, but monkey-patching required to workaround the
problems is way too much for any rails newbie IMHO.
The trigger to write was an issue I currently have with ERB templates
where rails is trying to concat together a UTF8 <label> with a ASCII
<textarea> (which has 'escaped' UTF characters) within a form. I can
get to the root of the problem, find an existing patch in LH or create
a patch with test cases, etc, but that isn't the point.
Encoding problems are not really bugs, but they crash and burn the
application. Even worse - some problems occur only on the production
environment (e.g. where the default encoding turns out to be ASCII)
and the error messages are far from suggesting what the problem is, or
even how to fix it.
I was wondering if there was a way to save people a lot of grief.
Especially people who are trying to mix 'a stable rails version' with
Ruby 1.9. A few solutions that come into mind:
1. Warn about using ROR 2.3 with Ruby 1.9 in UTF applications - tell
people to use 1.8.7 only or wait for Rails 3.
2. Force encoding to UTF8 in concat (output_safety.rb) when there is
a UTF/ASCII mismatch - as an option in the configuration. Sure, this
will probably kill performance, but killing developer time is worse.
I realize this is ugly, but this may make 1.9 at least somewhat
usable without too much work on the 2-3-stable branch.
3. Hunt down all the cases where ascii encoding is used and breaks
concatenation with UTF strings, release 2.3.6 or 2.3.7 with the
fixes - and close the bugs on LH.
4. The inverse of 3 - get Rails to work properly with RUBYOPT=-KU -
currently this means adding 'encoding: ascii' to tmail files,
because of escaped characters.
5. Create an 'unstable' branch for Rails 1.9, where patches
can be added sooner without too much worry for breaking things
6. Create an official page on how to deal (or not deal) with UTF
problems in rails 2.3
Personally, I would go for 2 and have an option that tries to 'fix'
obvious cases with encoding errors - or at least in a production
environment.
I would be more than happy to put effort into solving these issues if
the status of the bugs in LH wouldn't remain too discouraging.
Thank you for your time, Your attention and any suggestions,
Cezary Baginski
--
Cezary Baginski
--
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Core" group.
To post to this group, send email to rubyonrails-c...@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
