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

[Colin Putney]

On Jun 25, 2004, at 10:44 PM, Avi Bryant wrote:

>
> On Jun 25, 2004, at 6:58 PM, Colin Putney wrote:
>
>> Well, no. That's the opposite of what I suggested above.
>>
>> Frankly I think that's too much flexibility. The whole idea of what I 
>> proposed above is *not* to have strings in the source code. If every 
>> user-visible string is a message to a single localization object, 
>> it's an easy bottleneck for translators to intercept, but still 
>> flexible enough to handle the vagaries of diverse languages.
>
> I'm not sure it's realistic to try to actually prevent people from 
> having user visible strings in the source code.  Better to make it 
> easy for them to migrate from hardcoded strings to localized ones, no?

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. And it provides a simple and clear pattern for localizers and 
readers of the code.

To make it more concrete, here's what I propose for Seaside 2.6, which 
is when you planned to include localization support, no?

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.

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.

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

Colin