>>>>> "Dan" == Daniel Berlin <[EMAIL PROTECTED]> writes:
Dan> You still need to be able to display the message for each number in all Dan> the languages you want, so it's going to be stored somewhere, you Dan> haven't solved the problem, just moved it completely to the consumer. Usually I'm not a fan of using numbers instead of strings. But in this particular case I think it does make sense. One reason is that numbers are compiler-independent. This means that the IDE can provide its preferred text for each message and this will work regardless of what compiler is in use. With strings you either need to enumerate all possible strings or you need access to the compiler's message catalog -- but either of these is hard to do in a compiler-independent way. Dan> I have a very hard time believing that compiling and outputting messages Dan> in one language, and having someone who can't read those messages Dan> optimize and profile your application in another language, is a Dan> significant enough use case to be worried about. Yes, I agree that this is scenario probably does not occur often. Nevertheless I think we should aim for maximum usability -- it is a bad idea in general to design something knowing about a losing i18n case... usage frequencies change. Dan> It also has almost zero hope of working over multiple compiler versions, Dan> being future proof in general, and not having other compiler vendors Dan> fight over message number namespace. The maintenance issue is a major one. This document definitely needs to address this, and not just in some theoretical way. Otherwise, chaos ensues. I'm sure we've all seen the consequences here plenty of times, enough to insist on a solution. Tom
