> Also glad to see Vince is working on making onTap BD
> compatible. This gives me some hope that we can at
> least start development using onTap, with hopes that
> by the time we are done, BD support will exist.
They made a point of telling me that Vince was really busy and there weren't any promises, but then they did call me personally on the phone to tell me he'd taken an interest in it, so although it's no guarantee it does sound promising.
I forgot to mention in the last email that the use of % to name localized strings is purely preferential. It's intended to reduce the likelyhood of namespace conflict in which a static string might be inappropriately replaced with a localized string. I personally tend to prefix my localized strings with %tap_ just as an added layer of protection against this phenomena. Because localized strings can be named any way you want, you can replace text in one language with another, i.e. "friend" might become "amigo" in spanish. This is not recommended because a change in the text of the original language would either cancel out the translated text (so the original language would then appear in its place) or would require updating many different resource bundles to match the change (tightly coupled in the worst way), though it might work in a pinch if you needed to replace someone else's non-i18n text temporarily while working on a migration or integrating someone else's plugin.
s. isaac dealey 434.293.6201
new epoch : isn't it time for a change?
add features without fixtures with
the onTap open source framework