----- Original Message ----- From: "Jordi Salvat i Alabart" <[EMAIL PROTECTED]> To: "JMeter Developers List" <[EMAIL PROTECTED]> Sent: Sunday, January 18, 2004 11:56 PM Subject: Re: Bean Properties
> En/na Sebastian Bazley ha escrit: > > ----- Original Message ----- > > From: "Jordi Salvat i Alabart" <[EMAIL PROTECTED]> > >[...] ... > > I don't think any coding is necessary - AFAIK, Java already does this. > > E.g. if Java does not find "open_file" in message_de.properties, it will check for > > "open_file" in messages.properties. > > [This confused me when I originally wrote the resource JUnit test - it did not > > find missing keys in the de/no/ja files, because it > > defaulted to the ones in messages.properties. This is why the code parses the > > entries itself, rather than using the Java methods...] > > Is it that clever? Wow! Not really - I presume it just looks for a properties file without a locale suffix. If the English properties file were called messages_en.properties, I don't think it would look there. It just so happens that messages.properties contains English, but there's nothing really to tell Java that. Which is presumably why i18nEdit wants to know what the default language is. > > We need to choose: > > - either we assume that translators will use i18nEdit or similar, and remove the > > English values (and keys?) > > - or we leave the English values in the file so that translators can work on files > > in isolation > > I don't mind which. > > The problem with the later is that once an initial translation has been > done, there's no way to "tell" the translator that a change has been > made to the English text and the translation should be reviewed. I'm > thinking about semantical changes, not spelling, of course. Except perhaps by remembering to copy the new English version of the text to all the other files. > I guess we should ask the translators. Indeed! > > [...] > > > As an initial implementation, using the Java names would be OK, but I don't think > > they can be left like that. > > Too restrictive when choosing class and variable names, and one cannot use spaces > > ... > > Of course it's a prototyping feature -- only, as I suggested, for > Alfa/Experimental stuff. OK: remove the Beta. OK, I'm happy with that. > > > [...] > > > > By the way, I found I needed to add *.metaprops to Eclipse Team files to be > > ignored ... > > The plan is to keep those in CVS. OK - I guess we'll need those once we start using i18nEdit in earnest. S. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
