You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Mattias J <ma...@expertsystem.se> on 2005/05/22 09:12:57 UTC
[i18n] Remaining issues
Here is a list of what I think needs to be done before i18n is moved to
proper/released as 1.0:
* If the id ("parent") exists, but the entry ("child") does not, the
ResourceBundleMessageProvider throws an exception (erroneously claiming "No
message entries found for bundle with key ..."), while the
XMLMessageProvider returns null.
Proposed fix: Make all implementations of MessageProvider.getText() return
null if message is not found and have MessageManager.getText() throw the
Exception instead. We can then remove the try/catch in MessageManager.
Also consider renaming MessageProvider.getText() to
MessageProvider.findText() to make this more obvious for implementors.
* The ResourceBundleMessageProvider and the XMLMessageProvider behave
differently when an entry does not exist in a non-default language. With
ResourceBundles, if there is an entry, say
helloWorld.notTranslated=This entry is not translated to any other languages
that only exists in the default locale file, the entry will be included
when calling getEntries() for *any* locale. Whereas for XML, only the
entries defined for the given locale will be returned.
Proposed fix: First of all, I am not sure I personally think this needs
fixing, since all the entries should normally be translated. Secondly, I
don't know which behaviour I believe is most correct, but since we cannot
change the implementation of ResourceBundle, the only option would be to
make XMLMessageProvider (and any other MessageProvider) behave the same way
as the ResourceBundleMessageProvider. If we decide this does not need to be
fixed, we need to document the difference in behaviour somewhere (JavaDoc?).
* Consider the semi-circular dependency between MessageManager and the
MessageProvider implementations. The implementations are used, via the
interface, by the MessageManager and the MessageManager is used by the
implementations for install/uninstall through static methods, and for
internal error messages.
Proposed fix(es):
1. Remove the static install/uninstall/update methods on the
MessageProvider implementations.
2. Move the MessageManager.INTERNAL_MESSAGES and the internal message
keys to a utitly class, say I18nUtils. I have ideas for other stuff to put
there too. Another alternative would be to consider whether we actually
need these error messages in the MessageProvider implementations. As of the
above proposal, at least the use of MessageManager.NO_MESSAGE_ENTRIES_FOUND
should be moved to MessageManager instead.
* Consider the circular depency between the "org.apache.commons.i18n" and
"org.apache.commons.i18n.bundles" packages. For example
org.apache.commons.i18n.LocalizedException uses
org.apache.commons.i18n.bundles.ErrorBundle which is a subclass to
org.apache.commons.i18n.LocalizedBundle.
Proposed fix: Personally I think the org.apache.commons.i18n.bundles
packages is a bit overkill; why not remove it altogether? Otherwise, move
the LocalizedException/RuntimeException/Error into the bundles package (or
another package such as "org.apache.commons.i18n.exceptions").
* The I18nTestSuite is not up to date.
Proposed fix: Remove it altogheter. There is no real use for it, and it is
easy to forget to keep it up to date.
* Synchronize Maven (project.xml) and Ant (build.xml).
Proposed fix: Add jcoverage test coverage to build.xml. (I have EMMA test
coverage with Ant locally). This might imply adding jcoverage jars to a lib
dir.
* Create a database/JDBC MessageProvider to be used out-of-the-box,
subclassed or as an example.
Proposed fix: I have it in my head, just need to find the time to code it.
* Unify XML indentation.
Proposed fix: We decided on 4 spaces, right? Then just use your favorite
IDE to auto-indent *.xml.
* Consider renaming the file with the internal error messages. It is quite
possible a user of the library would like to put their own error messages
in messages.properties.
Proposed fix: Rename src/resources/messages*.properties to
src/resources/i18n-messages*.properties and update corresponding code.
* Consider examples with qualified entries.
Proposed fix: Create code example that use my modification with qualified
provider/namespace/source.
* Consider adding check style plugin in project.xml and fix whatever it
reports.
Mattias Jiderhamn
Expert Systems
Mail:
<ma...@expertsystem.se>mattias.jiderhamn@expertsystem.se
Web: <http://www.expertsystem.se/>www.expertsystem.se
Skype: <callto://mattiasj78>mattiasj78
[i18n] Remaining issues (updated 2005-06-18)
Posted by Mattias J <ma...@expertsystem.se>.
[A few entries have been removed and a comment has beedn added to the list
of remaining issues previously posted]
Here is a list of what I think needs to be done before i18n is moved to
proper/released as 1.0:
* If the id ("parent") exists, but the entry ("child") does not, the
ResourceBundleMessageProvider throws an exception (erroneously claiming "No
message entries found for bundle with key ..."), while the
XMLMessageProvider returns null.
eturn
null if message is not found and have MessageManager.getText() throw the
Exception instead. We can then remove the try/catch in MessageManager.
Also consider renaming MessageProvider.getText() to
MessageProvider.findText() to make this more obvious for implementors.
* The ResourceBundleMessageProvider and the XMLMessageProvider behave
differently when an entry does not exist in a non-default language. With
ResourceBundles, if there is an entry, say
helloWorld.notTranslated=This entry is not translated to any other languages
the entry will be included
when calling getEntries() for *any* locale. Whereas for XML, only the
entries defined for the given locale will be returned.
Proposed fix: First of all, I am not sure I personally think this needs
fixing, since all the entries should normally be translated. Secondly, I
don't know which behaviour I believe is most correct, but since we cannot
change the implementation of ResourceBundle, the only option would be to
make XMLMessageProvider (and any other MessageProvider) behave the same way
as the ResourceBundleMessageProvider. If we decide this does not need to be
fixed, we need to document the difference in behaviour somewhere (JavaDoc?).
* Consider the semi-circular dependency between MessageManager and the
MessageProvider implementations. The implementations are used, via the
interface, by the MessageManager and the MessageManager is used by the
implementations for install/uninstall through static methods, and for
internal error messages.
Proposed fix(es):
1. Remove the static install/uninstall/update methods on the
MessageProvider implementations.
2. Move the MessageManager.INTERNAL_MESSAGES and the internal message
keys to a utitly class, say I18nUtils. I have ideas for other stuff to put
there too. Another alternative would be to consider whether we actually
need these error messages in the MessageProvider implementations. As of the
at least the use of MessageManager.NO_MESSAGE_ENTRIES_FOUND
should be moved to MessageManager instead.
* Consider the circular depency between the "org.apache.commons.i18n" and
"org.apache.commons.i18n.bundles" packages. For example
org.apache.commons.i18n.LocalizedException uses
org.apache.commons.i18n.bundles.ErrorBundle which is a subclass to
org.apache.commons.i18n.LocalizedBundle.
Proposed fix: Personally I think the org.apache.commons.i18n.bundles
packages is a bit overkill; why not remove it altogether? Otherwise, move
the LocalizedException/RuntimeException/Error into the bundles package (or
another package such as "org.apache.commons.i18n.exceptions").
* Synchronize Maven (project.xml) and Ant (build.xml).
Proposed fix: Add jcoverage test coverage to build.xml. (I have EMMA test
coverage with Ant locally). This might imply adding jcoverage jars to a lib
dir.
* Create a database/JDBC MessageProvider to be used out-of-the-box,
subclassed or as an example.
Proposed fix: I have it in my head, just need to find the time to code it.
Update 2005-06-18: Preliminary version e-mailed to Daniel Florey.
* Consider examples with qualified entries.
Proposed fix: Create code example that use my modification with qualified
provider/namespace/source.
* Consider adding check style plugin in project.xml and fix whatever it
reports.
Addition 2005-06-18:
ces MessageProvider.
Mattias Jiderhamn
Expert Systems
Mail:
<ma...@expertsystem.se>mattias.jiderhamn@expertsystem.se
Web: <http://www.expertsystem.se/>www.expertsystem.se
Skype: <callto://mattiasj78>mattiasj78
RE: [i18n] Remaining issues
Posted by Arnaud HERITIER <ah...@gmail.com>.
My 2 cents,
>
> * Synchronize Maven (project.xml) and Ant (build.xml).
> Proposed fix: Add jcoverage test coverage to build.xml. (I
> have EMMA test coverage with Ant locally). This might imply
> adding jcoverage jars to a lib dir.
To simplify your devs,
- You can generate a minimal build.xml from maven with the ant plugin :
http://maven.apache.org/reference/plugins/ant/
- You can use the jcoverage report in maven :
http://maven.apache.org/reference/plugins/jcoverage/
Arnaud
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org