and congrats, robert.

so, how and when will we update our current antville installations...? (or will there be another update before?)

nice that you like it. reg. update: we need the update-scripts before (depending whether we switch to file-based skins or stick witch db-stored ones, see my comment below). unless we haven't done that nobody who wants to use existing contents/skins in an antville-db can update without getting a bunch of errors.

some javascript functions that will be run from within the scheduler to change e.g. weblog macros to site macros and the like? that's right. could we do that next week?

of course it's ok if you merge the xml_content-branch in the main branch. just one minor question: what about using a ":" as separator in input-names instead of "_"?

localizing skins is the biggest part of it, the application messages were just the first step. i could think of the following:

1. finalize the default-skinset (with all the xhtml-compatibility-stuff, if there is any left)
2. choose a directory-structure for storing skins (also those custom-skins of weblogs; i still think that we should switch to file-based skins and drop those db-stored skins)
3. create a default-skinset for each language (most of the skins have at least some parts in them that should reflect the chosen language).

what ya think about?

1. and 2. sounds good.

but would the creation of a default skinset for each language as described in 3. not lead to a maintenance work almost impossible to handle for us? (if i see it right, we need to update each language skin if there is a change in html code or structure!?)

how about putting all of the messages in the message files you just created for the user messages?

that would mean a whole lot of maintenance work. on the other hand: if we move all localized parts of the default skin-set into the message file

• some skins will contain only macros (which isn't what i would call easy to modify); skins would be harder to understand for users.
• some macros contain prefixes and suffixes that also should be localized, but that would mean that we need to embed macros in macros, which i personally would like to avoid due to increasing complexity.

but maybe there's another possibility that i've missed (thinking about application structure is hard when you're carrying furniture from a to b ;-)

using just one skinset and including any messages and texts via a macro. Otherwise we'll just multiply the effort of modifying any skin by the number of translations we have, and if translations are maintained off-site it'll even increase the problems.

People wanting to modify messages in skins will get used to the fact that they're replacing a macro instead of the text itself.