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

[Avi Bryant]

On Jun 26, 2004, at 8:24 AM, Colin Putney wrote:

> Agreed, but I wasn't suggesting that we try to prevent user visible 
> strings in the source code of Seaside apps. Just that the pattern for 
> localized apps should be messages to a localization rather than string 
> literals. To localize an app, somebody has to go through the source 
> code, find all the strings and localize them in some way. Replacing 
> them with a message send is no more effort than adding a #localize 
> message.

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.

> 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.
>  Apps would add methods for dynamic strings as needed. The translation 
> app would be a simple editor for the static string table - dynamic 
> strings would have to be handled by the programmer.

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.

> The only thing the renderer would use localizations for is to figure 
> out character encodings and do HTML entities properly. Otherwise it 
> would rely on components to pass it the correct strings.

Don't agree - see above.

> The goal, as I see it, is to provide a standard mechanism and pattern 
> for localized apps.

Agree.

Avi