Vladimir Gorr wrote: > In my opinion using the gettext() for the i18n goals will involve too big > re-factoring of source code. > I also disagree with the 'no-meaning' for message key. All we need is to > create the sensible ID for these messages.
I think this is the case of good intentions, which pave the well-known road. As soon as the message key is *not* the thing that is printed, it is inevitable that the message sensible for one engineer, will have no meaning to the other. Do you think "K00Ec" is sensible? I think not. Do you think the developer had no chance to choose better key? IMHO, this kind of things must be *enforced*, for example, by making sure that the message key is printed in C locale (default case for most developers). > *4) Add to this that most of the developers will not know where the > localized messages are kept, > and you'll get the situation when most of the messages are not localized in > any way. > * > I'm not sure the gettext() will eliminate this issue. gettext effectively splits this issue into two *independent* tasks: - the task of the developer is to code - the task of the translator is to find translatable messages and translate them The greatest advantage of it is that developer do not need to care about translations, besides putting _() occasionally, and translators do not need to care about coding. --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
