commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 35726] New: - [i18n] Patches for remaining issues
Date Thu, 14 Jul 2005 05:35:47 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=35726>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=35726

           Summary: [i18n] Patches for remaining issues
           Product: Commons
           Version: unspecified
          Platform: Other
        OS/Version: other
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Sandbox
        AssignedTo: commons-dev@jakarta.apache.org
        ReportedBy: mattias@expertsystem.se
                CC: daniel.florey@web.de


I intent to use this entry for submitting patches of the remaining issues of 
the i18n sandbox component. Below is a slightly modified copy of the e-mail 
sent to the dev-list on 2005-06-18:

Here is a list of what I think needs to be done before i18n is moved to 
proper/released as 1.0:

1. 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.

2. 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?).

3. 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.

4. 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").

5. 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.

6. 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.

7. Consider examples with qualified entries and/or JDBC provider.
Proposed fix: Create code example that use my modification with qualified 
provider/namespace/source.

8. Consider adding check style plugin in project.xml and fix whatever it 
reports.

9. Consider adding Commons Resources MessageProvider.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message