templates/en_US/popup_charset.tmpl: maintainance nightmare?

Hello Terje,

I was just browsing around the template stuff.

I'm a bit worried about things like

       <TMPL_IF NAME="VALID">
         <TMPL_INCLUDE NAME="valid.tmpl">
       <TMPL_ELSE>
         <TMPL_INCLUDE NAME="invalid.tmpl">
       </TMPL_IF>

(in 
http://dev.w3.org/cvsweb/validator/share/templates/en_US/result.tmpl?rev=1.5 
&content-type=text/x-cvsweb-markup)

because it basically means that we have logic in two places
(perl code and templates). That also means that translators
will have to sort out code and text to be translated, a job
that I know isn't easy in particular because they will have
to deal with a new format they don't know (templates).

But it may be okay as far as it is on that level of granularity.
(note however that all of that specific file is language-independent,
so it probably has nothing to do in /en_US/).

Where I get much more worried is for popup_charset.tmpl.
When this is translated into a few languages, adding another
charset will be a real nightmare. A new charset added to the code
won't be selectable in a language unless the language-specific
file is updated. (it would be better if it were selectable,
but not translated).

One step to make things easier is to remove the explanatory text
from the value attribute (it only got there because earlier, we
used a system to produce the popup, in which case it was easier
to have both the value and the text shown in the popup to be the
same). So e.g. change
   <option value="utf-8 (Unicode, worldwide)">utf-8 (Unicode, 
worldwide)</option>
to
   <option value="utf-8">utf-8 (Unicode, worldwide)</option>
and so on. That will help translators, because they don't
have to figure out whether to translate the text
"(Unicode, worldwide)" in the 'value' or not (the way the
code works, it doesn't matter.
If you are okay, I can do that change.

In some ways, it would be nicer to have a template for each
of these texts (e.g. "(Unicode, worldwide)"). But I'm not
sure that will scale well.

In a wider sense, I think that doing some work to prepare for
message localization is good, but I'm not at all sure that
HTML Templates were the right way to go. But I'm leaving that
up to you.

There is of course also the issue of coordination with the
configuration of the charset conversion code. In particular,
should it be the validator or the charset module that knows
which encodings we want to accept because they are 'clean'?

BTW, what's the plan for 'templatizing' the rest of the text
related to charset detection/conversion? I'm affraid that
templatizing that without some preparatory moves towards
modularization could make modularization more difficult
than it has to.

Regards,    Martin.

Received on Wednesday, 22 September 2004 01:00:39 UTC