Brian Candler writes:

ISTM that gettext would be unnecessary overhead even if sqwebmail didn't have three-quarters of a substitution method built in.

If a particular string translation is missing from the chosen language then the default language should be used. If the default language file is also missing that string then you will see S590 or nothing at all or "???" or whatever the code puts there in such cases. BTW, the default shouldn't be English, it should be a build-time option choosing from whatever language files exist. So it should use whatever language the user chooses, if that file and particular string is available, if not is uses the build-time default, if not then it falls back to English (I'm not being a language chauvinist here, that's the only language file Sam will keep current in a release), if not then some error message generated by the code (probably just the substitution number so you can figure out which one is missing).

I agree entirely. But I covered that case merely for completeness. You COULD remove some overhead by abandoning templates but there is a big penalty to pay in terms of making it very hard to customize.

There are many ways of skinning that cat. See various perl templating systems for examples.

[...]

I'm not sure that this is a good idea. Ideally a template should look as much like the final result as possible, to the extent that you could feed it into Nightmareweaver to edit it. Dynamic expansion would make it very difficult for html designers to see what they're going to end up with. I think it has to be as close to WYSIWYG as possible.

This is the one case where WYSIWYG has to be abandoned - conditional inclusion. But even then the page designer can see where the text is going to fall, even though the width is wrong.

Again, I think HTML fragments is a bad way to go. Imagine a designer viewing one of the default pages, saving the source and editing that source to achieve the desired look. The templates should be as close as possible to that. Anything else complicates matters far too much for most page designers. They can cope (just) with [#S581#] meaning "User" and move it around the page using their favourite HTML editor, they won't cope with [#fragment1#] meaning include this fragment of HTML from elsewhere.

You're thinking like a programmer, not like a web page designer. We could do this all in TeX. That's a particularly arcane language but is capable of the task. Then we could tell the page designers that if they want corners they just need to \expandafter\cornermacro{image.gif} and they'll love us for it. Actually, they won't. They want templates that look like the final thing so they can edit them and see, in a browser, how it is going to look. You and I can expand macros in our heads and anticipate how things are going to look; they want to actually see the result. Yes, you can build a test box for them to try their templates on but they'll still hate you for not letting them use their usual tools in the way they normally use them to edit a page and see how it looks immediately. I know this from personal experience.

It may be better to load on demand. There's not much point loading Chinese translations if nobody needs them.

Since the index for translations will be essentially numbers, loading them into an array is not only adequate, it's sensible. You're not going to need an inverse lookup so no need for a hash in memory or a dbm.

Good point. Say a local_lang directory in which you put only the language files you need and they contain only the strings you've changed rather than a full set. If a string is matched in the appropriate local_lang file then use it otherwise use the standard one.

Like I said, there are many ways of skinning this cat.

Or you could use comments. I've seen plenty of templating systems that used <!--#substitute$foo--> or similar. And they annoy the hell out of our page designers because they can't see anything on the page. So the last time I knocked up a templating system I used {!-#substitute$foo-} which is of a form that would never appear in ordinary text but is visible. Actually, I also used <!--#loopstart$foo--> for loops because you do want those markers to be invisible because they mess up tables if visible.

So your idea is clever, but it violates the principle of having the template look as closely as possible to the page that gets output.

Again, I believe this to be a bad idea from the viewpoint of those who are going to edit the templates. The way to do a loop is more like:

Stuff on the page before the folder list. <!--#loopstart$folder--> <tr class="folder-index-header"> <th align="center">[#NUM#]</th><th>&nbsp;</th><th>[#DATE#]</th> <th>[#FROM#]</th><th>[#SUBJECT#]</th><th>[#SIZE#]</th> </tr> <!--#loopend$folder--> Stuff on the page after the folder list.

This makes the template look as close as possible to the page that gets output, albeit with only one row.

For conditionals I've used <!--#foo?-->foo is true<!--#foo:-->foo is false<!--#foo;--> and the equivalent {!-#foo?-}... I allowed both because there are times when it should be visible and times when it shouldn't (when it encloses a row in a table).

Agreed. Although I usually call it rowclass because it's used to select a class for alternating rows in a table, and I usually expand it to odd or even in <tr class=[!ROWCLASS|]>. Unless you have a different use in mind.

Better as things like <tr class="[#read-or-unread#]"> applied to rows. The idea, yet again, is to keep it as much like the real thing as possible.

Removing all HTML fragments from the code has to be the way to go.

So does your clever substitution scheme. The stuff might all be in one file but a page designer wouldn't be able to tell what it does just by opening it in a browser.

This is why [!ENTRY_START!] is a bad idea.

No, it has to be as unmagic as possible. It's a clever idea, the sort that appeals to programmers, but it makes the template look even less like the final thing. Think "monkey with Nightmareweaver" not "coder."

Maybe, but unless it's something a page designer who isn't a coder can see and understand by looking at the template in a browser, it's not really an improvement. You can't avoid the fact that looped structures like the folder list will have only one row but you can make that row look like the real thing and in the 'right' place. When the guy edits it he'll see it's wrapped in loopstart/loopend comments and realize that wherever on the page he wants the folder list to appear he has to move that row and its enclosing comments. Well, maybe he won't realize, but when it doesn't work he'll look more closely at the original and figure it out or read the FAQ.