[Catalyst] Localization (was - Where should constraints go)

[Ian Docherty]

John Siracusa wrote:

...cut...
> Warning!  Localization alert! :)  Like I said before, I don't think
> you really want to be passing things to the view at that granularity.
> It makes for some vary hairy form templates--one for each locale, to
> boot.
>
> If you whip up all this stuff *before* passing it off to the template,
> you get templates like this (shown using Mason with a
> "designer-friendly" syntax for the form/fields which just translates
> deterministically into the corresponding method calls at runtime):
>
>    <% '/messages.mc', %ARGS %>
>
>    <% 'START_FORM' |fm %>
>
>    <table>
>
>    <tr>
>    <td class="label"><% 'USERNAME:LABEL' |f %></td>
>    <td class="field"><% 'USERNAME:FIELD' |f %></td>
>    </tr>
>
>    <tr>
>    <td class="label"><% 'PASSWORD:LABEL' |f %></td>
>    <td class="field"><% 'PASSWORD:FIELD' |f %></td>
>    </tr>
>
>    <tr>
>    <td colspan="2"><% 'LOGIN_BUTTON:FIELD' |f %></td>
>    </tr>
>
>    </table>
>
>    <% 'END_FORM' |fm %>
>
> That's one form template for all supported languages, complete with
> extremely granular, localized error messages.  (e.g., "The username
> 'whatever' is already taken.  Please choose another.")  The form-wide
> messages go in the message box produced (or not, if no messages) at
> the top by messages.mc.  The per-field errors are returned by the
> "USERNAME:FIELD" calls and go under each field.
>
> Even ignoring localization, you will save much sanity by constructing
> all this stuff "perl-side" before passing it off to a template.
>
> -John
This all makes excellent sense, since localisation is another thing to 
worry about on my agenda!

Leaving aside my original question, I do however have the following 
observations.

1) The contents of USERNAME:LABEL and USERNAME:FIELD have to be created 
somewhere. I assume that this is in the controller, which creates some 
HTML (using widgets or the like) and which inserts the localised text?

2) I don't like the idea of there being *any* html code produced in the 
controller  since in principle  the same controller could be used for 
different output media.

3) ISTM that there should be another layer between the controller and 
the Template to perform the localisation. Perhaps this is where the View 
needs to actually have code rather than taking the passive approach that 
I see in all the Catalyst examples. So the controller would generate 
some generic error flag (e.g. a flag to warn that the username field is 
already taken, or is too long) and the localisation 'layer' would 
convert this into the appropriate language version.