[Seaside] Re: no HTML entities for 8bit characters in UTF-8 encoding

Colin Putney cputney at wiresong.ca
Mon Jun 28 17:20:02 CEST 2004


On Jun 27, 2004, at 10:03 PM, Avi Bryant wrote:

> We agree about that.  I wasn't clear enough in my message.  If you 
> recall, in the Babel discussions one argument was about putting a send 
> to #localize at every point a string was used in the source (ie, in 
> model or controller code), vs. at every point a string was displayed 
> to the user (ie, in view code).  I'm in favor of the latter, and when 
> I was showing implementations of #localize it was with that in mind.  
> So, when you were using hardcoded strings, they would still be sent 
> #localize by the view code, but it wouldn't be affecting them (they 
> just return self).  When you wanted to localize an app, you would go 
> through and change them all to something that responded to #localize 
> in a more interesting way.  You would never, except at the framework 
> level, send #localize yourself.  And a hardcoded string in the source 
> would always mean a hardcoded string in the output.

I can see the attraction of putting the localization calls in the views 
- the renderer in the case of Seaside. Late binding, right? The model 
can work with strings in their "native" representation and not worry 
about localization at all.

However, I think the added complexity pretty much negates that 
advantage. First of all, anything but the simple, static string literal 
case *does* require the model to know about localization and treat it 
specially. And yes, that's probably the most common case, but not 
overwhelmingly so - constructed strings are quite common as well.

Second, consider the case of strings requiring parameters - the "you 
have 2 knives" case. Putting localization in the controller (what I 
proposed) looks like this:

html text: (Localization youHaveKnives: 2)

By trying to delay resolution of the string, we get something like this:

html text: (ParameterizedString key: #youHaveKnives: parameters: #(2))

It's like passing around MessageSends instead of just sending messages. 
I think it's too clever, too complicated. YAGNI, and even if you do you 
won't need it *until* you need it. Let's do the simplest thing that 
could possibly work, and solve any problems as they come up. Right now, 
the issue that needs to be solved is text encoding. That clearly has to 
be addressed in the renderer framework. The rest of it can be handled 
in components by authors of localized apps. All we need is a pattern we 
can point people towards.

>> A class called WALocalization which is a superclass for localizations 
>> to specific languages. We could include say, english and two or three 
>> other languages by default, or whatever the wants and can provide. 
>> Each localization would know how to handle things like dates, times 
>> and default character encodings. Also, each localization would have a 
>> dictionary in a class variable that would be used to look up static 
>> strings via DNU.

> Sound great except that I don't understand the need for a dictionary 
> and DNU - why not have real methods returning literal strings?  Easier 
> in pretty much every respect.

Sure. I was thinking it would be easier for the translation app to edit 
a dictionary than compile methods. But yeah, that's probably overkill. 
We ain't gonna need that either.

Colin



More information about the Seaside mailing list