Oh, right. Then it's like some exception messages, that come untranslated from the server.
When that is tackled, though, I don't think the server should get much change. To keep it simple, all the server would need to do is send label ids instead of labels (all strings after all, it's just that the ids would look like "checked.in.file" instead of "Checked in file"), and then the client should be able to find their translation. There's always the danger of having a client without some of the translations, but client and server versions should be the same anyway, so that's unlikely. Then there's a problem of dynamization (the labels can contain variable values like in "# Getting version <<n>> of file: <<filename>>"). However, MessageFormat classes could be used, so not a big deal. Perhaps you were already thinking of a similar way of doing it, but, just in case, I wanted to say that the server and the client would need very few changes if done so, while it would be harder if the server made the translations depending on the client's selected language. Cheers, Albert. ----- Original Message ----- From: "Robert MacGrogan" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Monday, January 10, 2005 4:45 PM Subject: Re: [SourceJammer-devel] Re: Sourcejammer development > Hi, Albert. > > Those untranslated messages are all server-side. I think Timo is only working on the client. I > definitely need to add the same abstraction/trasnlation capability to the server that was built > into the client long ago. > > --Rob ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ SourceJammer-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sourcejammer-devel
