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

[Avi Bryant]

On Jun 28, 2004, at 8:20 AM, Colin Putney wrote:

> 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

I'm not asking for the model to not know about localization.  I'm 
asking for the view to *also* know about localization.  I'm saying it 
should be the model's job to mark a string as needing to be localized 
(or not), but the view's job to do the actual localization.  The way 
you're proposing, the view only ever gets static strings, and has no 
idea whether they've gone through a localization process.  I'd like to 
delay that loss of knowledge as long as possible.

> 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))

Why?  I agree with you entirely on what the code should look like in 
the model.  It's just that you're picturing #youHaveKnives: returning a 
string, whereas I'm picturing it returning an object that responds to 
#localize.

Why?  For one thing, think about the halo possibilities.  If the 
renderer is getting passed static strings, all it can ever do is dump 
them out as HTML.  If it's being given localization objects of some 
kind, it can get switched into a mode where it renders text inputs or 
edit links for each localizable string.  Or it can collect all the 
localized strings on that page as it renders them, and provide a link 
that brings up a separate editor for just those strings.

Avi