On 12/7/2010 2:23 AM, Daniel Friesen wrote:
One thing our skin system "does" have is an extensive linker and system for building tooltips and accesskeys for things using our i18n system. And calls to the message system from skins are all over the place: tagline, jumpto, and basically every header that's part of a skin itself is all generated by calls to the i18n system, they are not hardcoded in SkinTemplate.
And that's the rub.
I18N is essential if you need to cover multiple linguistic zones. If you don't, I18N can increase the cost of making simple changes by a factor of 3 to 5.
I was working on a product aimed at the Brazillian market (pt-br) years ago, and the first iteration of the product was I18N'ed to the sky because we wanted to get investment from the en, es and pt-br zones. Well, that investment didn't come, we bootstrapped, and the first version to really hit the web was built exclusively for the pt-br zone. Instead of requiring a committee to meet and wasting hours just to move a button from one place to another, we could just do it. If your resources aren't infinite, I18N can have a definitely harmful effect on UI quality because it tries to break your hands every time you want to make a tweak.
As for XSLT, it's one of those languages that can't decide if it wants to be Turing complete or not. XSLT, as an output templating language, is the kind of thing that takes a task an intern can do in five minutes and makes it a job that you have to bring a consultant in for three weeks.