I don't know that it is good to include the (mini) TranslateKeys in the API. I think it would be better to only allow the API translate() method to use a String. Implementors can then use an enum class if they want to keep track of strings themselves, and convert to string when translating.
(Alternatively, replace translate(TranslateKeys) with translate(Object), which would in turn call translate(String) with an object.toString() method - this will allow them to use enums directly, but not limit them to already defined strings).
What would you think of this?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I was not fond of TranslateKeys myself, solely because of the work involved keeping the api keys matched up to the buddi keys.
I only implemented it because that's what the export plugins were already using.
I'm fine with dumping TranslateKeys from the API.
If you think translate(Object) is necessary, that's fine, but if someone references an internal buddi class (like TranslateKeys), then they've broken the api contract. I'd simply leave it as translate(String).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sounds good to me. For small projects (i.e. plugins), I think Strings are a perfectly acceptable method for translating.
From the main project perspective, however, although there are difficulties in keeping TranslateKeys and English.lang in sync, I find that it is still much better than the alternative. I've worked on some large projects where hard coded strings were used as keys, and *that* was an unmaintainable nightmare! Compared to that, an enum class is amazing!
I am currently thinking about how best to integrate Java's locales with external properties files for translation, in a generic way to reuse and put into Moss. I have so far come up with nothing better than the current implementation, in which you can specify a Java locale by setting a certain key in the properties file. If you have any better ideas, let me know, and I may do some minor changes to the translation system...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Furthermore, I don't think that it's important for plugin developers to use my translations - for the most part, mine are very specific for the situation. By re-using them, people will get messages that don't quite fit in this situation. Far better to just translate them themselves (or at least provide distinct keys / values, and let whoever wants to translate them, do so).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, I think there's some value in having common items (yes, no, ok, cancel) translated once rather than trying to find someone to translate them for you. But I agree that it's just as easy to look up the key string and use it directly. I wonder if it might make sense to isolate common items out to another enum down the road and provide it via the api.
I haven't done much with localization, but probably a place to look for best practices would be large-community web frameworks like JSF, Struts, Tapestry, WebObjects, and so on, to see how they are handling it.
It might also be helpful to see if there's built-in support in Java 6 or J2EE.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hey Mike,
I don't know that it is good to include the (mini) TranslateKeys in the API. I think it would be better to only allow the API translate() method to use a String. Implementors can then use an enum class if they want to keep track of strings themselves, and convert to string when translating.
(Alternatively, replace translate(TranslateKeys) with translate(Object), which would in turn call translate(String) with an object.toString() method - this will allow them to use enums directly, but not limit them to already defined strings).
What would you think of this?
I was not fond of TranslateKeys myself, solely because of the work involved keeping the api keys matched up to the buddi keys.
I only implemented it because that's what the export plugins were already using.
I'm fine with dumping TranslateKeys from the API.
If you think translate(Object) is necessary, that's fine, but if someone references an internal buddi class (like TranslateKeys), then they've broken the api contract. I'd simply leave it as translate(String).
Sounds good to me. For small projects (i.e. plugins), I think Strings are a perfectly acceptable method for translating.
From the main project perspective, however, although there are difficulties in keeping TranslateKeys and English.lang in sync, I find that it is still much better than the alternative. I've worked on some large projects where hard coded strings were used as keys, and *that* was an unmaintainable nightmare! Compared to that, an enum class is amazing!
I am currently thinking about how best to integrate Java's locales with external properties files for translation, in a generic way to reuse and put into Moss. I have so far come up with nothing better than the current implementation, in which you can specify a Java locale by setting a certain key in the properties file. If you have any better ideas, let me know, and I may do some minor changes to the translation system...
Furthermore, I don't think that it's important for plugin developers to use my translations - for the most part, mine are very specific for the situation. By re-using them, people will get messages that don't quite fit in this situation. Far better to just translate them themselves (or at least provide distinct keys / values, and let whoever wants to translate them, do so).
Well, I think there's some value in having common items (yes, no, ok, cancel) translated once rather than trying to find someone to translate them for you. But I agree that it's just as easy to look up the key string and use it directly. I wonder if it might make sense to isolate common items out to another enum down the road and provide it via the api.
I haven't done much with localization, but probably a place to look for best practices would be large-community web frameworks like JSF, Struts, Tapestry, WebObjects, and so on, to see how they are handling it.
It might also be helpful to see if there's built-in support in Java 6 or J2EE.