-1. Text can be just as much a part of a skin as visual images are. For example, if you define a skin that adds an icon, I think you should define the alternate text for that icon in the same artifact - the skin.
It's artificial to my taste to decide that all translatable text are messages, and that MessageBundle should be used to customize every last bit of text. FWIW, I'm never a big fan of "Windows designed it such a way, so let's do it the same way", etc... too often, software is designed badly. I saw many Java libraries follow the poor example of JSTL and Struts and add "bundle" and "key" properties onto all tags that required translatable text. JSF intentionally pushed aside that precedent, and I'm glad we did. -- Adam On 3/17/07, Simon Lessard <[EMAIL PROTECTED]> wrote:
Hello all, here's a controversial issue. I'm not too fond of the resource bundle being part of a skin. To me, it's just added complexity for users as they have to split their text resources between two files (or use the same file for both but define it in 2 different places). I would rather see those text resource being loaded from the application specific message bundle and then from the embedded MessageBundle class, leaving only the "how" page are shown to skin, not the "what". To my opinion, here're the pros and cons of the feature: Pros: - Allow you to change some text resources simply by changing used skin; - Can be useful if you have a skin for small screen where you need to get text resources as short as possible. Cons: - If you want to use a skin but change the text resource you have to redifine a new skin inheriting the skin you want to use just to override the text resources; - It split the text resources in one more file rather than using the application specific message-bundle which is the easiest to understand for users; - It's incorrect for a skin to switch text values as a skin should not affect the perceivable semantic of an application. For example, I don't think it should be the skin responsibility to choose the the tooltip applied to a next set link of a process train, but this feature allow you to have one skin defining the text to "Next step group" and another to "Next step". The true semantic behind would be of course unchanged as the skin cannot control that, but to the user it's going to be different. Furthermore, to my knowledge, Winamp skins and Windows themes does not affect text resources and since those are the most well known form of skinning, I think we should conform to that. Regards, ~ Simon
