En/na Sebastian Bazley ha escrit:
----- Original Message ----- From: "Jordi Salvat i Alabart" <[EMAIL PROTECTED]>>[...]
So, I would propose to write our ResourceBundle subclass that will provide the English strings for any resources missing in the per-language property file.
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!
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.
I guess we should ask the translators.
[...]
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.
[...]
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.
-- Salut,
Jordi.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
